According to the ICANN, US Department of Commerce, and VeriSign, DNSSEC will be implemented on the root zones by no later than May 2010 (source: http://www.root-dnssec.org/).  For those of you who don’t know what this means, here’s a deconstruction of the sentence above:

• DNS stands for the Domain Name System.  DNS is a hierarchical naming system for the Internet (or private network) that translates human-meaningful domain names into machine-meaningful numerical identifiers (eg, www.winnersdontlose.com -> 74.52.192.250).

• DNSSEC stands for the Domain Name Systems Security Extensions.  It is effectively a suite of IETF-created specifications for securing certain types of data that is provided by DNS.

• A root zone is the top-level DNS zone in the above mentioned hierarchy.  Generally speaking, “the root zone” is the largest global DNS system on the Internet.  IANA and ICANN manages this zone.  Strictly speaking, this zone is where the authorities for gTLD (.com, .net, etc) and CC TLD (.uk, .us, etc) are configured and handed out to the world.  The root zone is hosted on 13 clusters of root servers (a. to m.root-servers.net), which are the only servers in the world that are allowed to be authoritative for it.

So now, re-read what I typed.

-

According to the ICANN, US Department of Commerce, and VeriSign,
DNSSEC will be implemented on the root zones by no later than May
2010 (source: http://www.root-dnssec.org/).

-

So what does this really mean to you?  Given that the majority of us don’t need to know much more than theory about the root zone, would ICANN, US Dept of Commerce, and VeriSign really risk implementing something that could break a lot of installations today?  One would think that the majority of their decisions could be implemented in a transparent fashion, unbeknownst to the most of us. To better understand this decision, let’s look at it from two different perspectives:

1. What benefits does DNSSEC on the root zone really provide?  Why is it necessary?
2. What is the impact to the rest of the Internet by implementing DNSSEC on the root zone?

-

1) DNS, like a whole lot of other protocols that were created decades ago, was designed for a different Internet (lower bandwidth, higher error rate, trustworthy users).  The Internet as we know it today (including the misanthropes) has forced the creation and deprecation of many protocol specifications.  DNS suffers mostly from the trust issue.  For example, a DNS resolver currently sends a query for a resource record (RR) out to the Internet, and then will accept the first response it receives, without question.  Obviously a malicious server could provide an incorrect response, forcing the original resolver to use this incorrect address until its cache expired.  If this DNS server belongs to a major consumer ISP (like Comcat or RoadRunner), a major service interruption affecting tens of thousands of users could easily happen.

-

2) From a technology standpoint, the impact of signing the root zone has a minimal effect on end users and networks.  Since DNSSEC uses a PGP-esque keypair setup, RRs that are sent and received all day long by nameservers will be a little larger.  This will probably result in slightly larger network bills for companies managing large-ish installations, with the rest of us noticing little to no change in our operating costs.

So what IS the problem?

Part of the problem is that RFC 1035 (http://www.ietf.org/rfc/rfc1035.txt) set an upper-bound for the size (512-bytes) of a DNS response.  Because of this, many firewalls and applications used this limit in their DNS implementations.  This would not have been an issue until DNSSEC.  Since DNSSEC responses will have a signature (RRSIG) as well as the RR itself, it’s not out of the question to assume that many responses will be bigger than 512 bytes in size.

In addition to the RFC, another issue is that larger DNS packets have never been well respected on the Internet.  Most of the time, large UDP packets will get fragmented by routers along the way to the destination, and the destination either doesn’t, or can’t deal with fragmented UDP packets, and drops them.  DNS clients will usually then retry the query with a smaller buffer size, and may even eventually fail back to TCP.

-

In a nutshell, most of the problems that come about as a result of DNSSEC being implemented on the root zone are caused by larger DNS packets.  The two things you want to make sure of are:

1. Your server/network will allow in DNS packets larger than 512-bytes.
2. Your network/firewall will accept IP fragments, and your server knows what to do with them.

The DNS Operations Analysis and Research Center (DNS-OARC) has created a tool to help ease this process.  See https://www.dns-oarc.net/oarc/services/replysizetest for more details.