OARC's DNS Reply Size Test Server

Recent increases in DNSSEC deployment are exposing problems with DNS resolvers that cannot receive large responses.

The maximim reply size between a DNS server and resolver may be limited by a number of factors:

  • If a resolver does not support the Extension Mechanisms for DNS (EDNS), replies are limited to 512 bytes.
  • The resolver may be behind a firewall that blocks IP fragments.
  • Some DNS-aware firewalls block responses larger than 512 bytes.

The BIND resolver, since version 9.5.0, includes a feature to decrease its advertised EDNS receive buffer size (down to 512) when its queries time out. We've seen this lead to significant increases in TCP for DNSSEC-signed zones.

DNS-OARC built the DNS Reply Size Test Server to help users identify resolvers that cannot receive large DNS replies.

How To Use

To use the DNS Reply Size Test Server, simply use dig command line tool to issue a TXT query for the name rs.dns-oarc.net:

$ dig +short rs.dns-oarc.net txt

You can test a specific DNS resolver by using the @server feature of dig.

The output should look something like this:

rst.x4001.rs.dns-oarc.net.
rst.x3985.x4001.rs.dns-oarc.net.
rst.x4023.x3985.x4001.rs.dns-oarc.net.
"192.168.1.1 sent EDNS buffer size 4096"
"192.168.1.1 DNS reply size limit is at least 4023 bytes"

The first three lines of the output are CNAME records in the response. The "x" numbers represent the sizes of successfully received responses at each step in the test. The final two lines are TXT records that provide information on the test results. Here we can see that the resolver advertised a receive buffer size of 4096 and the server was able to send a response of 4023 bytes.

If your test results in a reply size limit of less than about 4,000 you may want to investigate further for one of the following problems:

No EDNS

The following result comes from a DSL router that does not support EDNS:

rst.x486.rs.dns-oarc.net.
rst.x454.x486.rs.dns-oarc.net.
rst.x384.x454.x486.rs.dns-oarc.net.
"X.X.X.X DNS reply size limit is at least 486 bytes"
"X.X.X.X lacks EDNS, defaults to 512"

IP Fragments Filtered

If you're behind a firewall that filters IP fragments, you can expect to see a reply size limit slightly less than 1400 bytes:

rst.x1014.rs.dns-oarc.net.
rst.x1202.x1014.rs.dns-oarc.net.
rst.x1382.x1202.x1014.rs.dns-oarc.net.
"X.X.X.X sent EDNS buffer size 4096"
"X.X.X.X DNS reply size limit is at least 1382 bytes"

Inconsistent Results

The test may provide inconsistent results if any of the DNS reply packets are dropped or reordered. The records in the reply have a TTL of 60 seconds or less, so feel free to rerun your test again after waiting 60 seconds.

Truncated, retrying in TCP mode

Some resolvers (e.g. BIND-9.6) send the bloated authority section back to dig. Since dig doesn't set an EDNS receive buffer size by default, the reply may be truncated. You can avoid this problem by telling dig to advertise a large receive buffer. For example:

$ dig +bufsize=1024 rs.dns-oarc.net txt

Note that the EDNS receive buffer size is a "hop-by-hop" parameter, which means that setting it here does not affect the test between your resolver and the OARC server.

Nominum CNS

Nominum's CNS resolver is designed to utilize EDNS only after first receiving a truncated response. To use this test with a CNS resolver, issue the following query:

$ dig tcf.rs.dns-oarc.net txt

The special name "tcf" instructs the server to set the TC bit in responses if the query doesn't have an EDNS pseudo-record. This should cause CNS to re-query with EDNS.

How It Works

For the technically inclined, here's how the DNS Reply Size Test Server works:

  • An initial DNS query leads to a chain of CNAME responses. It currently uses a CNAME chain of length three.
  • A custom DNS server sends multiple replies. The replies decrease in size. The CNAME rdata encodes the size of the reply. Assuming the UDP replies don't become reordered, the resolver will follow the CNAME of the largest reply it can receive.
  • The authority and additional sections of the CNAME reply are bloated to make the response large.
  • The server uses something akin to a binary search to refine the reply size limit. For example, if the first step indicates that the limit is between 1024 and 2048, then the next step will send a number of logarithmically-stepped responses between that range (2048, 1625, 1290, 1024).
  • At the end a TXT RR is sent indicating the measured reply size limit.

Additional Notes:

  • This tool can only test the path between itself and the resolver. I cannot test the path between the resolver and dig.
  • The test server works over both IPv4 and IPv6.
  • The custom DNS server does not yet support name compression. This has a small effect on its ability to build a message of a certain size. Currently it takes 37 NS+glue records to bloat the response to near 4K. With compression it would take significantly more than that, so I'm not sure compression should even be enabled.
  • It might be better to bloat the response with a small number of Unknown (ie binary) RR types, assuming they be passed through by forwarders.

Additional Resources

Submitted by admin on Tue, 2009-07-07 21:54.