DNS-OARC 24th Workshop, Buenos Aires, Presentations
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:
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.
Please note: This tool isn't sufficient for testing against the glibc stub resolver bug described CVE-2015-7547. The test results bear no connection to this bug.
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:
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"
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'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:
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:
Submitted by admin on Thu, 2016-02-18 12:03
Public Interest Registry
Verizon Digital Media Svs
Integrated S and T
Tel Aviv University