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.