Skip to main content

Root Zone Management Transition Update: Preservation of Security, Stability and Resiliency

View translations of this blog:

العربية | Español | Français | Português | Pусский | 中文

Updated with documents on 29 June 2016.

On March 4, 2015, the U.S. National Telecommunications and Information Administration (NTIA) officially requested that ICANN and Verisign work together to develop a proposal on how best to transition the NTIA administrative role associated with root zone management in a manner that maintains the security and stability of the Internet’s domain name system. NTIA previously announced that the transition of this aspect of its administrative role was a process separate from but parallel to the IANA stewardship transition.

Verisign and ICANN submitted a proposal to NTIA that contained two primary elements. First, the teams would build and test a parallel root zone management system that would simulate root zone management functions without NTIA’s current authorization role. That system is now approaching the completion of its 90-day defect free testing phase. Second, in anticipation of the release of Verisign from root zone management obligations by NTIA under the Cooperative Agreement, the teams began work on a commercial agreement between ICANN and Verisign for the continued performance of root zone management functions.

We are pleased to announce that ICANN and Verisign have completed the discussions and negotiations for the root zone maintainer services agreement (RZMA).

Since the early days of the Internet, Verisign has been providing “registration services” under its Cooperative Agreement with NTIA, which was broadly defined to include root zone management functions and Top Level Domain registry services. NTIA recognized that root zone management aspects of the IANA functions contract are “inextricably intertwined” with the Cooperative Agreement. Given the unified nature of the present Cooperative Agreement, much of the root zone infrastructure itself is “inextricably intertwined” with Verisign’s TLD operations for .com: the servers that provide root services are hosted at every .com resolution site (over 100 locations). These servers share bandwidth, routing and monitoring with the .com operations, and the servers use the same code base as the .com TLD name servers and are operated and maintained by the same operation and engineering group. On the provisioning side, the root zone’s provisioning system is derived from the .com Shared Registration System (SRS), using the structure, schema, and software used for .com provisioning operations. Verisign builds and signs the root zone today using the same cryptographic facilities used for .com as well as signing software derived from that used for signing .com. Importantly, Verisign’s root zone operations are also within the .com’s Denial of Service attack detection and mitigation framework including independent internal and external monitoring and packet filtering at all layers. A key component of ensuring security of the root operations was making sure that those operations continued to benefit from its historic association with the .com operations.

The RZMA is intended to maintain stable, secure, and reliable operations of the root zone not only for direct root zone management service customers (Registry Operators, Registrars and Root Server Operators), but also to maintain the security and stability of the Internet’s domain name system. This was achieved by a simple extension of the .com Registry Agreement to coincide with the term of the new RZMA.

Regarding the RZMA, some of the key features include:

  • Requiring Verisign and ICANN to work together in good faith to preserve the security, stability and resiliency of the root zone and root zone management system consistent with the security and stability of the Internet.
  • Detailing ICANN’s responsibility to authenticate, verify, and submit to Verisign changes to the service data comprised in the Root Zone File.
  • Establishing service level requirements for Verisign to process, edit, generate and publish the Root Zone File, including an accelerated path to update the service data in the Root Zone File in cases of emergency.
  • Describing ICANN and Verisign’s key-signing obligations, which are to be performed in a secure, transparent and accountable manner.
  • Providing that the integrity of the service data of the Root Zone File and the Verisign systems performing the root zone maintainer function will be operated under a business continuity plan with the same product support level as maintained by the .com DNS resolution service and .com SRS, respectively.
  • Setting forth that Verisign will participate as a member of the future Root Zone Evolution Review Committee.
  • Providing for continuity of the security and stability of the root zone through a one-year transition process which may be initiated by a community driven process under which Verisign continues to perform the root zone maintainer function while ICANN implements a public RFP process to identify and onboard a new provider.
  • Setting out the development of an emergency transition process for extraordinary events.
  • Requiring ICANN and Verisign to meet quarterly to prioritize potential changes and updates to the services, including service levels and to prioritize a roadmap for implementation of such changes that may be effected through a built in change control process.

What’s left to be done? Soon, we will post the RZMA for public review and the .com registry agreement amendment for public comment, after which our respective boards of directors will be asked to approve the agreements. The .com extension will be sent to NTIA for review and approval according to their processes.

On 29 June 2016, ICANN published the RZMA and the .COM Registry Agreement Amendment on its website.


    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."