John Timmons at Ars Techinca wrote about the interorganizational wrangling beginning as .gov studies DNS fix. At issue: Who should implement and manage the root signing process rasises the question about who should hold the root keys to such a critical service. But my question is, why does the root zone need to be signed at all?I hope plans to deploy DNSSec aren't slowed while ICANN, National Telecommunications and Information Administration (NTIA), and VeriSign hash out the details. As Timmons points out, there is a lot of wrangling going on that is important to address, but the root zone doesn't need to be signed for a successful global DNSSec deployment.

The trust in tree hierarchies like DNSSec and a public key infrastructure flows from a root to the leaves. Take a look at a hierarchy like VeriSign's, which has three PKI trees. The trust in each tree begins at the Class 1, 2, and 3 self-signed root certificate authorities. Those CAs are the trust anchors for each tree. All other public CAs have a similar structure where a self-signed root sits atop the tree and trust flows downward to the leaves. That flow of trust is the trust chain, which you can follow back to a trusted root. If you look Amazon.com's digital certificate, it was issued by the VeriSign Class 3 Secure Sever CA, which was in turn signed by the VeriSign Class 3 Public Primary Certification Authority, which is the trust anchor.

The hierarchy in DNS is no different. There is a single root, the root zone, at the top of DNS that refers all queries to the top-level domain (TLD) servers. I recognize that DNS is a single tree where the plethora of public CAs are multiple trees, but that recognition simply demonstrates that a single trust anchor is unnecessary. The TLDs could be their own trust anchors, and the trust anchor signing keys could be distributed the same way that C A certificates are distributed today, which is through software updates. Or a mechanism to update trust anchor signing keys could be distributed through DNS, making sure that keys don't expire before the new ones are distributed.

A singed root zone is a more elegant and potential efficient solution because there are fewer keys to update and can be managed through a single entity, but it's not necessary.