Root Name Servers: The Foundation of the Global DNS System

At the very top of the Domain Name System hierarchy sits a small set of servers that make the entire internet’s naming system possible: the root name servers. Every single DNS lookup on the internet — every website visit, every email sent, every app that connects to a server — ultimately traces back to these servers. Yet most people who use the internet daily have no idea they exist. This guide explains what root name servers are, how they work, who operates them, and why they are simultaneously the most critical and most resilient infrastructure on the internet.

What Are Root Name Servers?

Root name servers are the authoritative name servers for the DNS root zone — the topmost level of the Domain Name System hierarchy. They hold the master list of all top-level domains (TLDs) and the name servers responsible for each one.

When a DNS resolver needs to resolve a domain name it does not have cached, it starts at the top of the hierarchy: it contacts a root name server and asks, in effect, “Where can I find the name servers for .com?” (or .nl, or .org, or any other TLD). The root server’s answer points the resolver to the correct TLD name server, which then points to the domain’s own authoritative name server.

Root servers do not know the IP address of any specific domain — they only know where to find the TLD name servers for each extension. They are the starting point of every DNS lookup that is not already cached.

Why Only 13 Root Server Addresses?

There are officially 13 root name server addresses, designated by the letters A through M (a.root-servers.net through m.root-servers.net). This number is often misunderstood as a physical limitation, but it is actually a technical constraint from the early DNS design.

The original DNS protocol used UDP packets with a maximum size of 512 bytes for DNS queries and responses. A response from a root server listing all 13 root server IP addresses needed to fit within this 512-byte limit. The number 13 was the maximum number of IPv4 addresses that could fit within this constraint while leaving room for other necessary response data.

This limitation is now largely historical — modern DNS supports larger packet sizes via EDNS0 (Extension Mechanisms for DNS), and DNSSEC signatures make DNS responses considerably larger. But the 13-address structure has been maintained for consistency and backward compatibility.

Anycast: Why 13 Addresses Means Thousands of Servers

The critical insight that most people miss: the 13 root server addresses do not correspond to 13 physical servers. Through a routing technique called anycast, each address is shared by dozens to hundreds of physical server instances distributed around the world.

With anycast, multiple servers worldwide are assigned the same IP address. When a DNS resolver sends a query to that IP address, internet routing protocols automatically direct the query to the geographically nearest instance of that server. This means:

• There are over 1,700 physical root server instances globally as of 2026
• Queries are handled by the nearest instance, minimising latency
• If one instance fails, queries are automatically routed to the next nearest instance
• The system handles enormous query volumes with built-in geographic redundancy

The root server system receives over 1 trillion DNS queries per day — and responds to them with extraordinary reliability.

Who Operates the Root Name Servers?

The 13 root server addresses are operated by 12 independent organisations — one operates two of the 13 addresses (Verisign operates both A and J). The operators are a diverse mix of US government agencies, academic institutions, nonprofit organisations, and commercial companies:

The diversity of operators is intentional. No single government, company, or organisation controls more than a fraction of the root server system. This distribution is a deliberate design choice to prevent any single point of control or failure.

How Root Servers Are Coordinated: The Root Zone

The authoritative data that root servers hold is called the DNS root zone — a file containing the name servers for every top-level domain. ICANN’s IANA function maintains the root zone and publishes it. The technical operation of the root zone (actually serving it from the A and J servers and coordinating publication) is performed by Verisign under contract with ICANN and the US Department of Commerce.

When ICANN approves a new TLD (like .shop or .amsterdam), IANA adds the new TLD’s name server records to the root zone. This update propagates to all root server instances worldwide, making the new TLD resolvable by any DNS resolver globally — typically within hours of the update.

The root zone file is publicly available and contains approximately 1,500 TLD entries as of 2026. Each entry specifies which name servers are authoritative for that TLD, enabling the entire global DNS hierarchy to function.

Root Server Attacks: Can the Internet Be Taken Down?

Root name servers have been the target of distributed denial-of-service (DDoS) attacks multiple times in the history of the internet. The most notable incidents:

• October 2002 — A DDoS attack targeted all 13 root server addresses simultaneously. Nine of the 13 were impacted, but only two suffered significant degradation. Most internet users noticed nothing. Anycast infrastructure was limited at the time; the incident accelerated the deployment of anycast globally.
• February 2007 — Another coordinated DDoS attack against root servers, this time affecting six of the 13 addresses with performance degradation. Again, internet performance was largely unaffected due to caching and anycast redundancy.
• November 2015 — A 5.6 million query-per-second DDoS attack against the root. Traffic was absorbed without notable impact on end users.

Why do these attacks fail to disrupt the internet?

• Caching — Most DNS resolvers cache TLD name server information for 24–48 hours. Even if root servers became completely unreachable, most DNS queries would be answered from cache for at least a day.
• Anycast distribution — Attacking one root server address means attacking hundreds of geographically distributed instances simultaneously — an enormously resource-intensive task.
• Redundancy — The 12 operators are independent. Taking down one operator’s servers does not affect the others.
• DDoS mitigation — Root server operators invest heavily in traffic scrubbing and DDoS mitigation infrastructure.

The root server system is arguably the most resilient piece of internet infrastructure ever built.

The Root Zone Signing Key: DNSSEC at the Top

The root zone is signed with DNSSEC — the cryptographic extension to DNS that enables resolvers to verify the authenticity of DNS responses. The root zone’s signing key is called the Root Zone Signing Key (RZSK) or KSK (Key Signing Key).

ICANN manages the root DNSSEC KSK through a highly ceremonial key management process — physical key ceremonies conducted in secure facilities with multiple trusted community representatives, witnessed and recorded for transparency. The root KSK was first generated in 2010 and has been rolled (replaced) once, in 2018, in the first-ever root zone KSK rollover — a carefully managed global event that required coordination with DNS operators worldwide.

All DNSSEC trust chains worldwide ultimately derive from this root signing key. When you enable DNSSEC for your domain, the chain of trust that protects your DNS records ultimately traces back to ICANN’s root zone signing key.

Frequently Asked Questions

What happens if all root name servers go offline?

In theory, if all root server instances worldwide went offline simultaneously, new DNS lookups for uncached domains would eventually fail as caches expired. In practice, this scenario is effectively impossible — the geographic distribution, operator diversity, and anycast infrastructure make a simultaneous global outage of all root servers essentially inconceivable. Individual operator outages have occurred without measurable internet disruption.

Why are there only 13 root server addresses instead of more?

The number 13 was dictated by the 512-byte UDP packet size constraint of the original DNS protocol — 13 was the maximum number of IPv4 addresses that fit in a root server response. Modern DNS supports larger packet sizes via EDNS0, but the 13-address structure has been maintained for backward compatibility. The anycast architecture multiplies each address across hundreds of physical servers, so the practical capacity is far greater than 13 servers would imply.

Can I query the root name servers directly?

Yes. Root servers are publicly queryable. Using the dig command: dig @a.root-servers.net com NS queries the A root server for the NS records of .com. ICANN publishes the complete list of root server addresses and supports tools for querying them directly. Root servers also publish their own A and AAAA records at root-servers.net for the use of DNS operators.

Does my website depend on root name servers?

Indirectly, yes — but through caching, the dependency is minimal for day-to-day operation. Your domain’s TLD name server records are cached by resolvers worldwide with TTLs of 24–48 hours. A root server outage would only begin to affect your domain’s resolvability after caches expire — and by then, root servers would almost certainly be restored. Your direct operational dependency is on your own authoritative name servers, not on root servers.

Conclusion

Root name servers are the invisible foundation beneath every internet communication. Their 13 addresses — operated by 12 independent organisations, replicated across 1,700+ global instances — answer over a trillion queries daily with extraordinary reliability. They are the starting point of every uncached DNS lookup and the ultimate authority on which TLDs exist and where to find them.

Understanding root servers provides the clearest view of how the internet’s naming infrastructure is designed: distributed, redundant, independently operated, and remarkably resilient. The fact that most internet users never notice root servers — even during attacks against them — is the highest possible compliment to their design.

Continue with: How DNS Works · ICANN Explained · DNSSEC Explained.