We Don't Need No Stinking DNS Root Zone Signing

John Timmons at Ars Techinca wrote about the <a href="http://arstechnica.com/news.ars/post/20081009-interorganizational-wrangling-begins-as-gov-studies-dns-fix.html" target="_blank">interorganizational wrangling beginning as .gov studies DNS fix</a>. 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?

Mike Fratto, Former Network Computing Editor

October 15, 2008

2 Min Read
InformationWeek logo in a gray background | InformationWeek

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.

About the Author

Mike Fratto

Former Network Computing Editor

Mike Fratto is a principal analyst at Current Analysis, covering the Enterprise Networking and Data Center Technology markets. Prior to that, Mike was with UBM Tech for 15 years, and served as editor of Network Computing. He was also lead analyst for InformationWeek Analytics and executive editor for Secure Enterprise. He has spoken at several conferences including Interop, MISTI, the Internet Security Conference, as well as to local groups. He served as the chair for Interop's datacenter and storage tracks. He also teaches a network security graduate course at Syracuse University. Prior to Network Computing, Mike was an independent consultant.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights