DNS Root Servers Explained: The 13 Servers That Run the Internet

There are 13 DNS root server identities, named A through M, operated by 12 organizations. Each identity has IPv4 and IPv6 addresses and can be served from multiple sites. Root servers provide TLD delegations; a recursive resolver with usable cached delegation information can skip a root query even when the final hostname is not cached. The IANA root-server list identifies the operators and current addresses.

What Are DNS Root Servers?

DNS root servers sit at the top of the DNS hierarchy. When a recursive resolver lacks a usable cached delegation, it can start at a root server. But calling it a "first stop" understates how narrow their role actually is.

A root server does exactly one thing: it answers the question "who is responsible for this TLD?" When your resolver asks a root server about docs.example.com, the root server doesn't try to resolve the full name. It looks at the rightmost label, .com, and responds with a referral: "I don't know about docs.example.com, but here are the authoritative name servers for .com. Go ask them."

That referral response contains NS records and glue records (IP addresses) for the TLD's name servers. The resolver takes that information and continues the chain, asking the .com servers about example.com, then asking the example.com authoritative servers about docs.example.com. The root server's job is done after that first referral.

This delegation model is what makes DNS scalable. No single system needs to know every domain. The root carries the delegated TLD information listed by IANA, rather than the individual registrations below each TLD.

How Root Servers Fit Into DNS Resolution

To understand where root servers sit in the resolution process, walk through what happens when you type docs.example.com into a browser:

Browser
  → Stub Resolver (OS-level)
    → Recursive Resolver (ISP or public like 8.8.8.8)
      → Root Server         "Who handles .com?"
        → TLD Server (.com) "Who handles example.com?"
          → Authoritative NS "docs.example.com = 93.184.216.34"

The recursive resolver is the one doing the heavy lifting. It walks down the delegation chain, starting at the root, collecting referrals at each level until it reaches an authoritative answer. The root server only participates in step one of that chain.

If you want to see this process in detail, I wrote a full walkthrough in How DNS Queries Work that traces a query from browser to authoritative answer. The root interaction is needed when the resolver lacks the relevant cached delegation information.

You can also observe this firsthand with the +trace flag in dig. Running dig +trace docs.example.com forces your resolver to walk the entire delegation chain from root to authoritative, showing every referral along the way. My dig command guide covers this and other diagnostic techniques.

The 13 Root Server Clusters

The most common question about root servers is: why 13? The answer is a protocol constraint from the early 1990s.

A DNS response over UDP must fit within 512 bytes without EDNS extensions. The root zone's NS response needs to include 13 NS records (the hostnames like a.root-servers.net) plus their IPv4 glue records (the actual IP addresses). Fitting 13 entries with their associated data is the practical maximum for a single 512-byte UDP packet. Go to 14 and the response would exceed the limit, forcing TCP fallback on every priming query, an unacceptable overhead at the scale root servers operate.

When IPv6 was added later, the response size grew beyond 512 bytes. EDNS(0) extensions (RFC 6891) solved this by allowing larger UDP payloads, but the 13-identity design was already entrenched. There was no compelling reason to add more root server identities when anycast could multiply capacity behind each one.

Here are all 13 root server clusters with their operators and network details:

A few things stand out in this table. Verisign operates two root server identities (A and J), making them the only organization running more than one. The operator mix is deliberately diverse, government agencies, academic institutions, nonprofits, commercial entities, and international organizations. This diversity is intentional: no single organizational failure, legal jurisdiction, or policy decision should be able to compromise all 13 roots.

Instance counts and deployment locations change as operators add or retire sites. Consult each operator’s current deployment information before quoting a count; the table records identities and addresses rather than a dated capacity estimate.

How Anycast Makes It Work

Anycast lets the same root-server address be served at multiple sites. Routing chooses one available announcement rather than assigning a separate DNS identity to every machine.

In a normal (unicast) setup, an IP address maps to exactly one machine in one location. Anycast breaks this assumption: the same IP address is announced via BGP from hundreds of different locations simultaneously. When a resolver in Tokyo sends a packet to 198.41.0.4 (A-root), BGP selects a route according to network policy and reachability. The selected site may be nearby, but geographic proximity is not guaranteed.

The benefits of anycast for root servers are substantial:

Latency. Distributed sites can shorten network paths, but the routing-selected instance is not guaranteed to be the geographically nearest one.

DDoS resilience. Distribution can spread traffic and isolate some attacks to part of the deployment. The outcome depends on routing, capacity, and mitigation; anycast does not guarantee that every attack is evenly distributed or absorbed.

Automatic failover. If an instance goes offline, it stops announcing the BGP route. Traffic automatically reroutes to another reachable instance with no manual intervention and no DNS-level changes. The IP address doesn't change; only the BGP routing table shifts.

Capacity scaling. Adding capacity means deploying a new instance and announcing the same prefix from the new location. No configuration changes needed on any resolver worldwide.

The 13 identities are stable names for distributed services. The number of sites and machines behind them is a separate operational metric, which changes over time.

The Root Zone File

Every root server serves the same data: the root zone file. This is the authoritative list of every TLD and its name servers. Here is what a snippet of it looks like:

com.                172800  IN  NS  a.gtld-servers.net.
com.                172800  IN  NS  b.gtld-servers.net.
com.                172800  IN  NS  c.gtld-servers.net.
a.gtld-servers.net. 172800  IN  A   192.5.6.30
a.gtld-servers.net. 172800  IN  AAAA 2001:503:a83e::2:30

For every TLD, the root zone contains NS records (which name servers are authoritative) and, where needed, glue records (the IP addresses of those name servers). It also carries DS records delegating DNSSEC trust to signed TLDs, plus the SOA, DNSKEY, RRSIG, and NSEC records required to operate and sign the zone itself. What it does not contain is data about individual domains: no A records for second-level domains, no MX records, no TXT records, just delegation.

The root zone is managed by IANA (a function of ICANN) and published by Verisign in their role as Root Zone Maintainer. The process for changes is deliberate: a TLD operator requests a change, IANA verifies it, and Verisign publishes the updated zone. Updates happen multiple times per day as TLD delegations change.

The file itself is surprisingly small, roughly 2MB. That's the entire top level of the global DNS hierarchy compressed into a file smaller than a typical JPEG photo. You can download the current root zone from internic.net, or query it directly:

dig . NS

This returns the 13 root server NS records and their glue addresses, the same data every recursive resolver needs to begin resolution.

The roughly 1,500 TLDs in the root zone represent every active top-level domain, from legacy TLDs like .com and .net to newer gTLDs like .app and .dev, plus country-code TLDs like .uk and .jp. You can explore the full directory of TLDs and their delegation details on the TLD directory.

Root Hints and Priming Queries

A recursive resolver needs to know the root server addresses before it can resolve anything. This creates a bootstrapping problem: how do you look up a DNS name when you don't have DNS yet?

The solution is the root hints file, a static file shipped with every recursive resolver containing the names and IP addresses of all 13 root servers. This file is built into BIND, Unbound, PowerDNS Recursor, and every other resolver implementation. It's not fetched from the network; it's compiled into the software.

When a resolver starts up for the first time, it sends a priming query, a direct NS query for the root zone (. IN NS) to one of the root server IPs from its hints file. The root server responds with the current, authoritative list of root servers. The resolver caches this response and uses it for all subsequent root referrals.

RFC 9609 (BCP 209, February 2025) defines this priming process, obsoleting the earlier RFC 8109. Note that the priming configuration need not be a file in any particular format: the RFC only requires the resolver to start with addresses for some root servers, and vendors ship that as a hints file, package configuration, or built-in defaults. The key insight is that the hints file doesn't need to be perfectly current. It just needs to contain at least one working root server IP address. As long as the resolver can reach any root server, the priming query will return the complete, current set.

Use the current IANA root-server list and hints rather than a copied address table when configuring a resolver. IANA announced B-root’s change from 199.9.14.201 to 170.247.170.2 for November 27, 2023, together with its IPv6 change. The 192.228.79.201 address belongs to an earlier stage of B-root’s history.

Do Root Servers Handle Every DNS Query?

No, and this is one of the most important things to understand about root servers. Aggressive caching means the vast majority of DNS queries never reach a root server.

Here's why: when a recursive resolver receives a root referral, it caches the response. The root zone NS records carry a TTL of 518,400 seconds, that's six days. The individual TLD NS records carry TTLs of 172,800 seconds, two days. A busy resolver that handles thousands of queries per second may only contact root servers once every couple of days per TLD, because the referral data stays cached.

RFC 8767 (Serving Stale Data) further reduces root server dependency. It allows resolvers to continue serving expired cached data when authoritative servers are unreachable, rather than returning SERVFAIL. This means that even if all root servers became temporarily unavailable, most DNS resolution would continue working for hours or even days on cached data.

Despite this caching, root servers collectively still handle substantial traffic, on the order of hundreds of thousands of queries per second across all 13 clusters. Studies of root server traffic consistently show that the majority of queries they receive are unnecessary: junk traffic from misconfigured devices, automated scanners, botnets, and applications that bypass local resolver caching. Legitimate, cache-miss queries from properly configured resolvers represent a relatively small fraction of total root server load.

This relationship between caching and root server load is directly connected to DNS propagation. When TTLs expire and resolvers re-query the delegation chain, that's the mechanism behind propagation delays. Root server referrals have long TTLs specifically to minimize the frequency of these re-queries.

Security and DNSSEC at the Root

The root zone was signed with DNSSEC on July 15, 2010, a date that represents one of the most carefully coordinated infrastructure changes in internet history. From that point forward, the root zone has been signed, and root servers return the relevant DNSSEC records when a query asks for them by setting the EDNS DO bit (RFC 4035 Section 3.1). A query without DO normally omits the accompanying authentication records; it does not make the underlying zone unsigned. Explicit queries for a DNSSEC record type are a separate case.

DNSSEC at the root works through a chain of trust:

1. The root zone has a Key Signing Key (KSK) and a Zone Signing Key (ZSK)
2. The root KSK is the trust anchor, it's hardcoded into validating resolvers
3. Each TLD in the root zone has a DS (Delegation Signer) record that links the TLD's DNSSEC keys to the root's signature
4. Resolvers can verify the chain from root KSK to root ZSK to TLD DS record to TLD keys, and so on down to individual domains

The root KSK is maintained through key ceremonies, quarterly events held at two secure facilities in the United States (El Segundo, California, and Culpeper, Virginia). These ceremonies involve multiple trusted community representatives, hardware security modules (HSMs), and physical safeguards. The ceremonies are filmed and publicly streamed as a transparency measure.

In October 2018, ICANN performed the first-ever root KSK rollover: replacing the original 2010 key with a new one. This required coordinating with every validating resolver on the internet to recognize the new trust anchor. The rollover was originally scheduled for October 2017 but was delayed by a year after telemetry suggested a significant number of resolvers hadn't yet picked up the new key. The successful rollover in 2018 demonstrated that the process works, but also highlighted how operationally complex root-level DNSSEC management is.

You can check whether a specific TLD has DNSSEC configured by looking up its DS records in the root zone, or use the DNS Inspector to query DS and DNSKEY records for any domain.

Common Misconceptions About Root Servers

"If root servers go down, the internet stops." Cached answers and delegations can keep some resolution working. Serve-stale behavior may help during outages, but duration depends on resolver policy, cached coverage, and the specific lookup; there is no guaranteed hours-to-days window for every service.

"There are only 13 root servers." There are 13 identities operated by 12 organizations. Their distributed service sites provide more redundancy than a literal 13-machine deployment.

"Root servers are all in the United States." Operator location and service location are different. Netnod (Sweden), RIPE NCC (the Netherlands), and WIDE (Japan) are three operators outside the United States. Anycast deployment sites are distributed internationally.

"Root servers store all domain records." Root servers know nothing about individual domains. They store only TLD delegations, roughly 1,500 entries. The root zone file is about 2MB. The actual domain records for .com alone would be hundreds of gigabytes.

"Querying a root server is slow." Latency depends on the route, service site, and network conditions. Cached delegations often avoid a root query altogether; measure the path rather than assuming a fixed latency.