Earlier this year, ICANN and VeriSign announced plans to sign the DNS root zone, using DNSSEC. DNSSEC is a set of extensions to the DNS protocol which allow one to digitally sign the records in a zone and allow a client to verify the authenticity of these records.
In the early days of the DNS protocol, it was assumed that large packets will rarely be required, so the early DNS RFCs (RFC 1035) set an upper bound of 512 bytes on the size of a DNS message. Many devices, firewalls and applications used this limit in their DNS implementations. Until recently, it wasn't a problem.
One of the most visible changes that DNSSEC introduces is that DNS replies become bigger. Every resource record set (RRSet) is accompanied by a signature (RRSIG). In many cases, such responses will be bigger than 512 bytes in size. In order to cope with this, the DNSEXT working group of the IETF developed an extension called EDNS0, which allows a client to request bigger responses, and a server to send bigger responses, up to 4096 bytes in size. In a perfect world, this would have solved the problem. Almost all responses would fit within 4096 bytes, and DNSSEC would just work.
Unfortunately, the reality is that large DNS packets aren't treated well on the Internet. Some firewalls and devices just drop all DNS packets bigger than 512 bytes in size. In other cases, large packets get fragmented by routers along the path, and the destination does not, or cannot handle fragments, and drops them. DNS clients then have to retry the query, perhaps with smaller buffer sizes, until they can get a response. Some clients fall back to TCP.
The RIPE NCC is concerned about these issues, and we're adjusting our instrumentation and monitoring, so that we can observe what happens when the signed root zone is gradually introduced.
We already collect pcap traces of all UDP and TCP queries arriving at K-root. We're going to improve this by also collecting TCP responses, to understand TCP behaviour better. In addition to this, we will also collect separate pcap traces focusing on priming queries as these bootstrap the whole DNS lookup process and are therefore especially important.
We'll upload these pcap traces to OARC servers, so that it is available to researchers to analyse, and discover trends and problems. OARC stands for the DNS Operations, Analysis, and Research Center ( www.dns-oarc.net ) and is a trusted platform that allows operators, implementers, and researchers securely share data and coordinate research.
In addition to pcap traces, we also run DSC collectors at all K-root instances. DSC provides interesting summaries of various types of data sets. We'd like to improve this further by defining more data sets to collect. One particular one that interests us is the priming query data set.
Path MTU probing
We've installed OARC's reply size tester ( https://www.dns-oarc.net/oarc/services/replysizetest ) at all the global instances of K-root. This small program allows a client to determine its path MTU towards its nearest instance of K-root.
On the RIPE NCC website, we've embedded mark-up in some of the pages (for instance on this one: http://www.ripe.net/error/dns.html ) to refer to this test name, test.rs.ripe.net. This causes the browser to send queries for this name to its locally-configured resolver. This way, we can collect data about the path MTUs of all the resolvers that are used by visitors to these pages.
We will share our results and findings with the community at regular intervals, so please stay tuned.
If you have the DNS tool dig installed, you can run:
dig txt test.rs.ripe.net +short
This will eventually give you back a response telling what the maximum path MTU is for your resolver.
You will get a response like this:
"192.168.1.1 sent EDNS buffer size 4096"
"192.168.1.1 DNS reply size limit is at least 1399 bytes"
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 1399 bytes.
If the size of the response is less that the size of the advertised buffer, you may want to investigate this further. For more details on how this works, and how to interpret the responses, please see https://www.dns-oarc.net/oarc/services/replysizetest