PKTMON is a built-in packet sniffer tool in Windows client and server operating systems. For the full list of PKTMON articles, please see this page.
When running PKTMON in real-time mode, the output is typically limited to information regarding the headers of layer two, three, and four protocols. For application protocols like HTTP, RDP, SSH, and SMB, no decoding is available directly on the real-time command-line output.
However, one exception exists: DNS queries and the respective replies. Here, PKTMON provides an extensive automatic decoding in the real-time mode. Unfortunately, the output is not self-explanatory:
A combinations of characters like *, $, +, ?, –, |, [ and / all have important meanings. Overall, the PKTMON tool is relatively sparsely documented. This is especially the case regarding the DNS output.
Despite the PKTMON DNS output lacks any kind of official documentation, this article will provide all the information on how to interpret the DNS data available in the real-time command-line view of PKTMON.
The DNS header is only 12 bytes in length. The following information is carried inside the DNS header:
| DNS header flag / field | Explanation |
| QR bit | Query / Reply. If this bit is set to zero, the packet contains a query. If the bit is set to one, the packet is a reply. |
| RD bit | Recursion Desired. If set to one, the client requests for recursive resolution, if the receiving server is not authoritative for the name being queried. |
| RA bit | Recursion Available. If this bit is set to one, the server confirms its ability to conduct recursive resolution. |
| AA bit | Authoritative Answer. The reply is not from cache, but directly from a primary source, i.e., a server with the particular zone loaded. |
| AD bit | Authenticated Data. The reply was verified by the server through DNSSEC. |
| Query id | A random number between 0 and 65535, set by the client. The server reply must match this specific identification number to be accepted by the client. |
| Number of answers | The number of answers included in the DNS data field. |
| Number of authority records | The number of authority records included in the DNS data field. This is information that a authoritative server can include, but is not required to. |
| Number of additional records | The number of additional records included in the DNS data field. This is data that the client did not specifically ask for, but the server is including as “additional” information. Today, mostly used for the EDNS0 feature. |
All of the above information is presented by PKTMON in the real-time mode. However, due to the somewhat obfuscated symbols displayed, additional explanations are required.
To capture DNS traffic, use the following PKTMON filter:
pktmon filter remove
pktmon filter add -t UDP -p 53Acquire the network interface card component ID with:
pktmon comp listStart the real-time capture of the DNS data with:
pktmon start -c -m rt -s 16 --pkt-size 0 --comp <INTERFACE-ID>
Example output from PKTMON real-time mode, having captured a DNS query and reply.
(For clarity, the screenshots displayed will only contain the final components of each line.)
The question mark in a packet indicates that the QR bit was set to zero, meaning this packet was a DNS query. The absence of the question mark, as seen in the packet immediately after, indicates the QR bit was set to 1, i.e., was a Query Reply.
Next, we can observe two uncomplicated pieces of information. First, the query type, here the A record type. Other common types are SOA, NS, PTR, CNAME, etc. Next to it, we can observe the PKTMON decoding of the name query itself.
Next, an important component of the packet pair of a query and the reply is the Query Identification number. This number is used for the purpose of the client potentially sending multiple queries simultaneously, and the query id in the replies are used to match the incoming answer with the question.
Traditionally, the query id was often a sequential number, increased by one for each query. However, the risk of spoofed replies required this to be changed. Today, DNS clients typically will create a random number for each query, thus making it more difficult for an out-of-band malicious user to send a spoofed reply. The value is a 16 bit number.
At the end of each PKTMON real-time mode output line is the length of the DNS header and data fields combined. (Note that the number 53 in the DNS reply is only a coincidence with the port number UDP/53.)
The asterisk symbol, or star, next to the query id, indicates the AA bit was set to 1 in the reply. An answer is said to be an “authoritative answer” when provided from a server with the zone loaded, i.e., the answer was from a primary source.
In the DNS header, the three numbers separated with a front slash are counters for the information found in the DNS data field. Here, the number of answers, the number of authority records, and the number of additional records are presented. Note, these counters are from the DNS header, and the actual information is in the DNS data field.
The header contains the query id, bit flags, and counters. The data component carries the actual information.
When receiving at least one “Number of answers”, the PKTMON tool will decode the information from the DNS data field and present this in the real-time mode.
The client will signal its “desire” for recursive resolution by setting the RD bit (Recursion Desired) in the query to 1. In the PKTMON output, the enabled RD bit will be displayed as the plus symbol.
The server will presents its general ability to conduct recursive resolution, i.e., attempt further resolution of a question to external DNS servers, by setting the RA bit (Recursion Available) to 0 or 1. PKTMON will display the RD bit set to zero by a minus symbol on the command-line output.
The absence of the minus symbol in the reply output means the RA bit (Recursion Available) was set to 1, and the server is willing to perform recursive resolution.
If the client packet displays the symbols [1au], it means that the query itself is carrying one “additional record“. Traditionally, the additional record field was only ever used by servers in replies. However, the DNS extension standard, EDNS0, uses the Additional Record field to carry its data between the client and the server. Inside the Additional Record, a special record type called OPT is utilized for the exchange of extended DNS data, e.g., the capability to receive more data than the original limit of 512 bytes.
In the server response, the answer to the name query itself is provided. We can also note that in the server reply, one additional record is sent. This provide the “internal response” to the client EDNS0 options.
When the server reply contains a $ symbol in the PKTMON output, the AD (Authenticated Data) bit was set, meaning the reply was validated by the server through DNSSEC.
Finally, if a PKTMON output line contains the | symbol, it informs the user that the packet size was greater than the configured packet capture size. This results in PTKMON not being able to fully decode the DNS reply. Ensure to start the packet capture with the option ––pkt-size 0. This will capture the full size of all packets.
As seen, the symbols used in the real-time mode are not always entirely intuitive. A summary is provided below.
The PKTMON to DNS header translation table:
| PKTMON real-time output | DNS header value |
| ? | QR bit = 0 |
| + | RD bit = 1 |
| – | RA bit = 0 |
| * | AA bit = 1 |
| $ | AD bit = 1 |
| (64) | Number inside parentheses: length of DNS header + data. |
| 21313 | Number without parentheses: the query id. |
| 1/2/3 | Number of answers / authority / additional. |
| [1au] | One additional record provided in the client packet. |
| [|domain] | PKTMON output cut, due to too large packet. |
For advanced troubleshooting of TCP with PKTMON, please see the next article in the series.
If you have any questions regarding the PKTMON output for DNS queries, please leave a comment below.