What are DNS root servers?

DNS root servers sit at the top of the hierarchy and serve the root zone. You might hear “there are only 13,” but it’s really 13 identifiers (A–M), each with many anycasted instances worldwide. Here’s a relaxed rundown of what they do and why the number is misleading.

Role and position 🌐

Root servers sit atop the DNS hierarchy, holding the root zone and pointing resolvers to TLD name servers (.com, .jp, etc.). A quick glossary for resolver/authoritative/DNSSEC is here.

How it works

Recursive resolvers use root hints to query a root server; the root replies with TLD server info.
They are authoritative for the root zone and normally refer queries to TLD servers rather than directly answering with website addresses.
The root zone is signed with DNSSEC. Validators separately maintain trusted key information, called a trust anchor.

13 identifiers, not 13 boxes 🔢

A–M are just 13 labels; the actual footprint is much larger.

Why 13

Historically, root server names were set to 13 (A.root-servers.net through M.root-servers.net).
The 13 identifiers are run by 12 operators. Verisign operates both A and J, so identifiers and operators are not one-to-one.

Anycast everywhere

Anycast lets an identifier be served at multiple sites. Routing chooses the path; it need not lead to the geographically nearest or lowest-latency instance.
Published site and instance counts are not necessarily counts of physical machines. Current deployment information is available from the operators.

Why people say “13 servers”

Seeing only the 13 identifiers makes it sound like 13 machines, but each has many instances.
Early articles sometimes said “only 13,” and the phrasing stuck.
The operators publish site and instance information at root-servers.org. RSSAC is the ICANN Root Server System Advisory Committee.

Common misconceptions

It’s not a fragile set of 13 boxes; it’s globally redundant.

Myths vs. reality

Distributed deployment improves resilience, but does not prevent failures in a user connection or recursive resolver.
Multiple operators and geographic spread provide robustness.

Practical notes 💡

You don’t run root servers yourself, but knowing the basics helps troubleshooting.

Good to know

dig . NS and dig . DNSKEY query the configured resolver. They do not prove a direct query to a root server or local DNSSEC validation.
Cache state and routing influence the responding instance, path, and latency.
Ordinary clients use configured recursive resolvers. DNS software performing iterative resolution uses initial root information; not every OS directly uses root hints.

Specifications and related guides

Root Server Technical Operations Association / RFC 4786 / DNS basics

< What VPNs protect and what they do not The long, layered UA string >