2023-06-01: This service has been deprecated in favor of Check My DNS.

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.

Important Notes

  • This tool isn't sufficient for testing against the glibc stub resolver bug described CVE-2015-7547 (see more information below). The test results bear no connection to this bug.
  • DNS resolvers continue to evolve, this tool will likely not work as expected.
  • Also, with the move to using TCP instead of using UDP for resolvers, it may well one day become obsolete.
  • As of BIND 9.10, it's EDNS fallback mechanisms has changed which may give incorrect or inconsistent results.

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.
CVE-2015-7547: glibc getaddrinfo Vulnerability Notes:

Please note this tester is not a good way to determine if a system is vulnerable to the glibc stub resolver bug, CVE-2015-7547. Caution should be used when inferring any relationship between response sizes and actual vulnerability to this bug. In particular:

  • The test is for EDNS support. Attacks could potentially involve TCP, not just UDP and EDNS.
  • The recommended test involves a query for TXT records. The vulnerability is related to lookups for A/AAAA lookups.
  • The dig command is not implemented on top of getaddrinfo, it contacts the system name servers directly, so the vulnerable code path is not exercised.
  • Even if a resolver cannot get large responses from the Internet, it could still combine multiple smaller responses into a larger one, and such a large response could trigger the vulnerability.
  • Conversely, availability of large responses does not indicate vulnerability of the system because it may have already been patched.

Additional Resources