Every time a browser looks up a domain name, a quiet chain of questions begins at the top of the Domain Name System. That top is not a single machine. It is a set of 13 named authorities, labelled A through M, that together publish the master list of who runs each top-level domain — .com, .uk, .jp, .app, and the rest. Between them they field roughly 1.6 million queries every second under normal load — about 140 billion a day — according to the traffic report the root server operators published in July 2026.

The number 13 is not architectural. It is a leftover from a 1980s decision about how much data would fit in a single UDP packet.

Why there are 13 named servers, not 13 machines

The DNS was specified by Paul Mockapetris in RFC 1035, published in November 1987. That document set a hard ceiling of 512 bytes on a standard DNS response sent over UDP. Once the header, question section and other overhead were accounted for, the priority list of root name servers had to fit in what was left. Thirteen server names — a.root-servers.net through m.root-servers.net — was the largest set that fit comfortably. The letters stuck.

Each letter is a service, not a box. Behind a single letter sits a cluster of servers announcing the same IP address from many locations at once, a technique called anycast, described in RFC 4786. A query from Nairobi and a query from Reykjavík both aimed at K-root will each land at whichever K-root site the routing tables consider closest. The user never chooses. The network does.

The result: 13 identities, hundreds of physical locations. As of 11 August 2026, the operators together ran 2,003 operational instances worldwide, according to the live count published by root-servers.org.

What the root actually answers

A common misconception is that the root servers know where every website lives. They do not. Their job is far narrower.

Ask a root server about wikipedia.org and it will not tell you Wikipedia’s IP address. It will tell you which servers are authoritative for .org. Those servers, in turn, point to the servers authoritative for wikipedia.org, which finally answer with an address. The root is a signpost to signposts.

The file it serves — the root zone — is small, published by IANA, and lists the operators of every top-level domain. It changes slowly. Most of the time, a well-behaved resolver has already cached the answer and does not touch the root at all. That 140-billion-a-day figure is largely a background hum of misconfigured software, junk lookups, denial-of-service traffic, and freshly booted resolvers priming their caches.

Who runs the 13 letters

There is no single owner of the root. The 13 identities are operated by 12 independent organisations under a longstanding arrangement documented by IANA. A is run by Verisign; B by the University of Southern California’s Information Sciences Institute; C by Cogent; D by the University of Maryland; E by NASA Ames; F by Internet Systems Consortium; G by the US Department of Defense; H by the US Army Research Lab; I by Netnod in Sweden; J by Verisign; L by ICANN; M by WIDE Project in Japan.

K is operated by the RIPE NCC, the regional internet registry for Europe, the Middle East and parts of Central Asia, headquartered in Amsterdam.

The spread is deliberate. Governments, universities, non-profits and commercial firms across three continents share the responsibility. No single jurisdiction can pull the plug.

K-root, the letter with no home address

K-root has five core sites, and none of them is a headquarters in any meaningful sense. RIPE NCC’s published peering policy lists them as Amsterdam, Frankfurt, London, Miami and Tokyo. The London core node sits inside the London Internet Exchange, one of Europe’s largest peering points, alongside a great deal of other critical infrastructure.

Everything else is hosted. Anyone meeting RIPE NCC’s technical requirements can apply to run a K-root node, and hundreds of networks have. The public register lists 159 K-root sites, 143 of them currently operational, from Reykjavík to Doha to Nairobi to Ulaanbaatar.

Each of those sites is a small rack answering the same IP address, 193.0.14.129, as every other K-root site. Each announces the same prefixes from the same autonomous system number, AS25152. From the outside, K-root looks like one very fast server. From the inside, it is a distributed swarm.

The wider point of the anycast design is that no single site is precious. If the London node went dark tomorrow, K-root would still answer from 142 other locations, and users elsewhere in the world would not notice. Resilience is achieved by having many ordinary sites, not one heroic one — a pattern echoed in the way submarine cables carry intercontinental traffic.

What happens when the root is attacked

Because the root is the visible top of DNS, it draws attacks. The two most-cited incidents are from October 2002 and February 2007, both flooding attacks aimed at the root server addresses.

ICANN’s post-incident factsheet on the 2007 attack records that the flood began around 12:00 UTC on 6 February 2007, ran for about two and a half hours, and was followed by a second wave lasting five hours. Six of the 13 root identities were affected. Only two were noticeably degraded: G-root, then run by the US Department of Defense, and L-root, run by ICANN. Both were among the handful that had not yet deployed anycast.

The 2002 attack is often remembered as the moment the internet “almost went down.” The contemporary record is more restrained. The same ICANN factsheet describes the 21 October 2002 attack as having swamped nine of the 13 servers, and notes that the internet continued to run throughout — resolvers held cached answers and normal browsing was largely unaffected. It was, in ICANN’s framing, a wake-up call rather than an outage.

That wake-up call drove the industry-wide push to anycast. By 2007, most of the letters had made the switch, and the difference showed: the two identities that suffered were precisely the two that had not.

Neither event actually took the DNS offline. Both, however, made clear that the root is a target, and that survival depends on the fact that thousands of physical machines answer to just 13 names.

The parts the story usually leaves out

Three things are commonly muddled in casual retellings.

First, “13 servers” has not been literally true for more than 20 years. It has been 13 identities served by a large and growing anycast fleet since the early 2000s. Anyone still picturing 13 racks in 13 rooms is picturing the 1990s.

Second, the root does not authenticate the whole internet. It signs and publishes a list of top-level domain operators through DNSSEC, and that signature chain lets resolvers verify answers all the way down. But the root does not know or care what IP address any given website uses. That knowledge lives further down the tree.

Third, K-root is not “the British root server.” There is no British root server, or American one, or Japanese one, in the sense of national ownership. K-root is operated by a Dutch non-profit, hosted at more than 140 sites in dozens of countries, and happens to keep one of its five core nodes inside a London peering hall. The rest of the letters follow the same pattern of dispersed hosting under a single operator.

The system works because everyone agreed, decades ago, to keep the top of it boringly simple: a short list, a small file, and enough redundancy that no one location matters very much. Somewhere in a London exchange, and in Reykjavík, and in Nairobi, and in a hundred and forty other rooms, the same six-digit answer is going out to the same address, 1.6 million times a second, and has been all day.