Root Zone Management Transition Update: Preservation of Security, Stability and Resiliency
View translations of this blog:
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.