Thirteen addresses, hundreds of sites
Thirteen addresses, hundreds of sites
Why the number is thirteen
The root of the DNS has thirteen addresses. Not twelve, not sixteen — thirteen, and the reason is a constraint that predates the modern internet by decades. Early DNS resolvers sent queries and received responses over UDP, and UDP packets in that era were commonly limited to 512 bytes in their DNS payload. A response carrying the full set of root server records — name, address, all of it — had to fit inside that envelope. Thirteen IPv4 addresses, each paired with a hostname, was roughly the maximum that could be packed in. The letter-labelled hostnames, a.root-servers.net through m.root-servers.net, follow directly from that arithmetic.
RFC 1035 ↗, published in 1987, established the 512-byte UDP limit as the baseline for DNS messages. EDNS0 — the extension mechanism described in RFC 2671 and later revised as RFC 6891 — eventually lifted that ceiling and allowed resolvers to advertise larger buffer sizes. But the thirteen addresses were already baked into every resolver's priming query and every cached hints file before EDNS0 arrived, and there was no practical reason to add more root letters. The constraint that created the number persisted long after the constraint itself was relaxed.
What the thirteen addresses label is not thirteen physical machines. Each address is a point of delegation, an administrative identity run by one of the root server operators ↗ — bodies including Verisign, ICANN itself, the University of Maryland, NASA's Ames Research Center, the U.S. Army Research Laboratory, and several others. The operators are distinct organisations with distinct infrastructure. The addresses are the fixed handles; what sits behind them is anything but fixed.
Anycast multiplies the machines
The real count of root server instances is measured in the hundreds, and it changes continuously as operators add or retire sites. Anycast is the mechanism that makes this possible. A single IPv4 or IPv6 address is announced from many physical locations simultaneously using BGP. When a resolver sends a query to 198.41.0.4 — the address for a.root-servers.net — the routing table does not lead it to a single machine. It leads it to whichever announcement of that prefix is topologically closest, according to BGP path selection.
The consequence for operators is that adding a new root server instance means nothing more than standing up a machine, loading the root zone onto it, and announcing the operator's address block from that location. No coordination with IANA is required. No new letter is minted. The address stays the same; the routing cloud quietly grows. For resolvers, the experience is transparent — they send to the same address they always have, and the query arrives at whichever instance is nearest.
This matters for latency and for resilience simultaneously. A resolver in São Paulo querying a.root-servers.net reaches an instance in South America rather than one in Virginia. A resolver in Johannesburg reaches an African instance. When anycast works as designed, root queries rarely cross an ocean, even though the number of root addresses never changed. The thirteen letters of the root are a naming layer; the physical infrastructure beneath them has been decoupled from that naming entirely.
Resilience follows from the same design. A volumetric attack aimed at a single operator's address hits whichever instances are closest to the attack traffic's origin — it does not automatically saturate every instance worldwide. The rest of the anycast cloud absorbs normal query load while the targeted instances either absorb or drop the attack. The distributed denial-of-service attacks launched against the root in 2002 and again in 2007 landed on a far smaller set of instances than operators run today; the expansion of the anycast footprint since then is partly a response to those events.
What the root zone actually contains
The root zone is a small file by the standards of zones that hold real content. It contains NS records and glue for every top-level domain — every delegation from the root downward. The authoritative data is maintained by IANA and published by Verisign, which operates the root zone's primary master. Every root server instance loads and serves an identical copy of this file. There is no specialisation by letter; a.root-servers.net and m.root-servers.net answer from the same zone data.
DNSSEC signing of the root zone began in 2010, when the root Key Signing Key was first generated in a ceremony with formal procedures and independent witnesses — a process that continues on a scheduled basis and is a matter of public record. The root's trust anchor is the starting point for a validator that wants to verify a signed answer from anywhere in the DNS hierarchy; without a correctly configured trust anchor for the root, DNSSEC validation cannot be initialised. The chain of signatures runs from the root KSK down through TLD keys and into zone keys, and every link depends on the root's signing being correct and verifiable.
Because every instance serves the same zone, the problem of consistency across the root's hundreds of physical sites is handled by the zone distribution mechanism, not by any per-instance configuration. Operators pull the root zone over AXFR or IXFR from Verisign's distribution system, or via other authorised distribution means, and serve it from local storage. A resolver asking any instance for the nameservers of .com will get the same answer regardless of which physical machine handles the query.
But the thirteen addresses were already baked into every resolver's priming query and every cached hints file before EDNS0 arrived, and there was no practical reason to add more root letters.
The hints file and the priming query
A recursive resolver does not start with knowledge of where to send its first query. It starts with a hints file — a static list of the thirteen root server names and their addresses — which is compiled into the software or distributed alongside it and updated occasionally as operator addresses change. The first time the resolver needs a root referral, it picks one of those addresses at random (or in round-robin order, depending on implementation) and sends a priming query: a query for the root zone's NS records. The answer fills the resolver's cache with fresh root server data and confirms which addresses are currently authoritative.
The hints file is therefore not the authoritative source; it is merely good enough to bootstrap. IANA publishes the current hints file, and the named.root file distributed by Internic ↗ is the canonical reference that resolver operators are expected to track. Software that ships with a years-old hints file will still work unless an operator's address has changed, because the priming query corrects the cache quickly — but stale hints that point to decommissioned addresses introduce unnecessary latency at startup.
Thirteen addresses, because of a 512-byte ceiling imposed before the web existed. Hundreds of machines, because BGP lets the same address be announced from anywhere on earth. The design is a clean example of a constraint becoming a convention, and a convention persisting long past the constraint — while the infrastructure underneath outgrew both.
The chain of signatures runs from the root KSK down through TLD keys and into zone keys, and every link depends on the root's signing being correct and verifiable.