Root zone


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.


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,, and 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.




ICANN is responsible for coordinating the evolution and operation of the Domain Name System.


ICANN is responsible for coordinating the evolution and operation of the Domain Name System. The organisation coordinates the allocation and assignment of names in the root zone of the DNS, and the development and implementation of policies concerning the registration of second-level domain names in generic top-level domains (gTLDs). It also facilitates the coordination and evolution of the DNS root name server system. When it comes to gTLDs, ICANN concludes agreements with registry operators (for the administration of each gTLD), and accredits registrars. In the case of country code top-level domains (ccTLDs), ICANN only goes as far as (re)delegating them on the basis of some high-level guidelines.


IANA is responsible for the operational coordination of the DNS, through the so-called IANA functions, current


IANA is responsible for the operational coordination of the DNS, through the so-called IANA functions, currently performed by ICANN’s affiliate Public Technical Identifiers. IANA operates and maintains the DNS root zone, through, for example, evaluating requests to change operators of top-level domains and ensuring day-to-day maintenance of the details of existing operators. It also operates and maintains the .int and .arpa domains, and keeps a repository of Internationalised Domain Names ‘tables’ which document the permissible characters for different languages and scripts provided for registration by different TLD registries. In addition, IANA acts as operator of the Key Signing Key for the DNS root zone.


Up to October 2016, Verisign acted as the maintainer of the DNS root zone on the basis of a cooperative agreem


Up to October 2016, Verisign acted as the maintainer of the DNS root zone on the basis of a cooperative agreement with the US government. Following the transition of the IANA  IANA stewardship from the US government to the global Internet community, Verisign has continued to perform this role, in line with an agreement signed with ICANN. In virtue of this role, Verisign operates changes in the root zile (e.g. adding a new gTLD) and distributes the revised root zone file to root name servers. The company also manages 2 of the 13 root servers hostnames.


The core mission of the IETF is to develop technical standards for the Internet, ranging from Internet protoco


The core mission of the IETF is to develop technical standards for the Internet, ranging from Internet protocols (e.g. IPv4 and IPv6) and the Domain Name System (e.g. aspects related to the functioning of Internationalised Domain Names), to routing systems and security issues. Areas of work covered by IETF working groups include applications (e.g. real time communication and audio/video transport), Internet protocols, operations and management (e.g. DNS operations, routing operations, network configuration), routing (e.g. inter-domain routing, tunneling protocol extensions), security and transport (e.g. authentication and authorisation, IP security maintenance and extensions, and transport layer security).


As a committee of the IETF, the IAB has paid attention to issues related to the functioning of the Domain Name


As a committee of the IETF, the IAB has paid attention to issues related to the functioning of the Domain Name System root zone. In 2000, the Board issued a Technical Comment on the Unique DNS Root, stating that, ‘to remain a global network, the Internet requires the existence of a globally unique public name space’, and therefore advising against the deployment of multiple public DNS roots. The IAB has also contributed to ICANN-launched consultations and discussions on issues such as the root zone Key Signing Key rollover and the impact on the DNS root system of increasing the size and volatility of the root zone.


In addition to acting as a regional Internet registry, RIPE NCC is also one of the 12 root server operators, a


In addition to acting as a regional Internet registry, RIPE NCC is also one of the 12 root server operators, and it has been operating since 1997. Through the so-called K-root server, RIPE NCC published the DNS root zone in line with relevant technical standards and best practices, and with its own governance processes. The organisation advocates for a single, unique DNS root, as a vital condition for a stable and universally reachable Internet. Starting 2005, RIPE NCC has been working on expanding its K-root anycast network, ‘in order to improve K-root service for all users on the Internet’.



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

Other Instruments



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


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


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