While many of you know ISC as the maintainer of the BIND DNS server software, we have always had our hand in the DNS operations field, including operating one of the 13 DNS root servers (F.ROOT-SERVERS.NET), as well as secondaring many ccTLD and non-commercial zones for over a decade. ISC has also been at the forefront of designing and implementing DNS Security Extensions (DNSSEC) which is a mechanism to cryptographically verify that the response given to a DNS request is correct.
The big change is that to support DNSSEC responses from DNS servers will become larger, as they will contain the answer in the form of a RRset and its signature (RRSIG). Before DNSSEC, most DNS packets were over UDP and smaller than 512 bytes, which was enshrined in the early DNS-related RFCs. Since most DNS responses with signed RRsets (containing the paired RRSet and RRSIG) will exceed that 512 byte limit, ISC co-founder Paul Vixie worked with the IETF DNS Extensions Working Group to develop the now-standard EDNS0 extension (RFC 2671). This allows a client to request a response larger that 512 bytes (up to 4096 bytes) over UDP via IP fragments. EDNS0 is now widely supported by many device and appliance vendors (as well as DNS server applications like BIND).
However there are many devices & appliances in the wild that are still configured by default to only accept DNS packets smaller than 512 bytes or that don’t allow for IP fragments. In a few cases these devices or appliances are able to try a smaller buffer size until they can get the response thru; in most cases though, recursive name servers would then just fall back to TCP or just drop the response full stop and gets no answer.
We previously documented this issue last year when the root zone was signed in the blog post “The Signed Root Is Coming!”. Now with more and more TLD’s and enterprises signing their zones in 2011, this problem may reveal itself in more interesting ways. One non-obvious way is that while the zone you are querying for may not be signed, the authoritative nameservers they are using reside in a signed zone, so when the caching DNS server is looking up the authoritative nameserver records to follow the DNS chain, they responses come back signed which may get blocked and so you may not be able to resolve the domain in question.
You can check and see if your nameserver supports EDNS0 by using the Reply Size Test Server developed by DNS-OARC. This test will check and see if your resolver can accept EDNS0 packets and that your firewall (if there is one) is accepting IP fragments. ISC recommends that for maximum compatibility that firewalls should allow the full 4k that EDNS0 allows rather than limit it to 2k to account for additional response growth.
Note that if the results are smaller than you expect and if you are running a modern DNS software package (like BIND 9.6-ESV or later), then the problem may lie behind a intermediary firewall, NAT device or router between your name server and the test server. Please fix any issues you see now or you will likely experience degraded performance as more DNSSEC signed zones are fully rolled out over the next year and more DNS.
And to enterprises looking to sign their zones – educate your customer base of some of the issues they may see when your zones are signed using DNSSEC. DNS has in the past tended to be a service that was setup and then forgotten about because “it just worked” other than the occasional server code upgrade, and a lot of old Best Common Practices (BCP’s) have changed with the advent of DNSSEC. If your enterprise has any questions about implementing or deploying DNSSEC, please contact us to see how we can help.