The implementation of DNSSEC and required development of a procedure to sign the DNS root zone file provides an opportunity to restructure the current political oversight exerted by the United States and achieve shared responsibility for the secure and stable operation of the Internet’s root zone. Specifically, multiple, but limited number of, non-governmental Root Key Operators (RKOs) should be responsible for generating, use and distribution of root zone key-signing keys (KSKs) and zone signing keys (ZSKs). In practice, this will require close coordination between RKO and RZM organizations in executing contractually agreed upon roles.

As shown below, the RKOs would be responsible for generating KSKs and ZSKs and transmitting the public portions of these keys to the RZM for construction of a Root Keyset. RKOs would be also responsible for distribution of the public portion of their KSK (i.e., the "trust anchor") globally. Once constructed, the Root Keyset would be distributed to the RKOs for signature over the complete set of keys. The signed Root Keyset is then returned to the RZM for inclusion in the RZF. Each RKO will then sign a copy of the root zone file using the private portion of their respective ZSKs and transmit it to the RZM who will merge the files. All of the exchange of data between RKOs and the RZM would occur on secure out-of-band channels. The merged RZF would then be distributed according to existing procedures. A resolver could utilize any one of the available KSK to authenticate the RZF contents.

Like any technical or procedural recommendation, there are benefits, risks and unknowns. Below, I identify some of them:

Eliminate threats of political interference

A prominent aspect of this proposal is the elimination of governmental organizations from the root zone management process. While the majority of domain names are currently registered in gTLD namespaces, the majority of TLDs in the root are ccTLDs and it is these namespaces which are experiencing strong growth. The issue of who controls delegation and redelegation of ccTLDs has always been sensitive, and the addition of Delegation Signer records to the root will only serve to amplify these concerns. Because of this, the direct involvement in root signing, or additional oversight of data flows between RKOs and the RZM, by any government is ill advised. It only serves to introduce risk, raise uncertainty among contracted parties, and undermine the credibility of the system. Moreover, it is unnecessary from an operations perspective. Cases of incorrect data being sent to another party can be remedied using operational quality control techniques like standards certification. Furthermore, given the openness of the DNS, any verification that an outside party would perform can be done by anyone if the process is done with minimum standards of transparency. The deployment of DNSSEC at the root is best left to the organizations that are contractually obligated for maintaining the RZF contents and should be let alone from potentially destabilizing interference created by government oversight.

The obvious risk of the process outlined above is that an RKO could alter the contents of the root zone file it signs and return it to the RZM for inclusion in the merged RZF. If this was the case, and the RZF were published, any resolver using the trust anchor from that "rogue" RKO could be directed unknowingly into an "alternative root." However, this risk is mitigated simply by incorporating audits at certain points in the process. E.g., prior to publication of the merged file, any inconsistencies could be identified by the RZM, thereby identifying the RKO which "went rogue." Similarly, any uncoordinated change introduced by the RZM could also identified by the RKOs auditing the merged zone contents prior to its distribution. Processing audits will add additional steps, however, is likely not to pose a significant operational hurdle. Even with the addition of DNSSEC RRs, the RZF will not be not a large data file. The current management of the RZF already incorporates digital signatures, error checking, and correction processes, so the existing parties are familiar with the techniques. And while auditing potentially slows down the root signing process, it should be recognized that rolling over the root's trust anchors is anticipated to be a fairly infrequent event. E.g., ISC outlines a security policy which rolls over the KSK for their DLV implementation one time per year. Nonetheless, any process that involves coordinating multiple parties and which may need to occur on an unscheduled basis will need to be well documented, tested, and transparent.

A key feature of the Internet's architecture and the DNS is decentralization. For instance, the DNS is distributed among many nameservers, another example is the anycasting of root servers. Decentralization of critical Internet resources increases robustness of the entire system, protecting it from intentional and unintentional attacks. Having multiple, coequal RKOs makes the DNSSEC architecture more resilient against temporary outages that might be suffered by a single RKO. Resolver operators could use any number of available RKO trust anchors to validate RZF contents depending on their desired level of assurance. Distribution of control over the RZF KSK among multiple entities is desirable from the viewpoint of a decentralized Internet.

Liability is a powerful negative incentive which could easily prevent organizations from signing the root. By involving multiple RKOs in the root signing process, potential liability associated with providing a signed RZF could be diffused. It could increase the variety of contracting arrangements between RKOs, the RZM and those relying on stable operation of a secure root. It is unknown in the proposed system what legal relationships may develop between RKOs, nameserver and resolver operators and under what jurisdiction these relationship may fall. Given the unique position held by RKOs as "root authorities," it may be necessary for them to gain international status to limit their liability. For example, just as common carriers in the US have limited liability, other governments and transnational organizations (e.g., the ITU) have also placed limitations of liability on specific telecommunications services. Another approach to consider may be the development of a safe harbor for RKOs. Safe harbors have been used in other Internet governance issues (e.g., EU-US data protection and the Communications Decency Act), where an actors liability is made conditional only upon the non-compliance with some private rule regime.

A central question is determining how many and what organizations could be a RKO. This is an answer partially determined by any technical constraints, prior experience with other root authorities, and in all likelihood, market mechanisms. Technical constraints may include the number of keys in the Root Keyset, the number of keys used to generate signatures for the root zone data, properties of the keys such as size and algorithm used, response message size constraints, and the need to rollover keys periodically. Some of these constraints have policy dimensions as well, for instance, the choice of key size and algorithm used.

A secured DNS is not unlike a public PKI (Public Key Infrastructure). It is a combination of products, limited digital signature services, facilities, policies, procedures, agreements, organizations and people that provide for and sustain secure DNS queries and resolutions. Documentation concerning root authorities in other large-scale authentication chains (e.g., certificate authorities (CAs) in PKIs) could help identify what kind of organizations would be suitable to be a RKO. For example, the US General Accounting Office has provided examples of the risks facing and the internal control objectives associated with root certification authorities. Similarly, NIST has documented best practices for key management organizations which could serve as guidelines. Guidelines from other countries should be examined as well. At a global level UNCITRAL offers general remarks for characteristics that organizations within a PKI, including root authorities, should posses.

To date the development of broadly available public PKIs has been slow, with a mix of widely available CAs offering minimal liability protection, while more purpose-specific "private" CAs (i.e., it also includes substantial government efforts) have emerged for higher-risk scenarios. The levels of assurance provide by the digital signatures in each case varies accordingly. It is unclear at this time what level of assurance RKOs and other organizations involved in providing secure DNS information would be willing to provide.