Loading learning content...
Read aloud is unavailable in this browser.
Every time you type a domain name into your browser—whether it's google.com, wikipedia.org, or any of the billions of names on the Internet—a remarkable chain of events begins. At the very apex of this chain sit the DNS root servers: a small set of infrastructure components so critical that if they all failed simultaneously, the entire Internet would become largely unusable within hours as cached records expired.
Yet most users, and even many developers, have never heard of root servers. This invisibility is by design—like the foundation of a building, root servers are meant to be unseen, unheard, and utterly reliable. Understanding root servers is understanding the architectural apex of one of humanity's most important distributed systems.
By the end of this page, you will understand: (1) What root servers are and their role in DNS resolution, (2) The 13 root server identities and why there are exactly 13, (3) Anycast technology and how hundreds of physical servers operate as 13 logical servers, (4) Root server operators and governance, (5) Root zone file contents and management, and (6) The critical security and reliability mechanisms protecting root servers.
Root servers are the authoritative nameservers for the DNS root zone—the topmost zone in the DNS hierarchy, denoted by an empty string or a single dot (.). When you hear that DNS is hierarchical, root servers occupy the absolute peak of that hierarchy.
The fundamental role:
Root servers perform one specific but essential function: they answer queries about the top-level domains (TLDs)—the rightmost segment of domain names like .com, .org, .net, .uk, .de, and hundreds of others. When a recursive resolver needs to find where example.com lives but has no cached information, it must first ask a root server: "Who is authoritative for .com?"
The root server responds with referrals—specifically, the names and IP addresses of the TLD servers responsible for .com. This referral is the first step in the resolution chain that ultimately locates the authoritative server for example.com.
A common misconception is that root servers have knowledge of every domain. In reality, they only know about TLDs. They're the starting point for resolution—the 'first hop' when a resolver has no cached information about a domain's TLD. Root servers delegate everything else to the appropriate TLD servers.
Why the root zone exists:
The DNS namespace is conceptually an inverted tree:
. (root)
|
+-------+-------+-------+-------+
| | | | |
com org net uk de ... (TLDs)
| | | |
google wiki example co
| | |
www www bbc
Every domain name, when written fully, ends with a dot representing the root. So www.google.com is technically www.google.com. (with a trailing dot). We usually omit this dot in everyday use, but it's always implicitly there.
Root servers serve the . zone—the topmost node in this tree. They maintain the root zone file, which contains the complete list of TLDs and their associated nameserver information.
There are exactly 13 root server identities, named A through M, each operated by a different organization. These are identified by their naming convention:
This number—13—is not arbitrary. It stems from a fundamental constraint in the original DNS protocol design.
In the early 1990s, DNS queries and responses were limited to 512 bytes when using UDP (the preferred transport for DNS). The root server names and their IPv4 addresses had to fit within a single response. With 13 servers, each requiring a name pointer (about 4 bytes) and an IPv4 address (4 bytes) plus overhead, the response barely fits within 512 bytes. Adding a 14th server would exceed this limit, causing responses to be truncated and forcing TCP fallback, which was considered unacceptable for the root level.
| Identity | Operator | Location (HQ) | Notes |
|---|---|---|---|
| A | Verisign, Inc. | Reston, Virginia, USA | Also operates J root |
| B | USC-ISI | Marina del Rey, California, USA | One of the original roots; now operated by USC Information Sciences Institute |
| C | Cogent Communications | Herndon, Virginia, USA | Commercial ISP and network operator |
| D | University of Maryland | College Park, Maryland, USA | Academic institution operator |
| E | NASA Ames Research Center | Mountain View, California, USA | Government research operator |
| F | Internet Systems Consortium (ISC) | Redwood City, California, USA | Non-profit; also maintains BIND DNS software |
| G | U.S. Department of Defense (DISA) | Columbus, Ohio, USA | Military/government operator |
| H | U.S. Army Research Lab | Aberdeen, Maryland, USA | Military research operator |
| I | Netnod | Stockholm, Sweden | First non-US root operator; operates major European Internet Exchange |
| J | Verisign, Inc. | Reston, Virginia, USA | Also operates A root; global Anycast presence |
| K | RIPE NCC | Amsterdam, Netherlands | Regional Internet Registry for Europe, Middle East, and Central Asia |
| L | ICANN | Los Angeles, California, USA | Internet governance organization; operator of the IANA function |
| M | WIDE Project | Tokyo, Japan | Japanese academic networking organization |
The geographic and organizational diversity is intentional:
Early in DNS history, all root servers were located in the United States. This created concerns about:
Over time, root operations diversified. Today, three operators are outside the US (I, K, M), and more importantly, the use of Anycast means that physical root server instances exist on every continent.
IPv4 and IPv6 addresses:
Each root server identity has both IPv4 and IPv6 addresses. For example:
| Root | IPv4 Address | IPv6 Address |
|---|---|---|
| A | 198.41.0.4 | 2001:503:ba3e::2:30 |
| B | 199.9.14.201 | 2001:500:200::b |
| ... | ... | ... |
These addresses are hardcoded into DNS resolver software. This is the root hints file—a bootstrap file that allows resolvers to find root servers without needing to perform DNS lookups (which would be circular).
Although root server addresses rarely change, when they do, resolver software must be updated. Operating systems, BIND, Unbound, and other DNS software ship with root hints files that should be periodically updated. Stale root hints can cause resolution failures or inefficiencies.
The statement "there are 13 root servers" is technically accurate but misleading. While there are 13 identities (A through M), there are actually hundreds of physical root server instances distributed across the globe. This is made possible by Anycast.
What is Anycast?
Anycast is a network addressing and routing methodology where the same IP address is announced from multiple locations worldwide. When a client sends a packet to an Anycast address, the Internet's routing infrastructure delivers it to the nearest instance—determined by the network's view of the shortest BGP (Border Gateway Protocol) path.
How Anycast works for root servers:
Same IP, multiple locations: A root server operator (e.g., ISC for F-root) announces the same IPv4/IPv6 address from data centers in Tokyo, Amsterdam, São Paulo, Los Angeles, and many other locations.
BGP advertisement: Each instance advertises routes via BGP. Internet routers learn that 192.5.5.241 (F-root) is reachable via multiple paths.
Shortest path selection: When a resolver in Germany sends a query to F-root, German ISP routers select the instance with the best BGP path—likely the Amsterdam instance rather than one in Asia.
Identical responses: All instances serve the same root zone data, so clients receive correct, consistent answers regardless of which instance responds.
| Root Identity | Operator | Approximate Instance Count | Notable Presence |
|---|---|---|---|
| A | Verisign | ~10 | Major Internet Exchange Points |
| B | USC-ISI | ~6 | Limited deployment, primarily US |
| C | Cogent | ~10 | North America, Europe |
| D | University of Maryland | ~150+ | Extensive global Anycast |
| E | NASA | ~250+ | One of the largest deployments |
| F | ISC | ~250+ | Massive global footprint |
| G | DISA | ~6 | Limited, primarily military networks |
| H | Army Research Lab | ~2 | Minimal public instances |
| I | Netnod | ~70+ | Strong European presence |
| J | Verisign | ~200+ | Major commercial deployment |
| K | RIPE NCC | ~80+ | Europe, Middle East, Central Asia |
| L | ICANN | ~200+ | Globally distributed |
| M | WIDE Project | ~10 | Primarily Asia-Pacific |
Combined, the 13 root server identities are served by over 1,500 physical instances worldwide. This provides extraordinary redundancy, reduces latency by placing instances near users, and makes DDoS attacks far less effective—attackers must target all instances simultaneously to impact root server availability.
All root servers serve the same dataset: the root zone file. This file is deceptively small—usually around 2 MB—yet it represents the complete directory of all top-level domains on the Internet.
What the root zone contains:
The root zone file consists primarily of two types of records for each TLD:
For example, for the .com TLD:
123456789101112131415161718192021222324
; Excerpt from the root zone file; Last updated: example timestamp ; .com TLD delegationcom. 172800 IN NS a.gtld-servers.net.com. 172800 IN NS b.gtld-servers.net.com. 172800 IN NS c.gtld-servers.net.com. 172800 IN NS d.gtld-servers.net.com. 172800 IN NS e.gtld-servers.net.com. 172800 IN NS f.gtld-servers.net.com. 172800 IN NS g.gtld-servers.net.com. 172800 IN NS h.gtld-servers.net.com. 172800 IN NS i.gtld-servers.net.com. 172800 IN NS j.gtld-servers.net.com. 172800 IN NS k.gtld-servers.net.com. 172800 IN NS l.gtld-servers.net.com. 172800 IN NS m.gtld-servers.net. ; Glue records (addresses of .com servers)a.gtld-servers.net. 172800 IN A 192.5.6.30a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30b.gtld-servers.net. 172800 IN A 192.33.14.30b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30; ... (additional servers)Understanding glue records:
Notice a critical detail: the nameservers for .com are themselves in a .net domain (gtld-servers.net). But what if the nameservers were ns1.com and ns2.com—within the very zone they're supposed to serve?
This creates a chicken-and-egg problem: to resolve ns1.com, you need to query the .com servers, but to find those servers, you need to resolve ns1.com.
Glue records solve this. They're A/AAAA records included in the parent zone that provide IP addresses directly, bypassing the circular dependency. In the root zone, glue records ensure that TLD nameserver addresses are immediately available.
Root zone statistics:
| Attribute | Value | Notes |
|---|---|---|
| File size | ~2 MB (uncompressed) | Remarkably small for such critical data |
| Number of TLDs | ~1,500+ | Includes ccTLDs, gTLDs, and new gTLDs added since 2013 |
| NS records per TLD | Typically 2-13 | Most TLDs have multiple nameservers for redundancy |
| Update frequency | Multiple times daily | Changes occur when TLDs modify their nameservers |
| Serial number | YYYYMMDDnn format | Increments with each update; allows change detection |
| SOA refresh interval | 1800 seconds (30 minutes) | Secondary servers check for updates periodically |
The root zone is maintained through a collaborative process: (1) ICANN's IANA function processes requests from TLD registries for delegation changes, (2) Verisign, as the Root Zone Maintainer, implements these changes and generates the signed zone file, (3) Root server operators then retrieve and serve the updated zone. This separation ensures no single entity has unilateral control.
Understanding how root servers process queries is essential for grasping their role. Let's trace a complete query flow.
Scenario: A user in Singapore types www.example.org into their browser. Their local recursive resolver has an empty cache (cold start).
Step 1: Resolver consults root hints
The resolver's root hints file provides addresses for all 13 root server identities. The resolver selects one—typically based on past response times, randomization for load distribution, or explicit preference.
Step 2: Query to root server
The resolver sends a query to, say, F-root (192.5.5.241):
Query: www.example.org. IN A
Type: Standard Query
Recursion Desired: Yes (ignored by root)
Note: Root servers are authoritative only—they don't perform recursion, even if the Recursion Desired (RD) flag is set.
12345678910111213141516171819
; Response from F.root-servers.net; Status: NOERROR ;; QUESTION SECTION:;www.example.org. IN A ;; AUTHORITY SECTION:org. 172800 IN NS a0.org.afilias-nst.info.org. 172800 IN NS a2.org.afilias-nst.info.org. 172800 IN NS b0.org.afilias-nst.org.org. 172800 IN NS b2.org.afilias-nst.org.org. 172800 IN NS c0.org.afilias-nst.info.org. 172800 IN NS d0.org.afilias-nst.org. ;; ADDITIONAL SECTION:a0.org.afilias-nst.info. 172800 IN A 199.19.56.1a0.org.afilias-nst.info. 172800 IN AAAA 2001:500:e::1a2.org.afilias-nst.info. 172800 IN A 199.249.112.1; ... (additional glue records)Understanding the response:
No answer section: The root server doesn't know www.example.org—it only knows about TLDs.
Authority section: Lists the nameservers for .org—this is the referral. It tells the resolver: "I don't have your answer, but these servers do."
Additional section: Contains glue records—IP addresses of the .org servers—so the resolver can immediately contact them without another lookup.
Step 3: Resolver follows referral
The resolver now queries a .org server for www.example.org. The .org server will either answer or provide another referral to example.org's authoritative servers.
Query volume perspective:
| Metric | Approximate Value | Context |
|---|---|---|
| Total queries/day (all roots) | ~1 trillion+ | Peak loads during attacks much higher |
| Queries per root identity | ~50-100 billion/day | Varies by deployment size |
| Legitimate queries (estimates) | ~10-20% | Most queries are repeated/cacheable |
| Junk/abuse queries | ~80-90% | Misconfigured resolvers, botnets, attacks |
| Response latency | <1ms (local instance) | Extremely fast; data is in memory |
Studies show that the vast majority of root server queries should never happen. Properly configured resolvers cache TLD information for up to 48 hours. A well-behaved resolver serving millions of users might query root servers only a few times per day. Misconfigured resolvers, malware, and attacks generate most root traffic.
Given their critical role, root servers are among the most protected infrastructure on the Internet. Multiple layers of security address different threat vectors.
DNSSEC signing of the root zone:
Since July 2010, the root zone has been cryptographically signed using DNSSEC (Domain Name System Security Extensions). This provides:
The root zone's Key Signing Key (KSK) and Zone Signing Key (ZSK) are the most critical keys in DNSSEC. The KSK ceremony—where the KSK is generated or rotated—is an elaborate, audited process involving multiple trusted community members.
Historical attacks on root servers:
| Year | Attack Type | Impact | Outcome |
|---|---|---|---|
| 2002 | DDoS against all 13 roots | 9 of 13 severely degraded | Minimal user impact due to caching |
| 2007 | DDoS (24-hour attack) | 2 roots unreachable at times | Anycast deployment mitigated impact |
| 2015 | DDoS (5M queries/sec per root) | Brief periods of packet loss | Modern defenses handled load |
| 2016 | Mirai botnet (IoT devices) | Affected some instances | Anycast and scaling prevailed |
Why attacks haven't succeeded:
Despite repeated attempts, no attack has ever successfully taken down the root server system. Three factors explain this resilience:
Caching: Resolvers cache TLD information for 48+ hours. Even if all roots vanished, most resolution would continue for days.
Anycast scale: With 1,500+ instances, attackers need enormous, coordinated traffic to impact availability significantly.
Rapid response: Root operators actively monitor and can spin up additional capacity or implement filtering within minutes.
The root server system demonstrates defense-in-depth principles: multiple independent operators, multiple software implementations, massive geographic distribution, protocol-level caching, and active threat monitoring. This layered approach has maintained 100% practical availability for decades despite being a constant target.
The governance of root servers involves multiple organizations with distinct but interlocking roles. Understanding this structure is important for appreciating both the stability and the political dimensions of DNS.
Key entities:
| Entity | Role | Key Responsibilities |
|---|---|---|
| ICANN (Internet Corporation for Assigned Names and Numbers) | Policy and coordination | Manages root zone change policy; operates IANA function; facilitates multistakeholder governance |
| IANA (Internet Assigned Numbers Authority) | Root zone administration | Processes TLD delegation requests; maintains authoritative root zone data |
| Verisign | Root Zone Maintainer | Implements root zone changes; generates and distributes signed zone files to all operators |
| NTIA (U.S. Dept. of Commerce) | Historical oversight (ended 2016) | Formerly authorized root zone changes; role transitioned to ICANN via IANA Stewardship Transition |
| Root Server Operators (RSO) | Operational | Each of 12 organizations operates infrastructure, handles traffic, implements security |
| RSSAC (Root Server System Advisory Committee) | Technical advice | ICANN advisory body with RSO participation; provides operational and security recommendations |
The root zone change process:
Request: A TLD registry (e.g., Verisign for .com, PIR for .org) submits a change request to IANA (e.g., update nameserver addresses).
IANA Review: IANA verifies the request authenticity and policy compliance.
Root Zone Maintainer Action: Verisign implements the change in the root zone file, resigns with DNSSEC keys, and distributes to all root operators.
Operator Distribution: Each root server operator retrieves the updated zone via AXFR/IXFR zone transfers.
Global Propagation: Within minutes to hours, all root instances serve the new data.
The 2016 IANA Stewardship Transition:
Historically, the U.S. government (via NTIA) held contractual authority over ICANN and the root zone. In October 2016, this arrangement ended with the IANA Stewardship Transition—a landmark moment where oversight transitioned to the global multistakeholder community.
This means no single government now has special authority over the root zone. Changes are governed by ICANN's processes, with accountability mechanisms involving the global Internet community. This was a major step toward internationalizing Internet governance.
It's crucial to distinguish governance (policy, authority, change approval) from operations (running servers, answering queries). Root server operators are independent organizations; they voluntarily run infrastructure as a public good. No entity 'owns' the DNS root—it functions through cooperation, shared protocols, and institutional trust.
Root servers are the architectural apex of the DNS hierarchy—the starting point for resolving any domain name when cached information is unavailable. Their design exemplifies principles that make distributed systems resilient: redundancy, geographic distribution, protocol-level caching, and operational diversity.
example.comWhat's next:
With root servers established as the hierarchy's apex, we'll explore the next tier: TLD (Top-Level Domain) Servers. These servers—responsible for .com, .org, .net, country codes like .uk and .de, and the newer generic TLDs—handle the next step in referral chain. Understanding TLD servers reveals how the DNS hierarchy scales to handle billions of domains across thousands of registries.
You now have a comprehensive understanding of DNS root servers—their role as the resolution starting point, the Anycast architecture enabling global distribution, the root zone management process, security mechanisms, and governance structures. This foundation prepares you to understand how the full DNS hierarchy delegates authority from root to TLD to authoritative servers.