There are not 13 root servers. There are more than 1,900, scattered across every populated continent, and on any given day the one answering your queries is probably a few milliseconds away in the same city. Yet every explainer, every interview answer, every certification study guide says 13. The number is wrong, it has been wrong for two decades, and the reason it survives is more interesting than the number itself.
Thirteen is real, but it counts the wrong thing. There are 13 root server identities — named A through M, a.root-servers.net through m.root-servers.net — operated by 12 independent organizations. (Verisign runs both A and J; the others run one apiece.) Those identities are not machines. Each one is an IP address, and behind that address sits a swarm.
Why 13 and not 12 or 50
The number got fixed in 1987, and the thing that fixed it was a packet.
DNS was built on UDP with a hard ceiling: a response had to fit in 512 bytes, per RFC 1035. That wasn’t laziness — 512 was the size everyone trusted any IP path to carry in one datagram without fragmenting. Stay under it and your answer arrives whole, in one shot, no reassembly.
Now think about how a resolver finds the root in the first place. It can’t look the root servers up in DNS — the root is DNS’s starting point. So it ships with a tiny bootstrap file (the “root hints,” historically named.root) and, on startup, fires a priming query: it asks one root server, “who are all the root servers?” The answer comes back as a list of every root name plus its address.
That answer had to fit in 512 bytes.
Work out the arithmetic and it’s tight. Each server costs you a name in the answer section and an address record in the additional section, and once you count the question, the header, and the per-record overhead, thirteen name-and-address pairs is just about where you run out of room. A fourteenth would have pushed the response past 512 bytes and triggered truncation. So the operators stopped at 13. Not a committee’s lucky number — the largest count that fit in one UDP packet.
Here’s the part that makes the “13 servers” framing actively misleading: that constraint is gone. EDNS0 (RFC 6891) lifted the 512-byte ceiling years ago, the priming response now carries IPv6 glue too, and it long ago outgrew a single old-style datagram. The engineering reason for 13 expired. The number didn’t, because changing the count of root identities means re-coordinating the root hints baked into every resolver on earth, and nobody touches that for fun. So 13 is now a historical artifact wearing the costume of a design decision.
One IP, hundreds of boxes
If the number of identities is frozen at 13, how do you grow capacity, survive attacks, and put a root server near everyone? You cheat at routing.
The trick is anycast. You take one of those 13 IP addresses and you announce it into BGP — the internet’s routing protocol — from dozens or hundreds of physical locations at once. Every site claims to be that address. When your query goes out, the routing fabric does what it always does: hands the packet to whichever site is closest in network terms. Same destination IP, wildly different machine depending on where you are. A query to K-root from Seoul and a query to K-root from São Paulo hit completely different hardware, and neither client knows or cares.
This is why “how many root servers are there” has no clean answer. Thirteen addresses. Twelve operators. And, as of 2026, more than 1,900 physical instances answering on those addresses — the count creeps up constantly as operators add sites. The 13 is a logical fiction stretched over real iron by a routing protocol that was happy to let multiple places share one address.
Anycast wasn’t the original plan; it was a response to getting punched. On 21 October 2002, an attacker flooded all 13 roots with traffic for about an hour. The system mostly shrugged — the servers were filtering the junk — but it was a clear warning that 13 fat targets was a bad shape for the foundation of the internet. The fix was to stop being 13 targets. RIPE NCC, which operates K-root, deployed mirrored instances around the world; F-root did the same. When the next big one came on 6 February 2007 — a 24-hour assault — the anycast’d servers spread the load across their many sites and rode it out, while a couple of the roots that hadn’t distributed as widely took real damage. The architecture had quietly changed underneath the same 13 names, and it showed.
The smallest cheat: run your own
There’s a final move that makes the whole question feel almost quaint. Your recursive resolver doesn’t have to ask a root server at all.
The root zone is tiny — it’s basically a list of every TLD and which nameservers are authoritative for it — and it’s public. RFC 8806 (which obsoleted the experimental RFC 7706) describes loading a current copy of the entire root zone into your own resolver on a loopback address. Now every root query is answered locally, in microseconds, and never leaves the box — which kills the round-trip and stops anyone from snooping on which TLDs you’re resolving. It’s deliberately fenced in to loopback so you can’t accidentally start serving the root to the rest of the network and become a 1,901st instance nobody asked for. The RFCs are careful to frame it as an option with operational risk, not a best practice. But it exists, and it means the root is something you can just have a copy of.
So the honest answer to “how many root servers are there” is: it depends what you’re counting, and 13 is the least useful number in the set. There are 13 names because of a packet size that stopped mattering in the 2000s. There are more than 1,900 machines because a routing trick let the system grow without renumbering. And there can be exactly one more, on your own loopback, the moment you decide you’d rather not ask anyone at all.