Happy holidays from ISC!
ISC is fortunate to have staff members in so many different countries around the world: our software development benefits from all the different perspectives - and we benefit personally!
Read post
The press seems to love stories of doom and gloom. And for almost as long as the Internet has been around, there have been dire predictions of some resource exhaustion, disaster, or security flaw that will destroy the Internet. And who is the villain in this week’s piece? DNSSEC and the signing of all the root servers.
While I love a good story as much as the next person, it seems time to actually throw a few facts on the fire.
What is DNSSEC and what is “signing”?
The Domain Name System Security Extensions (DNSSEC) is a way of ensuring that when your name server queries the authoritative servers for example.com, you have a high degree of certainty that the answers you get back actually came from the example.com servers and haven’t been altered in transit.
Based on the trust anchors that you configure for your name server, when your name server validates a DNS response, it will go link by link in the chain. Each link “signs” its piece by using public key cryptography to create a digital signature. Your resolver can use that signature to validate that the server you think should sign a link has actually signed it and that what you receive was correctly signed.
For the DNS label “host.example.com.”, you would go to the root and get the signature that will let you validate “com”. From “com”, you would get the signature that will let you validate “example.com”, and so on. In order for this to work, the root servers sign all of their RRsets, including the RRset for “com”. The “com” servers would sign all their RRsets, including the ones for “example.com”.
What really happened on May 5?
The root server operators didn’t want to just turn on DNSSEC, start signing the root zone, and hope nothing broke. They came up with a detailed, phased plan for deployment. The first stage was to hand out signature records that were not validatable but would test if handing out DNSSEC signatures would break anything.
On 25 Jan 2010, the first of the 13 root servers starting handing out a Deliberately Unvalidatable Root Zone (DURZ). This was done in phases over several months so that if something did break, not all root servers would be serving the new data and name servers that couldn’t accept the DURZ would still have access to root servers.
What happened on 5 May 2010 was that the last of the 13 root servers started serving the DURZ. And if you’re reading this, I think you can assume that the Internet is still working.
It is important to keep in mind that while the roots are “signed”, they are still not serving a validatable root zone (i.e. you can’t yet use the roots as a trust anchor). The current schedule is that a real signed root zone will start being served July of 2010. This will make the roots usable as a trust anchor.
While this will be a real milestone, the Top Level Domains (TLDs), such as .NET, .COM, etc. will also all need to be signed before you can have just the root as a trust anchor. Until then, additional trust anchors, such as dlv.isc.org, will still need to be used.
What’s the real problem?
The underlying issue is DNS response size. “Conventional wisdom” for years for configuring firewalls, proxies, and load balancers was that UDP packets were 512 bytes or smaller and that DNS only used TCP for zone transfers, not queries. Sadly, both of these are wrong. For quite a while, DNS responses did fit in 512 byte packets. However, as the Internet grew and DNS was used for more and more things not originally envisioned by its designers, packets did get bigger.
DNS did have a back up plan for larger packets; the truncate bit (TC). If a nameserver had a response where all the required records in an RRSset would not fit into a 512 byte packet, the nameserver would send back an incomplete response with the TC bit set. That was supposed to tell the querying server that the response was truncated and that it should retry the query using TCP, which doesn’t have the 512 byte restriction. Too bad various middleware boxes were configured to not allow DNS over TCP…
The IETF developed the Extension Mechanisms for DNS EDNS0 to allow querying nameservers that could accept larger than 512 byte UDP packets to tell the authoritative nameserver how big a packet they could accept. And life should have been good. Except for folks that blocked larger than 512 byte packets… And all sorts of intervening network boxes and middleware boxes did all sorts of broken things with fragmented UDP packets, broke EDNS0, filtered DNS queries over TCP, etc.
The big problem this first phase of the signed root deployment is trying to catch is letting folks find all these broken middleware boxes so that they can be fixed before a signed and validatable root zone file is deployed.
These broken boxes really should be fixed and the vendors have no excuse. EDNS0 & queries over TCP have been around for more than ten years. IPv4 fragmentation has been around for decades. This is not DNSSEC-specific; DNS needs this fixed even if you are not planning on deploying DNSSEC.
Will my DNS stop working?
Probably not. OARC and the root operators have been monitoring this rollout carefully. By watching increases in TCP query traffic and packet sniffing, they have determined that the number of nameservers behind truly broken middleware boxes is quite small. Those boxes should be fixed, since this breaks any large DNS response; this is not a problem particular to DNSSEC.
DNS is very robust. You may have timeouts of UDP, falling back to smaller UDP packet sizes or falling back to TCP but it takes a lot of broken-ness to truly make DNS unusable.
Now that the root is signed, how long do I have to sign all my zones?
As long as it takes you to determine you have a business case for doing DNSSEC, determine your trust anchor policy and your signing policy, and do a phased rollout plan of your own.
There is no requirement for you to sign your own zones just because the root is signed. You should sign your zones when you have a good reason to sign them.
I would like to start using DNSSEC validation. Do I have to sign my zones?
You do not have to sign your own zones in order to start doing DNSSEC validation. Odds are that you’ll want to start signing your zones at some point. But all you need to do for DNSSEC validation is to choose a trust anchor, enable DNSSEC validation in your nameserver configuration, and put the trust anchor in your nameserver configuration.
What if I don’t want to do DNSSEC? Will DNS still work for me?
Yes. One of the design requirements for DNSSEC was that it shouldn’t break DNS for people not using it. If you never sign your zones and never turn on DNSSEC validation, even if the rest of the Internet does, you will never notice. Your DNS will continue to work as it has in the past. The only caveat is that if you are behind one of the really broken middleware boxes, you should get it fixed. But you’ll need that for regular DNS responses larger than 512 bytes anyway.
Where do I go from here?
Listed below are some resources for testing and further reading. ISC can also assist you with your DNSSEC deployment through training and consulting.