There are not 13 root servers. There are about 2,000, scattered across every populated continent, and on any given day the one answering your queries is probably a short network hop away rather than across an ocean. 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 (an IPv4 and an IPv6 one, these days), and behind that address sits a swarm.

For the record, here are the thirteen and who runs them:

LetterOperator
AVerisign
BUSC Information Sciences Institute
CCogent Communications
DUniversity of Maryland
ENASA
FInternet Systems Consortium (ISC)
GUS Defense Information Systems Agency
HUS Army Research Lab
INetnod (Sweden)
JVerisign
KRIPE NCC (Netherlands)
LICANN
MWIDE Project (Japan)

Why 13 and not 12 or 50

The number was set by a packet, though it took a decade to get there.

DNS was built on UDP with a hard ceiling: a response had to fit in 512 bytes, per RFC 1035 (1987). 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, the room runs out fast. By 1993 the priming response was already brushing against 512 bytes. The fix was a renaming: from 1995 every root moved under one shared domain, root-servers.net, so DNS name compression could squeeze each name down to little more than a single letter. That bought exactly enough space for four more servers, J through M, added in 1996–97. Thirteen was where the packet was full. 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 almost certainly hit different hardware, and neither client knows or cares.

This is why “how many root servers are there” has no clean answer. Thirteen identities. Twelve operators. And, as of October 2026, 2,047 instances answering on those addresses according to root-servers.org — 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 at the root grew up alongside getting punched. On 21 October 2002, an attacker flooded all 13 roots with traffic for about an hour. Users barely noticed — packet filters absorbed most of the junk — but it was a clear warning that 13 fat targets was a bad shape for the foundation of the internet. The answer was to stop being 13 targets. ISC spread F-root across anycast sites, and RIPE NCC, which operates K-root, deployed instances around the world. When the next big one came on 6 February 2007 — an attack that ran for many hours — two roots, G and L, suffered badly, while F and M, already spread out by anycast, absorbed heavy traffic and kept answering. 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 replaced RFC 7706 in 2020) describes loading a current, validated copy of the entire root zone into your own resolver. Now root lookups are answered locally and never leave the box — which kills the round-trip and stops anyone on the path from seeing which TLDs you’re resolving. It’s deliberately fenced in: RFC 7706 insisted on the loopback interface, and RFC 8806 loosened that to “only this host may query it,” so you can’t accidentally start serving the root to the rest of the network and become an 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 once EDNS0 spread. There are about 2,000 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.