Skip to main content

A Progress Update: Ensuring the Security, Stability and Resiliency of Root Zone Maintenance

On 10 March 2016, a plan to transition the IANA stewardship from the U.S. government's oversight to a global multistakeholder community was submitted to NTIA for consideration. Witnessing the extraordinary efforts of the multistakeholder community to develop these proposals has been impressive and humbling.

While the community has been working hard to finalize the proposals included in the plan, my team and I have been diligently preparing for the implementation phase of the anticipated IANA stewardship transition. One of the tasks that must be completed is for ICANN and Verisign to enter into a Root Zone Maintainer Agreement (RZMA). Another is to extend the .com Registry Agreement to run for the same term as the RZMA, which ICANN and Verisign believe enhances the security, stability and resiliency of the root zone infrastructure. Today, I want to provide you with some background information on the RZMA and an update on our progress.

As noted in the IANA Stewardship Transition Coordination Group (ICG) proposal, the complete and finalized transition requires revising the relationship between the current IANA Functions Operator (ICANN), the current Root Zone Maintainer (Verisign) and the current Root Zone Administrator (NTIA). Specifically, the role of NTIA will be eliminated and a written agreement between ICANN and Verisign establishing each party's role will need to be in place once that happens.

On 4 March 2015, NTIA officially requested that ICANN and Verisign work together to develop a proposal on how best to transition NTIA's administrative role associated with root zone management. Of paramount importance is accomplishing this in a manner that maintains the security, stability and resiliency of the root zone management process. ICANN and Verisign are close to having terms and conditions that accomplish this essential objective and that clearly define the respective roles and responsibilities of each party.

In general, we have already agreed that Verisign will be compensated for performance of the maintainer function and will have obligations to meet certain service-level agreements (SLAs) that the parties may adjust to address recommendations of the Customer Standing Committee pursuant to a change control process anticipated in the agreement. This change process is being defined to allow for the community to introduce through ICANN improvements to the Root Zone Management System as well. While the term of the RZMA is intended to promote the security, stability and resiliency of root zone maintenance operations by having Verisign continue in its role, the agreement also provides a capability for the community, through a consensus-based community-driven process, to cause ICANN to transition the function to another service provider after an agreed-upon number of years.

There are some remaining issues that need to be resolved before we finalize a draft of the agreement. It's difficult to enumerate these issues because discussions are ongoing and the status of the issues changes frequently. However, we are making good progress and expect to complete a draft soon.

Once ICANN and Verisign have completed the draft agreement, it will be posted for a 30-day community review period. This is in accordance with ICANN's transparency as well as in keeping with the recommendation in the ICG proposal to make the draft proposal available for public review prior to execution.

There is still work to do but we are making good progress. I encourage you to explore the web pages listed below for more information and to keep abreast of the latest developments.


    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."