AddToAny

Printer Friendly and PDF

Root zone

Updates

11 Jan 2017

ICANN published the results of its annual survey measuring the satisfaction of IANA functions customers regarding the services they receive. In particular, the survey measures satisfaction in relation to documentation quality, process quality, transparency, timeliness, accuracy, reporting, and courtesy.The survey, which covered transactions completed between September 2015 and August 2016, showed that 99% of respondents were satisfied with the accuracy of their transactions, while 94% reported satisfaction in regard to transparency this year (an increase from 89 percent in the 2015 survey). In terms of satisfaction regarding process quality, the survey showed a drop to 89%, from 95% in 2015.

6 Jan 2017

ICANN and the US Department of Commerce have agreed to  terminate the Affirmation of Commitments (AoI), a 2009 document which outlined the two parties’ responsibilities towards each-other. Among its provisions, the AoI stressed out ICANN’s commitments to openness and transparency, and regular community reviews of its work. As noted by the US government, the termination of the agreement is a consequence of the completion of the IANA stewardship transition and the incorporation of the of the AoC framework into the revised ICANN bylaws.

2 Jan 2017

A report recently released by the Internet Society shows that, as of November 2018, 89% of all top-level domain names (TLD) have signed their zones with Domain Name System Security Extensions (DNSSEC). While all new generic TLDs have deployed DNSSEC at their root, only approximately 47% of all country-code TLDs (ccTLDs) have taken this step.  Deployment of the security extension for second-level domains vary widely; for example, over 50% of domains under .cz (the ccTLD for Czechia) are signed, while only about 0.5% of zones in .com are signed. Looking at the broader picture, the report notes that the ‘deployment of DNSSEC has made substantial progress since the root was signed in 2010’, and that ‘the major DNS servers and resolvers now ship with DNSSEC capability, and tools assisting DNSSEC operation are improving’.

Pages

The root zone and root servers have traditionally attracted plenty of attention in policy and academic discussions. The fact that the ultimate decision-making responsibility rests with one country, arguments in favour of the internationalisation of the control over root servers, and concerns over the single root server system have contributed to vibrant debates. The process to transition the stewardship of the functions of the Internet Assigned Numbers Authority (IANA) from the US government to the global multistakeholder community has also attracted significant attention.

 

The root zone is the highest level in the Domain Name System (DNS) structure. The root zone file contains the lists of names and Internet Protocol (IP) addresses of all top level domains (both generic top level domains - gTLDs and country code top level domains - ccTLDs) in the DNS.

How is the root zone managed?

The management of the root zone is carried out by the Internet Assigned Numbers Authority (IANA), whose functions are currently performed by the Public Technical Identifiers, an affiliate of the Internet Corporation for Assigned Names and Numbers (ICANN). In performing this role, PTI assigns the operators of top level domains and maintains a database with their technical and administrative details.

The maintenance of the root zone file itself is performed by VeriSign, on the basis of an agreement with ICANN. VeriSign’s role in this regard is to edit the file (at ICANN’s proposal), publish it, and distribute it to root server operators.

The DNS root zone is served by root servers – also known as authoritative servers, which keep the public copy of the root zone file. There is a misconception that the total number of root servers is 13. The fact is that there are hundreds of root servers scattered at various locations around the world. The number 13 comes from the 13 different hostnames, due to a technical limitation in the design of the DNS. Twelve entities – academic/public institutions (6), commercial companies (3), and governmental institutions (3) – manage these primary instances and ensure that all root servers within the same instance have the updated copy of the root zone file.

If one of the 13 hostnames crashes, the remaining 12 would continue to function. Even if all 13 went down simultaneously, the resolution of domain names into IP addresses (the main function of root servers) would continue on other domain name servers, distributed hierarchically throughout the Internet.

Therefore, hundreds of domain name servers contain copies of the root zone file and an immediate and catastrophic collapse of the Internet could not occur. It would take some time before any serious functional consequences would be noticed, during which time it would be possible to reactivate the original servers or to create new ones.

The system of root servers is considerably strengthened by the Anycast scheme, which replicates root servers throughout the world. This provides many advantages, including an increased robustness of the DNS and the faster resolution of Internet addresses (with the Anycast scheme, the resolving servers are closer to the end-users).

Alternative root servers – feasibility and risks

Creating an alternative root server is technically straightforward. The main question is how many followers an alternative server would have, or, more precisely, how many computers on the Internet would point to it, when it came to resolving domain names. Without users, any alternative DNS becomes useless. A few attempts to create an alternative DNS have been made: Open NIC, New.net, and Name.space. Most of them were unsuccessful, accounting for only a few percent of Internet users.  A more recent project - the Yeti DNS Project - launched in 2015, plans to ‘build a parallel experimental live IPv6 DNS root system to discover the limits of DNS root name service’.

Conceptual discussion: single vs alternative root server system

For a long time, the principle of the single root server was considered to be one of the main Internet mantras, which were not supposed to be touched or even discussed. Various arguments have been put forward in order to prevent any discussions about alternatives to the single root server. One argument is that the current (single root server) system prevents the risk of the DNS being used by some governments for censorship. However, the censorship argument against changes in DNS policy is losing ground on a functional basis. Governments do not need control over the DNS system or the root zone file in order to introduce censorship. They already rely on more effective tools, based on the filtering of Web traffic.

A more solid argument is that any alternative root servers could lead towards the fragmentation and even, maybe, the ultimate disintegration of the Internet, including one possible scenario of violent disintegration. The fragmentation of the Internet could endanger one of the core functions of the Internet – a unified global communication system.

Events

Instruments

Standards

Request for Comments (RFC) dealing with Root Zone (2015)

Other Instruments

Resources

Publications

Internet Governance Acronym Glossary (2015)
An Introduction to Internet Governance (2014)

Reports

State of DNSSEC Deployment 2016 (2016)
Root Zone KSK Rollover Plan (2016)
SSAC Report on the IANA Functions Contract (2014)
Impact on Root Server Operations and Provisions Due to New gTLDs (2012)

Other resources

Advisory on Measurements of the Root Server System (2016)
The IANA Functions: An Introduction to the Internet Assigned Numbers Authority (IANA) Functions (2015)
Root Zone Administrator Proposal Related to the IANA Functions Stewardship Transition (2015)
NTIA's role in Root Zone Management (2014)
Policy Brief on the Internet Root Zone (2014)
The Internet Domain Name System Explained for Non-Experts (2004)
Root Servers Technical Operations

The GIP Digital Watch observatory is a service provided by

 

in partnership with

 

and members of the GIP Steering Committee

 




 

GIP Digital Watch is operated by