Tcpdump is an old, venerable tool, that remains highly relevant in today's world when trying to find events of interest in large packet captures very quickly. It doesn't have a great deal of "smarts," but sometimes that's just what you need; a tool that can be down-and-dirty fast, but that still packs an incredibly powerful packet filtering language.

While working with someone today, I was asked about some of the output that tcpdump will sometimes include with DNS queries and responses. Specifically, the question was, "What is the [1au] term in the output?" What is this person asking? Have a look at this example:

IP 192.168.61.21.49931 > 8.8.8.8.53: 37379+ PTR? 230.118.133.79.in-addr.arpa. (45)
IP 8.8.8.8.53 > 192.168.61.21.49931: 37379 NXDomain 0/1/0 (105)
IP 192.168.50.25.49931 > 8.8.8.8.53: 57+ [1au] PTR? 139.122.207.223.in-addr.arpa. (57)
IP 8.8.8.8.53 > 192.168.50.25.49931: 57 1/0/1 PTR mx-ll-223.207.122-139.dynamic.3bb.co.th. (110)

In the first packet (or line), we see host 192.168.61.21 sending a DNS request to Google's public resolver, 8.8.8.8. The 37379+ PTR? 230.118... what appears next in the line indicates that the DNS transaction ID (or Query ID) is 37379, and that recursion is desired (the +). The PTR indicates that this packet involves a pointer record. The question mark immediately after PTR indicates that the QR field is marked as a query. Finally, the information being queried appears. Nothing strange so far.

The next packet shows Google answering host 192.168.61.21. We know that this is the answer to our question because the query or transaction ID is shown as 37379. In this case, we have an NXDomain result, which means that the lookup failed (record not found). Following that we have what is likely a familiar notation for you: 0/1/0. This indicates that there are zero Answer records, one Authority record, and zero Additional records included in the response. Still, nothing particularly unusual. That changes in the next request.

The third line shows a different host, 192.168.50.25, sending a query out to Google. Coincidentally, this query is coming from the same port (really, that's just a coincidence in this data; there's nothing more to read into this). We see that the query ID is 57 and, because of the +, we know that recursion is desired. Notice what comes next:

IP 192.168.50.25.49931 > 8.8.8.8.53: 57+ [1au] PTR? 139.122.207.223.in-addr.arpa. (57)

This is where the mysterious [1au] appears. If you read the manual page, you might have difficulty figuring out what this actually means, but it's actually pretty straight forward. When the DNS protocol decoder in tcpdump detects an anomaly in a query, it will note that between square brackets just like this. In this particular case, the au portion of the output indicates that the anomaly lies in the additional records section (Note that the au means "Additional" and not "Authority", which would make more intuitive sense!) This could also be an a, which would indicate the issue is in the answers section, or an n, which would indicate that the anomaly is in the Authority (or nameservers) section.

To summarize that last paragraph, the [1au] indicates that there is an anomaly in the additional records section of this query. More specifically, the number 1 indicates that there is one record present in the additional records section. Even as you read that, I hope that your mind is saying, "Well, that's odd..." That's exactly the point! The reason that tcpdump is calling this out as an anomaly is because the sender is sending a query, but that query includes additional records. It would be similarly odd for a query to send answers or authority records!

That might leave you wondering what's actually in that section. Let's have a quick look:

IP 192.168.50.25.49931 > 8.8.8.8.53: 57+ [1au] PTR? 139.122.207.223.in-addr.arpa. (57)
    0x0000:  4500 0055 6a86 0000 7e11 cf40 c0a8 3219
    0x0010:  0808 0808 c30b 0035 0041 86a7 0039 0100
    0x0020:  0001 0000 0000 0001 0331 3339 0331 3232
    0x0030:  0332 3037 0332 3233 0769 6e2d 6164 6472
    0x0040:  0461 7270 6100 000c 0001 0000 290f a000
    0x0050:  0080 0000 00      

We can see from the hex output that we have a 20 byte IP header followed by a UDP header (IP protocol 0x11). Decoding the packet from IP offset 20, we find a source port (0xc30b) and a destination port (0x35), followed by the UDP length and checksum. Next, we have the DNS query ID beginning at UDP offset 8. The decimal value, visible in the tcpdump output, is 57, which is represented as 0x39 in the DNS header. The next field indicates the DNS flags, 0x0100, which tells us that we have a query with recursion desired. The next field, beginning at offset 0x0020 in the output, is 0x0001. This indicates 1 question record, followed by 0x0000 answer records, 0x0000 authority records, and then our anomaly: 0x0001 additional records.

Following this, we have a DNS label of 0x03, indicating that the first piece of the query is 3 bytes long, followed by 0x31 0x33 0x39, or 139. Next, another 0x03 label to prefix the 122 portion of the query, then 207, 203, in-addr, and arpa. This last piece, the arpa is found at offset 0x0040 in the output: 0461 7270 6100, where the final 0x00 byte indicates the end of the record. The remaining data, then, is what has been sent as an additional record in this query.

Rather than decode the rest of this by hand, let's have a look at how Wireshark sees this:

What does this tell us? We can see that the query includes an EDNS (Extended DNS) option defining the maximum UDP payload that the host is willing to accept. While tcpdump can see that this record is present, it does not decode the EDNS additional record in its output!

David Hoelzer is the author and maintainer of the SANS SEC503 Advanced Intrusion Detection course, the leading class for advanced network analysis in the industry. With more than 30 years of experience in information technology and security, he is the author of and a contributor to a number of open source defensive tools. In addition to acting as the Chief of Operations for Enclave Forensics, Inc., an incident response, secure coding, and managed services corporation, David is also the Dean of Faculty for the SANS Technology Institute (STI).