What Are Root Name Servers, and How Many Are There?

Every DNS lookup that isn't already cached starts in the same place: the root. Before a resolver can find the servers for example.com, it needs to know who runs .com, and the only servers that can tell it are the root name servers. You'll often hear that "there are only 13 root servers," which is both true and wildly misleading — there are 13 names, but well over a thousand physical machines answering behind them.

This article explains what root name servers actually do (and don't do), why the number 13 exists, who operates them, how anycast turns 13 addresses into a global network, and how you can query them yourself. If you want the bigger picture of a lookup first, see how DNS works; this post zooms in on the very top of the tree.

What Root Name Servers Do

The DNS namespace is a tree. At the top is the root zone, written as a single dot (.). Directly underneath it are the top-level domains: com, org, net, country codes like uk and de, newer gTLDs like app and dev, and the infrastructure domain arpa.

Root name servers are the authoritative servers for that root zone. Their job is narrow: when a resolver asks about any name, they reply with a referral — the NS records (and glue addresses) for the TLD that name belongs to. They never know the IP address of www.example.com. They only know which servers are responsible for .com.

That narrow job is precisely why the system scales. The root zone is small — it contains delegations for a little over 1,400 TLDs plus DNSSEC records — and its delegations carry long TTLs, so resolvers rarely need to ask the root anything at all.

How Many Root Servers Are There?

There are 13 root server identities, named a.root-servers.net through m.root-servers.net. Each has one IPv4 and one IPv6 address. These identities are run by 12 independent organizations (Verisign operates two of them, A and J).

But those 13 identities are served by more than 1,900 instances around the world, thanks to anycast. The live count changes as operators add sites; root-servers.org publishes an up-to-date map.

Letter	Operator	IPv4 address
A	Verisign, Inc.	198.41.0.4
B	University of Southern California, Information Sciences Institute	170.247.170.2
C	Cogent Communications	192.33.4.12
D	University of Maryland	199.7.91.13
E	NASA Ames Research Center	192.203.230.10
F	Internet Systems Consortium (ISC)	192.5.5.241
G	US Department of Defense (DISA)	192.112.36.4
H	US Army Research Lab	198.97.190.53
I	Netnod	192.36.148.17
J	Verisign, Inc.	192.58.128.30
K	RIPE NCC	193.0.14.129
L	ICANN	199.7.83.42
M	WIDE Project	202.12.27.33

B-root changed its IPv4 address to 170.247.170.2 in late 2023; older root hints files list its previous address. Resolvers cope with this automatically by refreshing the list from the root itself, which is covered below.

Why exactly 13?

The limit is historical and comes from packet size. Classic DNS over UDP capped responses at 512 bytes. A response listing all root server names and their IPv4 addresses had to fit inside that limit, and 13 was the most that would fit with room for the header and question. With label compression, each additional server name costs only a few bytes, but the IPv4 glue records add up, and 13 was the practical ceiling.

Today EDNS allows much larger UDP responses, and the full priming response including IPv6 addresses is well over 512 bytes. But there's no pressing reason to add a 14th letter: anycast already provides as much capacity and geographic diversity as needed, and changing a foundational constant across every resolver on the internet carries real risk.

Anycast: 13 Names, Thousands of Machines

Each root server address is announced via BGP from many locations at once. This is anycast — the same IP address exists in dozens or hundreds of places, and internet routing delivers your packet to the topologically nearest one. When a resolver in Frankfurt queries 198.41.0.4, it reaches an A-root instance near Frankfurt; a resolver in Singapore sending to the same address reaches a different instance in Asia.

Anycast gives the root system three properties at once:

1. Low latency. Most resolvers are a short network hop from at least several root instances.
2. Resilience. If an instance fails, its route is withdrawn and traffic flows to the next-nearest one.
3. Attack absorption. A flood aimed at one root address is spread across every instance announcing it, and stays mostly local to the attacker's region.

You can see which instance you're hitting by asking for the server's identity in the CHAOS class:

dig @k.root-servers.net hostname.bind CH TXT +short
dig @f.root-servers.net hostname.bind CH TXT +short

"ns2.bh-amh.k.ripe.net"
"DAC.cf.f.root-servers.org"

Each operator uses its own naming scheme, but the result usually encodes the site. Run the same command from a different country (or via a VPN) and you'll get a different instance name for the same IP address. The +nsid option asks for the same information through an EDNS option instead:

dig +nsid +norecurse @k.root-servers.net . SOA

The NSID line in the OPT pseudosection shows the instance identifier in both hex and ASCII. Anycast DNS explains the routing technique in more depth, including how commercial DNS providers use it for their own networks.

Who Controls the Root Zone?

It's important to separate the root zone (the data) from the root servers (the machines that publish it):

• IANA, operated by ICANN's affiliate PTI, manages the contents of the root zone — which TLDs exist and what their NS and DS records are. TLD operators submit change requests to IANA.
• Verisign, as the Root Zone Maintainer, compiles and DNSSEC-signs the zone and distributes it.
• The 12 root server operators load that signed zone and serve it. They don't decide what's in it and can't edit it individually.

Because the zone is DNSSEC-signed, a validating resolver can detect any tampering regardless of which root instance answered. The root's key-signing key (KSK) is the trust anchor that underpins every DNSSEC validation chain on the internet.

How Resolvers Find the Root: Root Hints and Priming

A recursive resolver has to bootstrap somewhere. It ships with a root hints file listing the 13 names and their addresses. In BIND, that file is typically referenced like this:

// named.conf — older style, explicit root hints
zone "." {
    type hint;
    file "/usr/share/dns/root.hints";
};

Modern BIND versions compile the hints in, so you rarely need this block. On startup the resolver performs a priming query: it asks one of the hinted addresses for the NS records of . and uses that authoritative, current list from then on. Priming is how resolvers learned B-root's new address without everyone having to edit a file.

You can download the current hints file directly from IANA's InterNIC site:

curl -s https://www.internic.net/domain/named.root -o root.hints
grep -E "^[A-M]\.ROOT-SERVERS\.NET\.\s+[0-9]+\s+A\s" root.hints

The grep prints the IPv4 line for each of the 13 identities so you can compare against the table above.

Querying the Root Yourself

Ask any root server for the root NS set:

dig +norecurse @a.root-servers.net . NS

;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

;; ANSWER SECTION:
.   518400 IN NS l.root-servers.net.
.   518400 IN NS j.root-servers.net.
.   518400 IN NS f.root-servers.net.
...

The aa flag confirms the root server is authoritative for .. The TTL of 518400 seconds is six days — resolvers only need to refresh this list occasionally.

Now ask a root server about a real hostname:

dig +norecurse @a.root-servers.net www.example.com A

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; AUTHORITY SECTION:
com.   172800 IN NS a.gtld-servers.net.
com.   172800 IN NS b.gtld-servers.net.
...

There's no answer and no aa flag for www.example.com. Instead, the authority section lists the .com nameservers with a two-day TTL, and the additional section carries their addresses. That's a referral, and it's the only thing a root server will ever tell you about a name below a TLD. The next step belongs to the TLD name servers.

To watch the full chain from root to answer, use dig +trace www.example.com.

How Much Traffic Actually Reaches the Root?

Less than you might expect for legitimate lookups. Because .com, .net, and other popular TLD delegations are cached for two days, a busy resolver asks the root about them only occasionally. A large share of what the root servers do receive is junk: queries for TLDs that don't exist, such as typos, internal names like .local or .corp leaking from misconfigured networks, and random-string probes from browsers checking for DNS interception.

Two techniques reduce root load further:

• Aggressive NSEC caching (RFC 8198). A validating resolver can use the signed NSEC records from one "this TLD doesn't exist" response to answer other queries for nonexistent TLDs from cache. This is a form of negative caching.
• Local root (RFC 8806). A resolver can fetch a full copy of the signed root zone and serve it to itself, so it never needs to query the root servers for routine lookups.

Unbound supports running a local root copy with an auth-zone block:

# unbound.conf — serve a local copy of the root zone
auth-zone:
    name: "."
    primary: 192.33.4.12          # c.root-servers.net
    primary: 192.5.5.241          # f.root-servers.net
    primary: 192.0.32.132         # lax.xfr.dns.icann.org
    primary: 192.0.47.132         # iad.xfr.dns.icann.org
    fallback-enabled: yes
    for-downstream: no
    for-upstream: yes
    zonefile: "root.zone"

This tells Unbound to transfer the root zone from root and ICANN servers that permit it, use it for its own upstream lookups, and fall back to normal queries if the transfer fails. Check your chosen operators' current transfer policies before relying on this in production.

What Would Happen If the Root Went Down?

Taking the root offline entirely is extremely difficult — it would require knocking out 13 independently operated, anycast networks with diverse hardware, software, and hosting. Even then, the impact would be gradual rather than instant. Resolvers would keep answering from cache, and TLD delegations cached with two-day TTLs would keep most lookups working for a long time. Only newly queried TLDs and expired cache entries would start failing.

Large DDoS attacks against the root have happened, most notably in 2015 and 2016, and some letters saw degraded service at some sites. But end users broadly didn't notice, which is the clearest evidence that the distributed design works.

---

Root Name Servers FAQ

Conclusion

Root name servers have a simple, essential job: answer for the root zone and point resolvers to the right TLD servers. The famous number 13 refers to named identities, a holdover from the 512-byte UDP limit, not to physical machines — anycast spreads those 13 addresses across well over 1,900 instances run by 12 independent organizations. Long TTLs, caching, aggressive NSEC, and local root copies mean the root sees comparatively little legitimate traffic, and DNSSEC signing means it doesn't matter which instance answers.

For site owners, the root is something you'll rarely interact with directly, but knowing how it works makes dig +trace output easy to read and makes the delegation chain from root to TLD to your nameservers much less mysterious.

Here are some useful references for going deeper on the DNS root:

1. Root Server Technical Operations: root-servers.org — the official site of the root server operators, with a live map of instances.
2. IANA: Root Servers — IANA's list of the 13 root server identities and their operators.
3. IANA: Root Zone Database — every TLD delegated from the root zone.
4. RFC 8806: Running a Root Server Local to a Resolver — the specification for serving a local copy of the root zone.
5. RFC 8109: Initializing a DNS Resolver with Priming Queries — how resolvers bootstrap their view of the root servers.