DNSSEC Deployment at the Root

By Thierry Moreau

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:

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:

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: Cybersecurity, DNS, DNS Security, ICANN, Internet Governance, Privacy, Spam, New TLDs