If you haven’t done so already, May 5 will be a good day to make sure your network is ready for DNSSEC. On May 5, the last of the Internet’s 13 root servers will transition to (Domain Name System Security Extensions) DNSSEC. While the transition won’t bring Internet traffic to a screeching halt, it could pose a problem for network administrators and users working with older DNS servers, routers, firewalls, and modems.
What is DNSSEC?
In his 2008 TechRepublic article, “You don’t have to wait to deploy DNSSEC,” Tom Olzak explained the rationale behind DNSSEC, how it works, and the challenges it faces. He wrote:
DNSSEC (Domain Name System Security Extensions) is a suite of specifications which implement record signing to ensure the integrity of certain types of transactions. It uses both asymmetric and symmetric cryptography for RR (Resource Record) or zone transfer transactions, respectively. To ensure the authenticity of information received by a resolver. … Securing DNS with DNSSEC begins with establishing a chain of trust. Resolvers use ‘anchor keys’ to verify parent domains, beginning with the trust anchor.
Of the challenges Olzak mentions, one is of particular importance to those supporting or working on older network equipment. According to Olzak,
DNSSEC will increase DNS traffic with more requests and larger responses. Domains with high volume traffic should prepare for increased bandwidth needs.
DNSSEC could slow/stop Internet traffic for some
Until relatively recently, DNS responses have usually been limited to 512 bytes, and have mostly been carried by an Internet protocol called “UDP”. So various bits of infrastructure such as firewalls and home ADSL routers have been designed on the assumption that all DNS responses are 512 bytes or less, transported by UDP. The problem, of course, is that the digital signatures required by DNSSEC tend to push the size of DNS responses past the 512 byte point.
This shouldn’t present a huge challenge, because the DNS protocol has a mechanism for transporting larger responses by sending them over TCP instead of UDP. But the mechanism has been so rarely needed that many vendors haven’t implemented it. Indeed, large DNS responses have been so rare that some firewall vendors and some companies’ security managers have actively blocked them on the assumption that the only possible reason they’d exist would be as part of an attack!
As Newton puts it, “there’s a reasonable expectation that people who aren’t correctly processing large DNS responses will suffer connectivity problems to random bits of the Internet.”
What you should do?
In a May 4 article, iTnews.com.au provided tips from several experts on making sure your network and end users are ready for DNSSEC.
- If you haven’t done so already, make sure your DNS servers, routers, and firewalls, can handle DNS requests with packet sizes larger than 512 bytes. Upgrade software and firmware if necessary.
- Configure your firewall to allow DNS over TCP/53 and make sure “fragmented DNS responses over UDP or TCP aren’t blocked.”
- If you support users’ home equipment, make sure it is also compatible with DNSSEC, especially if the device has a built-in DNS server. Install new firmware if necessary.
No one seems to be predicting that the May 5 DNSSEC changes will cause a significant Internet disruption, but it never hurts to make sure your network and your users are prepared. If you’re not sure, you can use the instructions at DNS-OARC to test if your current DNS resolver can handle DNSSEC .
Additional DNSSEC resources:
- DNSSEC Deployment Guide (Microsoft)
- DNSSec – And Why the Internet Probably Won’t Break Today (Etherealmind.com)
- Will DNSSEC kill your internet?
- Secure Domain Name System (DNS) Deployment Guide, NIST SP 800-81
- DNSSEC: The Protocol, Deployment, and a Bit of Development (Cisco)
- The Case Against DNSSEC
- Resource Records for the DNS Security Extensions (IETF, RFC 4034)
- A Illustrated Guide to the Kaminsky DNS Vulnerability
- Verisign and ICANN Square off Over the DNS Root
- DNSSEC Introduction and Resources (ISC)
DNSSEC unlikely to break Internet on May 5