"... In the Domain Name System (DNS) naming of computers there is a hierarchy of names. The root of system is unnamed. There are a set of what are called "top-level domain names" (TLDs). These are the generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two letter country codes from ISO-3166. It is extremely unlikely that any other TLDs will be created..."-- Jon Postel, March 1994, RFC 1591 (emphasis added)"... The requirement for uniqueness within a domain further implies that there be some mechanism to prevent name conflicts within a domain. In DNS this is accomplished by assigning a single owner or maintainer to every domain, including the root domain ... This is a technical requirement, not a policy choice ... There is one specific technical respect in which the root zone differs from all other DNS zones: the addresses of the name servers for the root zone come primarily from out-of-band information. This out-of-band information is often poorly maintained and, unlike all other data in the DNS, the out-of-band information has no automatic timeout mechanism. It is not uncommon for this information to be years out of date at many sites. Like any other zone, the root zone contains a set of "name server" resource records listing its servers, but a resolver with no valid addresses for the current set of root servers will never be able to obtain these records. More insidiously, a resolver that has a mixed set of partially valid and partially stale out-of-band configuration information will not be able to tell which are the "real" root servers if it gets back conflicting answers; thus, it is very difficult to revoke the status of a malicious root server, or even to route around a buggy root server. In effect, every full-service resolver in the world "delegates" the root of the public tree to the public root server(s) of its choice. As a direct consequence, any change to the list of IP addresses that specify the public root zone is significantly more difficult than changing any other aspect of the DNS delegation chain. Thus, stability of the system calls for extremely conservative and cautious management of the public root zone: the frequency of updates to the root zone must be kept low, and the servers for the root zone must be closely coordinated. These problems can be ameliorated to some extent by the DNS Security Extensions [DNSSEC], but a similar out-of-band configuration problem exists for the cryptographic signature key to the root zone, so the root zone still requires tight coupling and coordinated management even in the presence of DNSSEC. ..." --Internet Architecture Board, IAB Technical Comment on the Unique DNS Root, May, 2000, RFC 2826 (emphasis added)
From Verisign's Form 10-Q filed with the United States Securities and Exchange Commission on October 22, 2015, for the reporting period ending September 30, 2015 (emphasis and links added):
"We operate two root zone servers and are contracted to perform the Root Zone Maintainer function. Under ICANN’s new gTLD program, we face increased risk from these operations.
"We administer and operate two of the 13 root zone servers. Root zone servers are name servers that contain authoritative data for the very top of the DNS hierarchy. These servers have the software and DNS configuration data necessary to locate name servers that contain authoritative data for the TLDs. These root zone servers are critical to the functioning of the Internet. Under the Cooperative Agreement with the National Telecommunications and Information Administration (“NTIA”) of the DOC [U.S. Department of Commerce], we play a key operational role in support of the Internet Assigned Numbers Authority (“IANA”) function as the Root Zone Maintainer [see: http://www.ntia.doc.gov/legacy/DNS/CurrentProcessFlow.pdf ]. In this role, we provision and publish the authoritative data for the root zone itself multiple times daily and distribute it to all root server operators.
"Under its new gTLD program, ICANN has recommended delegations into the root zone of a large number of new gTLDs. In view of our role as the Root Zone Maintainer, and as a root server operator, we face increased risks should ICANN’s delegation of these new gTLDs, which represent unprecedented changes to the root zone in volume and frequency, cause security and stability problems within the DNS and/or for parties who rely on the DNS. Such risks include potential instability of the DNS including potential fragmentation of the DNS should ICANN’s delegations create sufficient instability, and potential claims based on our role in the root zone provisioning and delegation process. These risks, alone or in the aggregate, have the potential to cause serious harm to our Registry Services business. Further, our business could also be harmed through security, stability and resiliency degradation if the delegation of new gTLDs into the root zone causes problems to certain components of the DNS ecosystem or other aspects of the global DNS, or other relying parties are negatively impacted as a result of domain name collisions or other new gTLD security issues, such as exposure or other leakage of private or sensitive information.
"Additionally, DNS Security Extensions (“DNSSEC”) enabled in the root zone and at other levels of the DNS require new preventative maintenance functions and operational practices that did not exist prior to the introduction of DNSSEC. Any failure by Verisign or the IANA functions operator to comply with stated practices, such as those outlined in relevant DNSSEC Practice Statements, introduces risk to DNSSEC relying parties and other Internet users and consumers of the DNS, which could have a material adverse impact on our business.
"On March 14, 2014, the National Telecommunications and Information Administration announced its intent to transition key Internet domain name functions potentially impacting our Root Zone Maintainer function.
"On March 14, 2014, NTIA announced its intent to transition its oversight of the IANA function to the global multi-stakeholder community. NTIA asked ICANN to convene global stakeholders to develop a proposal to transition the current role played by NTIA in the coordination of the DNS. The NTIA is also coordinating a related and parallel transition of related root zone management functions. These related root zone management functions involve our role as Root Zone Maintainer under the Cooperative Agreement. At NTIA’s request, we submitted a proposal with ICANN to NTIA as how best to remove NTIA’s administrative role associated with root zone management in a manner that maintains the security, stability and resiliency of the Internet’s domain name system. We have performed the Root Zone Maintainer functions as a community service spanning three decades without compensation at the request of the Department of Commerce under the Cooperative Agreement. While it is uncertain how the transition of oversight of the IANA function and related root zone management functions will affect our role as Root Zone Maintainer, it is anticipated that performance of the root zone management function would be conducted by us under a new root zone management agreement with ICANN once the root zone management function obligations under the Cooperative Agreement are completed. Although our Root Zone Maintainer function is separate from our Registry Services business, and the NTIA announcement does not affect our operation of the . com, .net and . name or other registries, including the root zone, there can be no assurance that the transition of the IANA function, the transition of the related root zone management functions and associated transition processes will not negatively impact our business...."
Caveat Emptor!
Additional info:
- IANA — Root Servers
- Root Server Technical Operations Assn
- Root Zone File
- Root Hints File
- Root Trust Anchors
- Summary of the Impact of Root Zone Scaling (pdf) October 2010
- Scaling the Root (pdf) September 2009
- CDAR: Continuous Data-driven Analysis of Root Zone Stability | Presentation at ICANN 54 [PDF 434.31 KB]
Follow @DomainMondo
DISCLAIMER
