At the very top of the DNS hierarchy sits the root zone — the starting point for every DNS query. The root is served by 13 server identities, operated by 12 independent organizations, distributed across over 1,500 physical locations worldwide.
This is the infrastructure that anchors the entire internet naming system.
The 13 Root Server Identities
The root servers are named A through M, each with its own IPv4 and IPv6 addresses:
| Letter | IPv4 Address | IPv6 Address | Operator |
|---|---|---|---|
| A | 198.41.0.4 | 2001:503:ba3e::2:30 | Verisign |
| B | 199.9.14.201 | 2001:500:200::b | USC-ISI |
| C | 192.33.4.12 | 2001:500:2::c | Cogent |
| D | 199.7.91.13 | 2001:500:2d::d | University of Maryland |
| E | 192.203.230.10 | 2001:500:a8::e | NASA Ames |
| F | 192.5.5.241 | 2001:500:2f::f | ISC |
| G | 192.112.36.4 | 2001:500:12::d0d | US DoD (DISA) |
| H | 198.97.190.53 | 2001:500:1::53 | US Army Research Lab |
| I | 192.36.148.17 | 2001:7fe::53 | Netnod (Sweden) |
| J | 192.58.128.30 | 2001:503:c27::2:30 | Verisign |
| K | 193.0.14.129 | 2001:7fd::1 | RIPE NCC |
| L | 199.7.83.42 | 2001:500:9f::42 | ICANN |
| M | 202.12.27.33 | 2001:dc3::35 | WIDE Project (Japan) |
These addresses are embedded in every recursive resolver’s “hints file” — the bootstrap that lets DNS resolution begin.
Why Exactly 13?
This number seems oddly specific. The reason is a technical constraint from the early 1990s.
A DNS response must fit within a single UDP packet. The original DNS specification (RFC 1035) set the maximum UDP payload at 512 bytes. A response containing all root server NS records plus their IPv4 addresses (A records) needed to fit within this limit.
The math works out to 13 as the maximum number of server identities that could be listed with their IPv4 addresses in 512 bytes. When IPv6 was added later, the same 13 identities were used.
Today, with EDNS0 allowing larger UDP payloads, this constraint is less relevant — but the 13-identity design persists for compatibility.
Who Operates Each One
The 12 organizations operating root servers represent a diverse mix:
Verisign (A-root, J-root)
The only commercial operator running two root identities. Verisign also operates the .com and .net TLD registries and performs the critical “root zone maintainer” function.
USC Information Sciences Institute (B-root)
Home of Jon Postel, DNS co-inventor. B-root has run continuously since the earliest days of DNS.
Cogent Communications (C-root)
A major internet backbone provider. Originally assigned to PSINet.
University of Maryland (D-root)
Academic institution with strong networking research programs.
NASA Ames Research Center (E-root)
Yes, that NASA. The space agency has operated E-root since 1991.
Internet Systems Consortium (F-root)
ISC also maintains BIND, the most widely deployed DNS server software. F-root is one of the most heavily anycast-distributed roots.
US Department of Defense / DISA (G-root)
The Defense Information Systems Agency operates G-root for the US military.
US Army Research Lab (H-root)
Another US government operation, focused on research.
Netnod (I-root)
A Swedish non-profit. The only root operator based entirely outside the US until WIDE and RIPE NCC joined later.
RIPE NCC (K-root)
The Regional Internet Registry for Europe, Middle East, and parts of Asia. K-root is heavily distributed across Europe.
ICANN (L-root)
The organization that coordinates DNS policy globally. L-root serves as ICANN’s direct infrastructure contribution.
WIDE Project (M-root)
A Japanese research consortium. M-root was the first root server in Asia.
Anycast: 13 Letters, 1,500+ Instances
Here’s the key insight: those 13 IP addresses are not 13 physical servers. Each root identity uses anycast routing to distribute queries across hundreds of physical servers worldwide.
How Anycast Works
With anycast, multiple servers announce the same IP address to the global routing system (BGP). When a query is sent to that IP, internet routing delivers it to the nearest announcing server (in network terms).
Example: A query for 198.41.0.4 (A-root) might go to:
- A server in Frankfurt for a European user
- A server in São Paulo for a Brazilian user
- A server in Singapore for an Asian user
All these servers have the same IP address. The network itself handles distribution.
Current Distribution
As of 2024, the combined root server infrastructure includes:
- 1,700+ physical instances across the 13 identities
- 200+ countries and territories
- Every continent (including Antarctica at times)
F-root alone has 300+ instances. Even the smaller root operators typically have dozens of anycast locations.
Why Anycast Matters
- Performance: Queries go to nearby servers, reducing latency
- Resilience: DDoS attacks affect only nearby instances; others keep serving
- Scalability: Add capacity by deploying more instances
- No single point of failure: Taking down “the root servers” would require attacking thousands of locations
The Root Zone File
The root zone is remarkably small — around 2MB of data containing delegations for approximately 1,500 TLDs.
What’s In It
The root zone contains:
- NS records: Nameservers for each TLD (.com, .org, .uk, etc.)
- A/AAAA records: IP addresses for TLD nameservers (glue)
- DS records: DNSSEC delegation signer records for TLDs
- DNSKEY records: Root zone’s own signing keys
That’s it. The root zone doesn’t contain information about individual domains — only TLD delegations.
Sample Root Zone Entry
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
; ... more NS records
com. 86400 IN DS 19718 13 2 8ACBB0CD...
a.gtld-servers.net. 172800 IN A 192.5.6.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
How Changes Are Made
The root zone update process involves multiple parties:
- TLD operator submits a change request (new nameserver, DS record update, etc.)
- IANA (part of ICANN) reviews and approves the request
- Verisign (root zone maintainer) incorporates the change into the zone file
- Root operators receive the updated zone and begin serving it
This process includes extensive verification to prevent unauthorized changes. A typical change takes 24-72 hours from request to global deployment.
DNSSEC and Root Signing
The root zone has been signed with DNSSEC since July 2010. This provides the trust anchor for the entire DNSSEC hierarchy.
The Root Keys
The root zone uses two types of keys:
Key Signing Key (KSK): Long-term key used to sign the Zone Signing Key. Currently a 2048-bit RSA key. The KSK’s public key hash is what DNSSEC validators trust.
Zone Signing Key (ZSK): Shorter-term key used to sign actual zone records. Rotated quarterly.
Key Signing Ceremonies
The root KSK is protected with extraordinary security measures. Generating or using this key requires a formal Key Signing Ceremony.
These ceremonies are:
- Held at two secure facilities (El Segundo, CA and Culpeper, VA)
- Attended by Trusted Community Representatives (TCRs) from around the world
- Completely scripted and audited
- Recorded on video
- Require multiple people with different keys/cards to proceed
The KSK private key is stored in Hardware Security Modules (HSMs) that require multiple smart cards and PINs to activate. No single person can sign with the root key.
The 2018 KSK Rollover
In October 2018, the root zone completed its first KSK rollover — replacing the original 2010 key with a new one. This was a years-long project requiring:
- Global coordination with resolver operators
- Extensive testing and outreach
- Multiple postponements to ensure safety
- Finally: the actual key change, transparent and anticlimactic (as intended)
The rollover succeeded because the DNS community had time to prepare. Future rollovers will be smoother now that the process is proven.
Priming and the Hints File
Every recursive resolver needs to know where to start. The hints file (or “root hints”) contains the 13 root server addresses.
; Root hints file
. 3600000 NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:ba3e::2:30
; ... more entries
Resolvers are configured with this file at installation. When they start, they can immediately query root servers.
Priming Query
On startup, well-behaved resolvers perform a priming query: they ask a root server for the current root NS records. This updates their cache with fresh data, ensuring they have current information even if the hints file is outdated.
Root Zone Stability
The root zone is one of the most critical pieces of internet infrastructure. Its stability comes from:
- Operational diversity: 12 different organizations, multiple countries
- Technical redundancy: 1,700+ anycast instances
- Conservative change process: Multiple review stages for any modification
- DNSSEC: Cryptographic protection against tampering
- Global monitoring: Root Server System Advisory Committee (RSSAC) oversight
Despite being a single logical zone, the root has no single point of failure. It’s designed to survive organizational failures, natural disasters, and targeted attacks.
Key Takeaways
- 13 root server identities (A through M) serve as the DNS starting point
- 12 organizations operate these identities, ensuring no single point of control
- Anycast distributes each identity across hundreds of physical locations
- The root zone contains only TLD delegations — about 1,500 entries
- ICANN/IANA/Verisign coordinate root zone changes with multi-party review
- DNSSEC root signing uses elaborate key ceremonies with community oversight
- Priming keeps resolver root data current even with old hints files
The root servers are both elegant and resilient — a distributed system that’s handled exponential growth while maintaining near-perfect uptime. In the next chapter, we’ll look at how zone data is stored and replicated: zone files and zone transfers.