In the last few weeks, we passed two more important milestones in the deployment of DNSSEC: the signing of the root zone and the .edu zone. The root zone was signed July 15th, and the .edu zone was signed on August 2nd.
The signing of the root zone was the culmination of a long, deliberate rollout process designed to ensure that the introduction of DNSSEC wouldn’t inadvertently cause resolution problems, particularly with older nameservers. The worry was that signing the root would render these older name servers unable to resolve domain names. Consequently, the rollout of the signed root zone proceeded in stages, with a signed copy of the zone pushed to only a subset of the root name servers on predetermined dates. After each date, measurements would be taken at all of the root name servers to determine whether traffic was shifting from the name servers hosting the newly signed root zone to those still serving the unsigned root. Only if the effects were deemed negligible would the rollout continue to the next group of root name servers.
That process was completed before July 15th, but the signed copy that all the root name servers were then serving had been made deliberately unvalidate-able. To sign the root zone so that recursive name servers could validate records in it, ICANN needed to generate the root zones Key-Signing Key pair, VeriSign had to generate the Zone-Signing Key pair, and the public portion of the Zone-Signing Key needed to be signed by the private portion of the Key-Signing Key in a special key signing ceremony. (If you’re interested in an insiders view of the signing ceremony, check out this episode of the Ask Mr. DNS Podcast. My friend and co-host, Matt Larson, represented VeriSign in the ceremony.)
Two of the next red-letter days in DNSSECs deployment are coming up over the next 12 months or so, though the exact dates aren’t known yet: VeriSign will sign the .netzone before the end of the year (I’m guessing in December), and the .com zone some time in 2011. At that point, recursive name servers will be able to validate signed responses from a substantial portion of the Internet’s namespace by working their way down from a single configured trust anchor, the root zones Key-Signing Key and you wonthave an excuse for not signing your Internet-facing zones!
