DNS Capture: UDP, TCP, IP-Fragmentation, EDNS, ECS, Cookie

It’s not always this simple DNS thing such as “single query – single answer, both via UDP”. Sometimes you have some more options or bigger messages that look and behave differently on the network. For example: IP fragmentation for larger DNS answers that do not fit into a single UDP datagram (hopefully not after the DNS flag day 2020 anymore), or DNS via TCP, or some newer options within the EDNS space such as “EDNS Client Subnet” (ECS) or DNS cookies.

I won’t explain any details about those options, but I am publishing a pcap with that kind of packets along with some Wireshark screenshots. Feel free to dig into it.

(Please note that I have a couple of downloadable pcaps on my blog, especially this one which looks at DNS and DNSSEC packets. However, with this post here I am looking into other DNS details.)

Download the pcap capture file here. 7zipped, 7 KB:

I am using dig version 9.11.3-1ubuntu1.7 (former versions are not using the EDNS cookie) on a Ubuntu 18.04.2 LTS. The Wireshark screenshots are from version 3.0.2. Note my custom Wireshark columns to show some special packet details that are relevant for DNS, likewise the TCP.Stream and UDP.Stream columns.

Common DNS: UDP

Find some very basic DNS queries/responses in UDP streams 11-14. First one with the “ad” flag (authentic data via DNSSEC), second one with DNSSEC failure aka SERVFAIL. Third and fourth: A and AAAA records:

Full listing:

Wireshark screenshots (quite boring at this time ;D):

Bigger Sizes: IP Fragmentation & TCP

Now it’s getting a bit more interesting. Querying for records that are bigger in size requires either IP fragmentation (there is no fragmentation in UDP, hence IP must do it) or the fallback/usage of TCP with its basic three-way handshake. Note that IP fragmentation behaves a bit different for IPv4 and IPv6. At least for IPv6 there is a huge discussion whether this fragmentation header should be dropped at *any* border router/firewall anyway. Keep that in mind when troubleshooting it! Links:

At least TCP is straightforward and without problems. (Note that zone transfers via AXFR and IXFR are handled by TCP by default.) For my test queries I used IPv6 and legacy IP, both via UDP (forcing IP fragmentation) and TCP:

Full listing (quite long dnskeys, not of interest):

Find those two UDP with IP fragmentation sessions at UDP streams 15 & 16 (while those IP fragments are NOT part of the stream directly. Again, be careful!) and TCP streams 0 and 1:

Fun fact out of my daily business while dealing with shitty fragments:

EDNS Extensions

The extension mechanisms for DNS (EDNS), RFC 6891, offer a flexible way to increase the DNS features. I am showing two scenarios here: RFC 7871 “Client Subnet in DNS Queries” and RFC 7873 “Domain Name System (DNS) Cookies”.

EDNS(0) Client Subnet

For the EDNS client subnet (ECS) packets I queried the Google Public DNS Resolver from one of my Linux machines, but I captured the packets on my authoritative DNS server! That is: The packets in the trace file show the resolving process from Google Public DNS to my DNS server ns1.weberdns.de. Google adds the client subnet, which in this case is a /56 IPv6 prefix on which my Linux machine resides.

Full listing (nothing to see here, skip it):

Not all resolving queries from Google Public DNS are shown here because I only captured on one out of two authoritative DNS servers. However, some queries came in twice, some over IPv6 – some over legacy IP. For whatever reason:

Domain Name System (DNS) Cookies

Finally, DNS cookies: “DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers”, RFC 7873. I simply queried my authoritative DNS server (hence the “aa”, authoritative answer, flag is set) four times for the same FQDN. For every transaction, a new client and server cookie was generated by both sides. UDP streams 7-10.

Full listing which also shows the cookies in the dig output:

Wireshark screenshot, again with a custom column:

That’s it. Happy wiresharking!

Further Links

Featured image “Shirley Lo” by Thomas Hawk is licensed under CC BY-NC 2.0.

Leave a Reply

Your email address will not be published. Required fields are marked *