Root zone

Updates

The Internet Corporation for Assigned Names and Numbers (ICANN) has published the final version of the revised Internationalised Domain Name (IDN) Implementation Guidelines. The document is the result of work that started in 2015, intending to update the most recent version of the guidelines, dating back to 2011. The new guidelines – which are now pending ratification from the ICANN Board of Directors – are addressed to top-level domain registries and registrars which offer, or plan to offer, IDN registration. The guidelines contain guidance on IDN registration policies and practices, and are designed to minimise the risk of cybersquatting and consumer confusion.​

In the context of the 61st meeting of the Internet Corporation for Assigned Names and Numbers (ICANN) – taking place this week in Puerto Rico - the New gTLD Subsequent Procedures Working Group presented a possible timetable for the launch of a new round of applications for new generic top-level domains (gTLDs). According to the working group, ICANN could, in a best-case scenario, open up a call for applications for new gTLDs in the first quarter of 2021, nine years after the 2012 new gTLDs round. For this timeline to be met, the ICANN community would need to be very efficient in going through the various preparatory stages (including, among others) the related policy development process within the Generic Names Supporting Organisation, a public comment period on the Applicant Guidebook, and the Board approving the policy. Given that, during the previous round, the Applicant Guidebook went through multiple revisions over a three-year period, some commentators believe that the 2021 timeline might be overly optimistic.

The Board of Directors of the Internet Corporation for Assigned Names and Numbers (ICANN) decided not to delegate the .corp, .home, and .mail generic top-level domains (gTLDs) because of concerns overs name collisions. As explained in the board's resolution, a 'name collision occurs when an attempt to resolve a name used in a private name space (e.g., under a non-delegated TLD, or a short, unqualified name) results in a query to the public Domain Name System (DNS)'. Otherwise put, the three strings were identified as being of high risk, as they could be identical to name labels used in private networks, which could then result in unintended and harmful consequences. The applicants are entitled to a full refund of their application fees.

Security Council of Russia instructed the Russian government to start talks among the BRICS countries (Brazil, Russia, India, China and South Africa) about the possibility to build an alternative DNS root server system, reports RBC news agency.  This system should be independent from the control of international organisations servicing current Internet infrastructure and be designed to protect the BRICS countries in the event of global Internet malfunctions. 

The Internet Corporation for Assigned Names and Numbers (ICANN) has announced the successful evaluation of Mauritania’s request for an Internationalised Domain Name (IDN) country code top-level domain (ccTLD). The IDN ccTLD, in Arabic script, is now pending delegation into the Domain Name System (DNS). At the moment, 58 IDN ccTLD requests for a total of 40 countries/territories have successfully passed through ICANN’s String Evaluation process. Of these, 56 IDN ccTLDs representing 38 countries/territories are delegated in the DNS root zone, with the remainder either readying to apply, or actively applying for delegation of the string.

As part of the preparations for the upcoming Root Zone Domain Name Systems Security Extensions (DNSSEC) Key Signing Key (KSK) rollover – scheduled for 11 October 2017 – the Internet Corporation for Assigned Names and Numbers (ICANN) has launched a testing platform for network operators and other interested parties to confirm whether their systems can handle the automated update process for the KSK rollover. Internet service providers, network operators, and others who have enabled DNSSEC validation must update their systems with the new KSK, and the testing platform is aimed to allow them to confirm that their infrastructure supports the ability to handle the rollover without manual intervention.

The root zone and root servers have traditionally attracted plenty of attention in policy and academic discussions. Some of the main debates have revolved around issues such as the risks associated with a possible collapse of root servers, and the feasibility and implications of alternative root systems.

The root zone is the highest level in the Domain Name System (DNS) technical 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 (PTI), 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. (Prior to the IANA stewardship transition, the root zone maintainer function was subject of a contract between Verisign and the US government.)

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.

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

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.

Alternative root server systems – feasibility and risks

While ICANN, via PTI, operates and manages the DNS root that most users of the public Internet rely on, there are also active alternative DNS roots. Organisations operating such roots offer their own top-level domains (usually different from the ones administered within the ICANN framework); end-users wishing to use such services need to reconfigure their network settings to deviate from the universal root to the alternative one. Examples of alternative roots include AlterNIC, Open NIC, New.net, and Name.space. Most of them were unsuccessful, accounting for only a few per cent of Internet users. One more recent project – the Yeti DNS Project – plans to ‘build a parallel experimental live IPv6 DNS root system to discover the limits of DNS root name service’.

Creating an alternative root name server system is technically straightforward. The main question is how many followers an alternative server would have, or, more precisely, how many devices on the Internet would point to it, when it came to resolving domain names. Without users, any alternative DNS becomes useless.

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, this 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 could rely on more effective tools, based, for example, on the filtering of web traffic.

A more solid argument is that any alternative root systems could lead towards the fragmentation and even, maybe, the ultimate disintegration of the Internet. Even though all root systems use the same system of IP numbers, they have different naming approaches and resolution techniques. It may happen that several root systems have the same domain names, but they resolve to different IP addresses (which host different content). Moreover, most of the alternative DNS roots are not interoperable – with ICANN’s DNS root or among themselves – thus breaking the principle of universal resolvability (according to which there is a single way to resolve a domain name into an IP address). Except for the cases when such alternative roots are used for strictly private purposes (e.g. within closed networks), their existence may prevent some parts of the Internet from reaching others. This fragmentation 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)

GIP event reports

DNS Quo Vadis – Addressing Challenges and the Future Functionality of the DNS (2018)
Discussions Related to Geographic Names of Countries and Territories at ICANN60 (2017)
Jurisdiction Issues in Focus at ICANN60 (2017)
DNS Abuse Discussions at ICANN60 (2017)

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

Processes

Click on the ( + ) sign to expand each day.
 

The GIP Digital Watch observatory is provided by

in partnership with

and members of the GIP Steering Committee



 

GIP Digital Watch is operated by

Scroll to Top