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.

By Thierry Moreau

Related topics: DNS, DNS Security, ICANN, Internet Governance, Privacy, Security, Spam, Top-Level Domains

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:


To post comments, please login or create an account.

Related Blogs

Studying .BRAND New gTLDs

A Case to Further DNS Registrar Industry Self-Regulation

Loudmouths Wanted for ICANN WHOIS Replacement Work

Use STIX to Block Robocalls

How Long Does a URS Case Take?

Related News

Explore Topics

Promoted Post

Boston Ivy Gets Competitive With Its TLDs, Offers Registrars New Wholesale Pricing

With a mission to make its top-level domains available to the broadest market possible, Boston Ivy has permanently reduced its registration, renewal and transfer prices for .Broker, .Forex, .Markets and .Trading. more»

Industry Updates – Sponsored Posts

Radix Announces Largest New gTLD Sale with Casino.Online

2016 Year in Review: The Trending Keywords in .COM and .NET Domain Registrations

Global Domain Name Registrations Reach 329.3 Million, 2.3 Million Growth in Last Quarter of 2016

i2Coalition to Present Tucows CEO Elliot Noss With Internet Community Leadership Award

A Look at How the New .SPACE TLD Has Performed Over the Past 2 Years

Verisign Releases Q4 2016 DDoS Trends Report: 167% Increase in Average Peak Attack from 2015 to 2016

Michele Neylon Appointed Chair Elect of i2Coalition

Neustar to be Acquired by Private Investment Group Led by Golden Gate Capital

Startup League Reports from WebSummit, Lisbon

Verisign Q3 2016 DDoS Trends Report: User Datagram Protocol (UDP) Flood Attacks Continue to Dominate

2016 U.S. Election: An Internet Forecast

.SPACE Becomes the Choice of the First Ever Space Nation Asgardia

Government Guidance for Email Authentication Has Arrived in USA and UK

Afilias Chairman Jonathan Robinson Wins ICANN's 2016 Leadership Award at ICANN 57

ValiMail Raises $12M for Its Email Authentication Service

MarkMonitor Supports Brand Holders' Efforts Regarding .Feedback Registry

Don't Gamble With Your DNS

Why .com is the Venture Capital Community's Power Player

Defending Against Layer 7 DDoS Attacks

Understanding the Risks of the Dark Web

Sponsored Topics