FAQ: Understanding Root DNS Servers and the Root Zone

June 11, 2025

6 min read

Explore how DNS root servers operate, their distribution, security, and importance in this comprehensive Q&A on root servers and the root zone.

Arthur Kotylevskiy CEO @ Netlas.io

Tags:

Millions of devices communicate with Root DNS servers every day, often without users even realizing it. Yet, these servers are so crucial that the internet wouldn’t function without them.

In this post, I’ve gathered the most important information about Root DNS servers. I believe that presenting this information in the form of questions and answers is the clearest approach. Please feel free to leave a comment if I’ve missed any important details.

What Are Root DNS Servers, and What is the Root Zone?

Root DNS servers are the highest level of the global Domain Name System (DNS) hierarchy. They serve as the authoritative directory for the entire DNS, directing queries for any domain name to the next appropriate step.

When a resolver¹ needs to resolve a domain name that isn’t already cached, it starts by querying its local DNS server, as specified by the network configuration. If the local server cannot answer from its cache, it forwards the query to a root DNS server. Root DNS servers don’t store records for individual domains; instead, they maintain knowledge of all top-level domains (TLDs) such as .com, .org, .io, and country codes like .jp or .uk. The root zone acts as the authoritative directory for these TLDs, containing NS (Name Server) records that direct queries to the appropriate authoritative servers for each TLD.

Root DNS Server: is a server responsible for managing the root of the DNS hierarchy.
Root Zone: is the highest-level DNS zone containing a list of all TLDs and their associated authoritative name servers, serving as the foundation for the DNS resolution process.

Why Are Root DNS Servers Important?

Root DNS servers are the backbone for all domain name resolution on the internet. If the root servers become unavailable, DNS lookups for uncached domains across all services — including web, email, FTP, APIs, and more — would fail.

For most users, root servers are invisible. But their reliability and security are paramount: even a brief outage could disrupt access to countless global services and affect nearly every internet user.

How Does the DNS Hierarchy Work?

The Domain Name System is organized as an inverted tree of responsibility and authority:

At the top is the root zone, managed by root DNS servers.
The next level consists of top-level domain (TLD) servers, each responsible for a specific TLD like .com, .org, .net, or country codes such as .jp and .uk.
Below TLD servers are authoritative name servers for individual domains and subdomains, holding the specific DNS records for each domain name.

DNS queries traverses this hierarchy, starting at the root and moving step by step downward.

    flowchart TD
	    Root["Root Zone<br>(Root DNS Servers)"] --> TLD_IO["TLD Server: .io"] & TLD_UK["TLD Server: .uk"]
	    TLD_IO --> NS_NETLASIO["Authoritative NS for netlas.io"] & NS_DEMOIO["Authoritative NS for demo.io"]
	    TLD_UK --> GOV_UK["gov.uk"]
	    GOV_UK --> NS_GOVUK["Authoritative NS for gov.uk"] & NS_DEMOGOVUK["Authoritative NS for demo.gov.uk"]
	    NS_NETLASIO --> RR_NETLASIO["DNS Records:<br>A, MX, TXT for netlas.io"]
	    NS_DEMOIO --> RR_DEMOIO["DNS Records:<br>A, MX for demo.io"]
	    NS_GOVUK --> RR_GOVUK["DNS Records:<br>A, MX for gov.uk"]
	    NS_DEMOGOVUK --> RR_DEMOGOVUK["DNS Records:<br>A, MX for demo.gov.uk"]
	    
	    Root@{ shape: rounded}
	    TLD_IO@{ shape: rounded}
	    TLD_UK@{ shape: rounded}
	    NS_NETLASIO@{ shape: rounded}
	    NS_DEMOIO@{ shape: rounded}
	    GOV_UK@{ shape: rounded}
	    NS_GOVUK@{ shape: rounded}
	    NS_DEMOGOVUK@{ shape: rounded}
	    RR_NETLASIO@{ shape: rounded}
	    RR_DEMOIO@{ shape: rounded}
	    RR_GOVUK@{ shape: rounded}
	    RR_DEMOGOVUK@{ shape: rounded}

This distributed model ensures that no single server must store or serve all DNS data, making the system resilient and massively scalable. It’s a key reason why DNS can handle billions of requests daily with high reliability.

How Exactly Do Root DNS Servers Work in the Domain Resolution Process?

The DNS resolution process works as follows:

Local Resolver and Cache Lookup:
The device queries its configured DNS server (referred to as the “local” DNS server). If the local server does not have a valid cached entry for the domain, it initiates the recursive resolution process.
Contacting the Root Servers:
The local DNS server is pre-configured with the IP addresses of root DNS servers. It queries one of these servers to identify which authoritative servers are responsible for the relevant top-level domain (TLD), such as .io. These queries are directed to the nearest available root server instance using anycast routing.
Referral from the Root Server:
The root DNS server responds with a list of authoritative name servers for the requested TLD.
TLD and Authoritative Server Lookup:
The local DNS server then queries the TLD server (for example, .io), which refers it to the authoritative name server for the specific domain (such as netlas.io). The authoritative name server returns the requested DNS records.
Final Response and Caching:
The local DNS server provides the obtained IP address to the requesting device. This result is cached for a specified duration, known as the time-to-live (TTL)², allowing for quicker responses to future queries for the same domain.

Caching is critically important in DNS because it dramatically reduces the number of queries that need to reach root and TLD servers, allowing the system to efficiently handle global demand. It also improves speed for devices and users, since most queries can be answered instantly from the local cache rather than repeating the full resolution process.

How Many Root DNS Servers Are There, and How Are They Distributed?

There are 13 root server “letters” (A–M), each representing a logical server with its own IP address. However, the number “13” refers only to the logical servers, not the physical machines. In reality, there are thousands of physical servers distributed globally, with over 1,700 root server instances spread across more than 130 countries. These servers use IP Anycast routing, where multiple physical servers in different locations share the same IP address, ensuring that queries are automatically routed to the nearest or best-performing instance.

This design provides redundancy and resilience, meaning that even if many servers go offline, the system keeps functioning. The root servers are strategically distributed in data centers around the world, typically at major internet exchange points or close to large population centers.

Root Server on the map

Interactive maps and real-time locations of root servers are available on RootServers.org.

Who Manages and Operates the Root Zone and DNS Root Servers?

The Root Zone is overseen by the Internet Assigned Numbers Authority (IANA), which operates under the Internet Corporation for Assigned Names and Numbers (ICANN). IANA coordinates the content and changes to the root zone, while ICANN provides overall oversight and policy direction. Any updates, such as adding new TLDs or updating server addresses, undergo a controlled, transparent process before being cryptographically signed and published to global root server operators.

The responsibility for operating the 13 root server addresses (A–M) is shared among 12 independent organizations, including private companies, government bodies, and research institutions. Each organization is responsible for the maintenance, security, and operational stability of its respective root server cluster.

Root DNS Servers: Addresses and Operators
Server	Addresses	Operator
A	198.41.0.4 2001:503:ba3e::2:30	VeriSign, Inc. Reston, Virginia, USA
B	170.247.170.2 2801:1b8:10::b	University of Southern California (ISI) Los Angeles, California, USA
C	192.33.4.12 2001:500:2::c	Cogent Communications Washington, D.C., USA
D	199.7.91.13 2001:500:2d::d	University of Maryland College Park, Maryland, USA
E	192.203.230.10 2001:500:a8::e	NASA Greenbelt, Maryland, USA
F	192.5.5.241 2001:500:2f::f	Internet Systems Consortium (ISC) Cambridge, Massachusetts, USA
G	192.112.36.4 2001:500:12::d0d	US Department of Defense / NIC Arlington, Virginia, USA
H	198.97.190.53 2001:500:1::53	US Army (Research Lab) Adelphi, Maryland, USA
I	192.36.148.17 2001:7fe::53	Netnod Stockholm, Sweden
J	192.58.128.30 2001:503:c27::2:30	VeriSign, Inc. Reston, Virginia, USA
K	193.0.14.129 2001:7fd::1	RIPE NCC Amsterdam, Netherlands
L	199.7.83.42 2001:500:9f::42	ICANN Los Angeles, California, USA
M	202.12.27.33 2001:dc3::35	WIDE Project (Japan) Tokyo, Japan

The table is accurate as of the time of publication. For the latest updates, please refer to IANA’s Root Servers List or Root-Servers.org.

How are the Root Zone and Root DNS Servers Protected?

To safeguard the root zone, DNS Security Extensions (DNSSEC) are implemented, adding cryptographic signatures to DNS records to ensure data integrity and prevent unauthorized modifications.

The root zone was first signed with DNSSEC in 2010, marking a significant milestone in the evolution of global DNS security. This cryptographic chain of trust begins at the root and extends downward, enabling the verification of DNS data’s authenticity all the way to the end-users.

As mentioned earlier, root DNS servers are designed for maximum resilience. They are globally distributed across hundreds of locations, ensuring redundancy and improving performance. This design, coupled with resistance to DDoS attacks and local failures, guarantees that the system remains operational even if some instances go offline.

How Are Changes Made to the DNS Root Zone?

Modifying the root zone — the foundational “master list” of all top-level domains (TLDs) — is a highly controlled process. The Internet Assigned Numbers Authority (IANA), under ICANN’s oversight, coordinates, reviews, and implements all changes, which undergo technical validation and multi-party approval. Updates are only published after cryptographic signing and verification.

Common root zone changes include adding or removing TLDs (e.g., .app, .corp), updating name servers, or adjusting technical parameters for DNSSEC and other security measures. Given the potential impact on the entire internet, the process is designed to avoid errors that could cause disruptions or security risks.

Official information on root zone updates can be found through the IANA Root Zone Database, ICANN Announcements, and Root-servers.org.

A resolver is system software that receives DNS queries from client, performs the necessary recursive lookups, and returns the final answer. ↩︎
Time-to-Live (TTL) is a value specified in each DNS record that indicates how long the record can be cached by resolvers and clients before it must be refreshed from authoritative sources. ↩︎

Tags: