At the very top of the DNS hierarchy sits the root zone — the starting point for every DNS query. The servers that host this zone are called root servers, and they’re arguably the most critical infrastructure on the internet. Understanding how they came to be and how they operate reveals the delicate balance of technical necessity and geopolitical complexity that shapes internet governance.
The Root of Everything
When your computer needs to look up www.example.com, the journey starts at the root. Here’s the simplified process:
- Your resolver contacts a root server: “Who handles
.com?” - Root server responds: “Try these nameservers for
.com” - Your resolver contacts the
.comserver: “Who handlesexample.com?” - And so on down the hierarchy
The root servers don’t know about every domain — they only know who’s responsible for each top-level domain (TLD). But this makes them the foundation. Without root servers, DNS cannot function.
The Original Deployment
When DNS launched in 1984, there was one root server. It ran at SRI-NIC, the same organization that had maintained HOSTS.TXT.
But a single root server was a single point of failure. The DNS design anticipated this — RFC 882 specified that zones should have multiple nameservers. The root zone was no exception.
By 1985, additional root servers came online:
| Letter | Original Location | Original Operator |
|---|---|---|
| A | SRI-NIC (Menlo Park, CA) | SRI International |
| B | USC-ISI (Marina del Rey, CA) | USC-ISI |
| C | PSI-NET (later BBN) | Various |
| D | University of Maryland | UMD |
| E | NASA (Moffett Field, CA) | NASA Ames |
| F | Internet Software Consortium | ISC |
| … | … | … |
The lettering scheme (A through M) remains today, though most original operators have changed.
Why Thirteen Letters?
A common question: why exactly 13 root servers (A through M)?
The answer is practical: DNS responses originally had to fit in a 512-byte UDP packet. With name compression, you could fit about 13 root server records in that space. Thirteen was the maximum, so thirteen it was.
Today, with EDNS allowing larger packets, we could theoretically have more root letters. But changing such fundamental infrastructure is politically and operationally difficult, so thirteen letters remain.
The Root Server Operators
As of today, twelve organizations operate the thirteen root server letters:
| Letter | Operator | Headquarters |
|---|---|---|
| A | Verisign | USA |
| B | USC-ISI | USA |
| C | Cogent Communications | USA |
| D | University of Maryland | USA |
| E | NASA | USA |
| F | Internet Systems Consortium (ISC) | USA |
| G | U.S. DOD NIC (DISA) | USA |
| H | U.S. Army Research Lab | USA |
| I | Netnod | Sweden |
| J | Verisign | USA |
| K | RIPE NCC | Netherlands |
| L | ICANN | USA |
| M | WIDE Project | Japan |
Notice the geographic concentration — 10 of 13 letters are operated from the United States. This reflects DNS’s ARPANET origins but has been a source of international tension.
Anycast: Thirteen Letters, Thousands of Servers
Here’s the key insight: thirteen root server “letters” doesn’t mean thirteen physical servers.
Anycast allows multiple physical servers to share the same IP address. When you query the A root server (IP: 198.41.0.4), your packets automatically route to the nearest instance of that server.
Today’s root server deployment:
| Letter | Number of Instances | Global Locations |
|---|---|---|
| A | 12+ | Global |
| B | 6+ | Global |
| C | 8+ | Global |
| … | … | … |
| J | 200+ | Global |
| K | 100+ | Global |
| … | … | … |
| Total | 1,500+ | Worldwide |
What looks like 13 servers is actually over 1,500 instances distributed globally. This provides redundancy, reduces latency, and prevents any single location from being a bottleneck.
What the Root Zone Contains
The root zone itself is surprisingly small — about 2 MB. It contains:
NS Records for TLDs
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
...
org. 172800 IN NS a0.org.afilias-nst.info.
...
uk. 172800 IN NS ns1.nic.uk.
These records tell resolvers where to find the authoritative servers for each TLD.
DS Records for DNSSEC
com. 86400 IN DS 30909 8 2 ...
DS (Delegation Signer) records establish the chain of trust for DNSSEC validation.
Glue Records
a.gtld-servers.net. 172800 IN A 192.5.6.30
These A/AAAA records provide addresses for nameservers whose names are within the TLDs they serve.
The entire zone is publicly available and updates about twice daily.
Root Zone Management
Who controls what goes in the root zone? This question has geopolitical implications.
IANA Function
The Internet Assigned Numbers Authority (IANA) — now operated by ICANN — maintains the root zone database. They process requests to add, modify, or remove TLDs.
Verisign’s Role
Verisign, under a complex arrangement with ICANN and the US government, performs the technical operation of publishing and distributing root zone updates.
US Government Oversight (Historical)
Until 2016, the US Department of Commerce (via NTIA) had authority over root zone changes. This meant, theoretically, the US government could veto TLD additions.
In October 2016, this oversight ended as the IANA functions were transitioned to ICANN’s control.
The Root Server System Advisory Committee
The operators coordinate through RSSAC (Root Server System Advisory Committee), part of ICANN’s structure. RSSAC provides advice on root server operations and policy.
Resilience and Attacks
Root servers are constantly under attack — they’re obvious targets for anyone wanting to disrupt the internet.
DDoS Attacks
Major DDoS attacks have targeted root servers:
- October 2002: A coordinated attack affected 9 of 13 root servers
- February 2007: Another major attack, though anycast deployment limited impact
- November 2015: Multiple attacks over several days
Why They Survive
Root servers survive through:
- Anycast distribution (attack one location, others keep working)
- Massive overcapacity (normal load is tiny compared to capacity)
- Caching (most queries never reach root servers)
- Filtering and scrubbing (traffic cleaning by operators)
In practice, root server attacks have never caused widespread DNS failures. Caching means even if root servers were completely offline for hours, most DNS would keep working with cached data.
The Root Zone KSK Ceremony
With DNSSEC, the root zone has a “Key Signing Key” (KSK) that authenticates the entire DNS trust chain. Changing this key requires an elaborate ceremony:
- Held at secure facilities in Virginia or California
- Multiple “Trusted Community Representatives” attend
- Hardware Security Modules store key material
- Every step is recorded and audited
- Livestreamed for transparency
These ceremonies happen several times per year and represent the most critical cryptographic operations in internet infrastructure.
Key Takeaways
- Root servers sit atop the DNS hierarchy, directing resolvers to TLD nameservers
- Originally single instances, now 1,500+ instances worldwide via anycast
- Thirteen letters (A-M) reflect early UDP size limits, not current infrastructure
- Ten of thirteen operators are US-based, reflecting ARPANET origins
- The root zone itself is small (~2 MB) and updates twice daily
- Root servers survive constant attacks through anycast, caching, and overcapacity
- IANA/ICANN manages root zone content; Verisign handles technical distribution
Next
With root servers in place, the next question was: what top-level domains should exist? The answer came in 1985 with the creation of the original TLDs — .com, .net, .org, .edu, .gov, and .mil.