Home / Blogs

DNSSEC Deployment at the Root

The DNSSEC is a security protocol for providing cryptographic assurance (i.e. using the public key cryptography digital signature technology) to the data retrieved from the DNS distributed database (RFC4033). DNSSEC deployment at the root is said to be subject to politics, but there is seldom detailed discussion about this “DNS root signing” politics. Actually, DNSSEC deployment requires more than signing the DNS root zone data; it also involves secure delegations from the root to the TLDs, and DNSSEC deployment by TLD administrations (I omit other participants involvement as my focus is policy around the DNS root). There is a dose of naivety in the idea of detailing the political aspects of the DNS root, but I volunteer! My perspective is an interested observer.

Recent developments surrounding ICANN:

  • The reconsideration request for the .xxx TLD rejection [PDF] again raises issues about the United States government control over the Internet.
  • Indeed, I was personally explained by a US civil servant that the ICANN implementation of a signed DNS root zone according to the “transition agreement” (part of the ICANN-Verisign settlement [PDF]) is subject to the final say of the US Department of Commerce (i.e. ICANN and Verisign “are going to do whatever the DoC tells them to do”).
  • The .ca TLD administration, CIRA (Canadian Internet Registration Authority) recently withdrawn [PDF] ICANN support. If the .ca TLD supports DNSSEC by the time ICANN is ready to establish secure delegations, will ICANN agree to establish a secure delegation to .ca without first resolving the difficulty with CIRA? The more general question is the provision of an optional service, DNSSEC secure delegation from the root, by ICANN to ccTLDs with which there are no for formal agreement.
  • In the ICANN routine of yearly operational and budget planning [PDF], ICANN lowered, at least nominally, the expectations for DNS root zone singing by qualifying the activity description with the phrase “Determine timetable, coordination requirements and costs for full deployment”.

That is for policy-related signals. Turning to the technology and demand rationale for DNSSEC deployment, the picture is somehow more definite. At the time of this writing, from a technology development perspective, the DNSSEC protocols are almost ready for wide scale deployment, and at least one ccTLD supports it (the Swedish registry, .se). The specific protocol areas where developments are still under way include mainly:

1) solving a privacy issue (not to be confused with data confidentiality which is not part of DNSSEC) referred to as “zone walking” prevention, or “NSEC3” as a technical buzzword for the solution being finalized,

2) the trust anchor key rollover issue, a protocol development item that merges into the “root signing” activity (this is the area in which I am involved),

3) some further testing might be required to strengthen the confidence that DNSSEC is adequate for full-scale deployment.

Beyond the mere observation that the current DNS implementation lacks cryptographic assurance security, the demand for DNSSEC deployment comes from an overall concern with Internet e-commerce insecurity, and from specific needs for a distribution channel for public keys, the latter supporting spam-prevention schemes (a potential killer-application for DNSSEC?) and ubiquitous encryption key distribution (a nightmare for “national security” premises?). The materialization of such DNSSEC benefits requires more software development on the DNS resolver side and end-user applications, but since deployment must start somewhere, why not at the DNS root and TLDs!

Perhaps a characteristic of the DNSSEC technology deserves a special note to observers of the DNS governance: while a secure delegation (DS resource record) parallels the plain DNS delegation (NS resource records) along the name hierarchy, they are otherwise independent relationships. It means that almost nothing from the existing ICANN policy for namespace management can be taken for granted when defining policy for DNSSEC support. Here are a few of the questions that may arise:

  • Once the cost structure of DNSSEC deployment is better understood, how does it fit the contractual arrangements and business models established by ICANN, with a possible impact on fee structure?
  • As hinted above, will ICANN tie the secure delegation to ccTLDs to a formal agreement with the ccTLD administrations?
  • How much of the PKI Certification Authority policy issues will be carried to ICANN in its role of a globally trusted organization for public key cryptography support? (After all, since DNSSEC is analogous to a streamlined PKI, can ICANN make it a policy-deprived PKI?)
  • In this process, will some governments attempt to ban DNSSEC-backed encryption key distribution?

I’m getting more and more convinced that DNSSEC deployment momentum can only occur through TLD administrations involvement, with focus on their respective understanding on the DNS institutional and policy issues. If you think of TLDs as independent entities deploying cryptographic assurance to the DNS data they publish, with their own requirements and conditions as they see fit, you just whish there is a higher level of technical coordination, acting merely as an agent of each enrolled TLD. Gone the view that ICANN empowers TLDs to do something, e.g. provide DNSSEC value added name registrations. After all, the ICANN board justified the .xxx rejection by its inability to cope with the diversified societal and legal environments that make up the global Internet.

Filed Under


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet




Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API

New TLDs

Sponsored byRadix

Brand Protection

Sponsored byCSC

IPv4 Markets

Sponsored byIPv4.Global


Sponsored byDNIB.com

Domain Names

Sponsored byVerisign