What are root name servers and how many are there?

Sajjad
DNS
10 Oct, 2026

Root name servers are the DNS servers at the very top of the Domain Name System. They don't know the IP address of any website, but they know where to find the servers for every top-level domain, such as .com, .org, .uk and .dev. When a resolver has nothing cached, the root servers are its starting point. There are 13 named root server identities, labelled a.root-servers.net to m.root-servers.net and run by 12 independent organisations, but each identity is served by many physical machines around the world using anycast, so the real number of root server instances is close to 2,000.

The "13 root servers" figure is one of the most quoted and most misunderstood facts about the internet. In this article you'll learn what the root servers actually do, why the number is 13, who operates each one, how anycast spreads them across the globe, what the root zone contains, and how to query the root servers and identify which instance you're reaching.

What Root Name Servers Do

DNS is a tree. At the top is the root, written as a single dot (.). Below it are the top-level domains, then the domains people register, then their subdomains.

The root name servers are authoritative for the root zone, and the root zone contains only one kind of useful information: which name servers are responsible for each TLD. When a resolver asks a root server about www.example.com, the root server doesn't try to answer the question. It replies with a referral: "I don't know that name, but these are the servers for .com."

That's all they do, and it's deliberately minimal. A root server never looks anything up on your behalf, never contacts other servers, and never stores records for individual websites.

You can see this by asking a root server directly:

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

;; 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.
...

;; ADDITIONAL SECTION:
a.gtld-servers.net.     172800  IN      A       192.5.6.30
...

No answer, just a list of .com servers and their addresses, valid for 172,800 seconds (two days).

How Many Root Servers Are There?

The honest answer has two parts.

13 root server identities: There are 13 names, a to m, each with one IPv4 address and one IPv6 address. These are the addresses every resolver knows about.
Nearly 2,000 instances: Each identity is served by many separate servers in different cities, all sharing the same IP address through anycast. The live count, published at root-servers.org, has been in the high hundreds to around two thousand in recent years and changes as operators add sites.

So when someone says "there are only 13 root servers", they're describing the addressing scheme, not the hardware.

Why 13?

The limit comes from the original DNS design. Classic DNS over UDP was limited to 512-byte messages. A response listing every root server's name and IPv4 address had to fit inside that limit alongside the rest of the packet, and 13 was the most that would comfortably fit.

Modern DNS uses EDNS(0), which allows much larger UDP responses, and IPv6 addresses have been added for every root server. But adding more identities would bring little real benefit, because anycast already lets operators add as much capacity and geographic coverage as they like without changing any addresses. So the number has stayed at 13.

Who Operates the Root Servers?

The 13 identities are run by 12 organisations. Verisign runs two of them (A and J). The operators are a deliberately varied mix of companies, universities, government bodies and non-profits in several countries.

Name	Operator	IPv4	IPv6
`a.root-servers.net`	Verisign	198.41.0.4	2001:503:ba3e::2:30
`b.root-servers.net`	University of Southern California, ISI	170.247.170.2	2801:1b8:10::b
`c.root-servers.net`	Cogent Communications	192.33.4.12	2001:500:2::c
`d.root-servers.net`	University of Maryland	199.7.91.13	2001:500:2d::d
`e.root-servers.net`	NASA Ames Research Center	192.203.230.10	2001:500:a8::e
`f.root-servers.net`	Internet Systems Consortium (ISC)	192.5.5.241	2001:500:2f::f
`g.root-servers.net`	US Department of Defense (DISA)	192.112.36.4	2001:500:12::d0d
`h.root-servers.net`	US Army DEVCOM Research Laboratory	198.97.190.53	2001:500:1::53
`i.root-servers.net`	Netnod	192.36.148.17	2001:7fe::53
`j.root-servers.net`	Verisign	192.58.128.30	2001:503:c27::2:30
`k.root-servers.net`	RIPE NCC	193.0.14.129	2001:7fd::1
`l.root-servers.net`	ICANN	199.7.83.42	2001:500:9f::42
`m.root-servers.net`	WIDE Project	202.12.27.33	2001:dc3::35

The B root changed its IPv4 address in late 2023, which is a good reminder that the hints file on long-lived systems should be refreshed occasionally. The old address continued to answer for a transition period, and resolvers pick up the current list automatically through priming, which is explained below.

The operators coordinate through ICANN's Root Server System Advisory Committee (RSSAC), but each runs its own infrastructure independently, often using different hardware, operating systems and DNS software. That diversity is intentional: a bug in one implementation can't take out every root server at once.

Who Decides What Goes in the Root Zone?

Running the servers and deciding their content are separate jobs.

IANA, operated by Public Technical Identifiers (PTI), an affiliate of ICANN, processes changes requested by TLD operators, such as updating name servers or DS records.
Verisign, acting as the Root Zone Maintainer, builds and signs the root zone file and distributes it to the root server operators.
The root server operators load the published file and serve it. They don't edit it.

The root zone is small by DNS standards. In October 2026 it delegates around 1,440 TLDs and is roughly 2 MB in its signed form. It's updated about twice a day, and the SOA serial number follows a date-based format:

dig . SOA +short

a.root-servers.net. nstld.verisign-grs.com. 2026100900 1800 900 604800 86400

The serial 2026100900 means the first version published on 9 October 2026.

Anycast: How 13 Addresses Become Nearly 2,000 Servers

With anycast, the same IP address is announced from many locations using BGP, the internet's routing protocol. Your packets go to whichever instance is closest in network terms. If one site goes offline, its route is withdrawn and traffic flows to the next nearest site automatically.

This gives the root server system several important properties:

Low latency: Most networks have a root server instance nearby, often in the same city or even inside the same internet exchange.
Resilience: Losing a site, or even many sites, simply shifts traffic elsewhere.
DDoS resistance: Attack traffic is spread across hundreds of locations rather than concentrated on one machine.

Finding Out Which Instance You're Reaching

Many root servers will tell you which instance answered if you ask with the NSID option or the special hostname.bind query in the CHAOS class:

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

"ns2.bh-amh.k.ripe.net"

dig @l.root-servers.net . NS +norecurse +nsid | grep NSID

; NSID: 6e 7a 2d 6d 61 65 2d 61 62 ("nz-mae-ab")

The naming scheme varies by operator, but it usually includes a city or airport code. Try the same query from a different network, or through a VPN, and you'll usually reach a different instance.

Root Hints and Priming

A resolver needs to know where the root servers are before it can ask them anything, which raises a chicken-and-egg problem. The solution is a small file called the root hints, shipped with every resolver. It lists the 13 names and their addresses. IANA publishes the current version at https://www.internic.net/domain/named.root.

A trimmed copy looks like this:

.                        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
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     170.247.170.2
B.ROOT-SERVERS.NET.      3600000      AAAA  2801:1b8:10::b

When a resolver starts, it sends a priming query (described in RFC 8109) to one of the addresses in the hints file, asking for the root's NS records. The answer gives it the authoritative, current list, which it then caches. That's why an outdated hints file rarely causes problems: as long as one address still works, priming fills in the rest.

You can perform a priming query yourself:

dig @198.41.0.4 . NS +norecurse +noall +answer

.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
.                       518400  IN      NS      c.root-servers.net.
...
.                       518400  IN      NS      m.root-servers.net.

The root NS records have a TTL of 518,400 seconds, or six days.

To refresh the hints file on a BIND server, download the current copy and reload:

sudo curl -fsSL -o /usr/share/dns/root.hints https://www.internic.net/domain/named.root
sudo systemctl restart named

The path varies by distribution, so check the hints zone definition in your BIND configuration first. Distribution packages usually update this file for you.

How Much Do Root Servers Actually Get Used?

Less than you might expect for any single lookup, and more than you'd expect in total.

Because resolvers cache the root's NS records for six days and each TLD delegation for two days, a busy resolver only needs to contact the root occasionally for legitimate queries. In fact, a large share of the traffic root servers receive is junk: queries for names that will never exist, such as single-label names leaked from internal networks, typos and misconfigured software. The root answers these with NXDOMAIN.

Even so, the root server system as a whole handles a very large volume of queries every day, which is why the operators invest so heavily in capacity.

What If the Root Servers Went Down?

People sometimes worry that the internet would stop if the root servers failed. In practice, a total outage is extremely unlikely because of the number of instances, the variety of operators and anycast's automatic failover.

Even in that unlikely case, the effect wouldn't be instant. Resolvers already hold the delegations for popular TLDs in their caches, and those remain valid for up to two days. Lookups for cached TLDs would keep working, and only new or expired delegations would fail. Large-scale attacks on the root servers have happened, and the system has absorbed them with little or no visible impact on users.

Running a Local Copy of the Root

RFC 8806 describes how a resolver can keep its own copy of the root zone and answer root queries locally, which reduces latency and dependence on the root servers. Unbound supports this with an auth-zone block:

auth-zone:
    name: "."
    primary: lax.xfr.dns.icann.org
    primary: iad.xfr.dns.icann.org
    fallback-enabled: yes
    for-downstream: no
    for-upstream: yes
    zonefile: "/var/lib/unbound/root.zone"

Unbound transfers the root zone from ICANN's public transfer servers, keeps it up to date, and falls back to normal queries if the local copy becomes unavailable. Because the root zone is DNSSEC-signed, Unbound can validate the data it downloads.

The Root and DNSSEC

The root zone has been signed with DNSSEC since 2010. The root's Key Signing Key (KSK) is the trust anchor for the entire DNSSEC system: every validating resolver ships with it, and every signature chain ends there.

dig . DNSKEY +multi +noall +answer | grep -E "KSK|ZSK"

                                ) ; KSK; alg = RSASHA256 ; key id = 38696
                                ) ; ZSK; alg = RSASHA256 ; key id = 8763
                                ) ; KSK; alg = RSASHA256 ; key id = 20326
                                ) ; ZSK; alg = RSASHA256 ; key id = 57780

The KSK was changed for the first time in 2018, when key 20326 replaced the original key. A newer KSK, known as KSK-2024 with key tag 38696, has been published in the root zone alongside it ahead of the next planned rollover. Resolvers that follow RFC 5011 automatic trust anchor updates, which includes the default configurations of Unbound and BIND, pick up the new key without manual action. If you maintain a resolver with a hand-configured trust anchor, check that it includes the current keys.

FAQ: Root Name Servers

There are 13 root server names and addresses, but each one is served by many machines in different locations using anycast. In total there are close to 2,000 root server instances worldwide.

No single organisation. Twelve operators run the 13 identities, including Verisign, RIPE NCC, ICANN, NASA, the University of Maryland, Netnod and the WIDE Project. IANA manages the content of the root zone, and Verisign compiles and signs it.

No. Root servers only know which servers handle each top-level domain. They refer resolvers to the TLD servers, which in turn refer them to your domain's authoritative name servers.

The original DNS limited UDP messages to 512 bytes, and 13 names with their IPv4 addresses was the most that fit. Anycast now provides unlimited scaling behind those addresses, so there's little reason to add more names.

Not often for real lookups. The root NS records are cached for six days and TLD delegations for two days, so a resolver only needs the root when its cache expires or a query arrives for a TLD it hasn't seen recently.

You can't add a new official root server, but you can run a local copy of the root zone on your resolver, as described in RFC 8806. Unbound and BIND both support this, and the data stays trustworthy because the zone is DNSSEC-signed.

The root server operators publish a map and list of instances at root-servers.org. You can also identify the instance you're reaching with dig and the hostname.bind or NSID queries.

Conclusion

Root name servers are the starting point of DNS. They hold the root zone, which lists the servers for every top-level domain, and they answer every question with a referral to the right TLD. There are 13 named identities, a legacy of the 512-byte limit in early DNS, operated by 12 independent organisations, and anycast spreads those 13 addresses across nearly 2,000 instances around the world.

Their design, with minimal data, long TTLs, diverse operators and anycast everywhere, makes them one of the most resilient parts of the internet. Run dig @a.root-servers.net com NS +norecurse and an NSID query or two, and you'll see the top of the DNS tree, and the instance nearest you, for yourself.