Tomorrow (May 5), at 17:00 GMT, all 13 root DNS servers on the Internet will begin using DNSSEC (Domain Name System Security Extensions) to reply to user requests. Here’s why you might care about this.
As most of our readers know, DNS is what translates the URL you type into your browser (like “www.mooselogic.com”) into an IP address (like “220.127.116.11″) that your computer can actually use to send packets of data across the Internet. If you have a Windows Server-based network, one (or more) of your Windows Servers is probably providing DNS services to the users on your network. But the DNS server on your network doesn’t automatically know where everything is. If it needs to resolve an address that doesn’t happen to already be in its local cache, it has to ask some other DNS server out on the Internet. Sometimes those queries go all the way to one of the root servers.
It’s been recognized for quite some time that the existing protocol used for DNS queries isn’t entirely secure. Therefore, the international standards bodies have been working on a more secure standard, which is DNSSEC. DNSSEC uses digital signatures to authenticate DNS responses, so your computer knows the response actually came from an authoritative DNS server.
So what’s the problem? The potential problem is that those DNS responses will arrive in significantly larger data packets than before. Specifically, rather than using UDP packets that are smaller than 512 bytes, the responses will not only be longer, but may be broken into multiple TCP packets. Some routers and firewalls specifically inspect DNS traffic to look for anomalies, and if you have older equipment that doesn’t know about the DNSSEC standard, these changes may very well look like anomalies, and be blocked. That would mean that your DNS clients or DNS server would not be able to communicate with the public root DNS servers, and that would mean that you would start having problems resolving DNS.
These problems may be intermittent in nature at first, because some DNS requests may be able to be resolved by using locally cached information…but DNS records typically have a “time to live” built into them, so eventually the cached information will expire and have to be refreshed. So if you do have a problem, it’s likely to get worse with time.
There are some tools available to help you determine whether you’re likely to have a problem. If you’re comfortable using a DNS query tool like dig (which is a command-line query that can be run from most unix or linux systems), you can find instructions on using it at https://www.dns-oarc.net/oarc/services/replysizetest. If you don’t have access to a unix or linux host, or don’t feel comfortable using such a tool, you can download a Java utility from http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues, and run it on any system with Java run-time installed (which includes most Windows systems). Just download and save the file, then double-click it.
Watchguard customers should note that if you have a Watchguard Firebox or XTM appliance with current firmware, you should not have any issues with these new DNSSEC packets.