When someone types wikipedia.org into a browser and hits enter, the page seems to appear at once. It does not. Before a single byte of the article loads, the computer has to answer a much more basic question: where, numerically, does wikipedia.org actually live? Computers do not route traffic by name. They route by IP address — a string like 208.80.154.224 for IPv4, or something longer and hexadecimal for IPv6. The job of turning the human name into the machine address falls to the Domain Name System, or DNS, and the path that query takes is stranger and more centralised than most people realise.
The system was designed by Paul Mockapetris in 1983 and first specified in RFC 882 and RFC 883, then revised four years later into RFC 1034 and RFC 1035, which are still the standards on which every DNS implementation is built. DNS replaced a single text file called HOSTS.TXT, maintained at SRI International in Menlo Park and manually distributed to every machine on the early ARPANET as new hosts joined. That file did not scale. DNS did, by turning the whole naming problem into a distributed tree — and the trunk of that tree is those 13 root server clusters everyone has heard about but almost no one has actually seen.
The first hop: your own machine, then your router
The lookup begins inside the operating system. Windows, macOS, Linux and every mobile OS keep a small DNS cache. If the name has been resolved recently, the answer is already sitting locally with a time-to-live counter ticking down, and no network traffic happens at all. Browsers keep their own cache on top of that. Chrome exposes its internal DNS state at chrome://net-internals/#dns. Firefox does the same at about:networking#dns. Both caches include not just successful lookups but also negative answers — records for names that don’t exist, held briefly so the next attempt does not go out on the wire again.
Every operating system has a stub resolver that decides where the initial query goes. On Unix-like systems, the answer sits in a small file called /etc/resolv.conf. On Windows it is set per network interface, controlled by DHCP unless the user overrides it. Most people have never seen either configuration. The machine quietly points itself at whatever address the router announced when they plugged in.
If nothing local matches, the query leaves the machine. In a typical home setup it goes first to the router, which is usually configured to act as a tiny DNS forwarder. The router almost never knows the answer itself; it passes the question upstream to whatever resolver it has been told to trust. By default, that is the ISP’s resolver. It may also be a public one — Google’s 8.8.8.8, Cloudflare’s 1.1.1.1, or Quad9’s 9.9.9.9 — if the user or the router vendor changed the setting. On a corporate network the query may pass through an internal resolver that filters, logs and rewrites answers before allowing the request onwards.
The recursive resolver does the real work
This upstream server is called a recursive resolver, and it is the workhorse of the whole system. Its job is to chase the answer down the DNS tree on the client’s behalf. If it already has a cached answer with time left on the clock, it returns that immediately, which is why popular sites resolve in a millisecond or two. If it does not, the chase begins.
The resolver starts at the top. It asks a root server: where do I find the servers that know about .org? The root server does not know where wikipedia.org is. It only knows who is authoritative for the .org top-level domain, and it hands back a referral. The resolver then asks one of those .org servers, which in turn does not know the IP of wikipedia.org but does know which nameservers Wikipedia itself has registered as authoritative. Finally the resolver asks one of Wikipedia’s own nameservers, which returns the actual IP address. The resolver caches every step of that answer, hands the final IP back to the browser, and the TCP connection can finally open.
To even begin the chase, the resolver has to know how to reach a root server in the first place. It does not learn this over DNS. It reads a short text file called the root hints file, which lists the names and IP addresses of the 13 roots and ships baked into resolver software such as BIND and Unbound. On startup, the resolver sends a priming query to one of those hints and gets back the current, authoritative list of root server addresses. That single response is the bootstrap. Everything downstream depends on it.
Only 13, and not for the reason people think
The root of the tree is the famous part. There are 13 root server identities, labelled a.root-servers.net through m.root-servers.net, operated by twelve independent organisations. Verisign runs two of them (A and J). The other eleven are USC’s Information Sciences Institute (B), Cogent Communications (C), the University of Maryland (D), NASA Ames (E), the Internet Systems Consortium (F), the US Department of Defense Network Information Center (G), the US Army Research Lab (H), Netnod in Sweden (I), RIPE NCC (K), ICANN itself (L), and the WIDE Project in Japan (M). The mix is deliberately diverse — governments, universities, non-profits, commercial operators, on four continents — so that no single jurisdiction or organisational failure can compromise all thirteen.
The number 13 is not arbitrary and not political. It comes from an old constraint in the DNS protocol itself. A priming response listing all root server names and their IPv4 addresses had to fit inside a single 512-byte UDP packet, because the original DNS specification limited responses on unextended UDP to that size. Thirteen entries with their names and IP addresses was the practical maximum that would fit without triggering truncation and a fallback to TCP. Fourteen would not. The limit is documented in the original DNS RFCs and discussed in detail by the root server operators.
But 13 servers could not possibly handle the global query load, and they do not. Each of those 13 identities is actually a cluster of hundreds of physical machines spread around the world, all answering to the same IP address using a routing trick called anycast. When a resolver in Sydney sends a query to a.root-servers.net, it reaches a nearby instance operated in Australia, not the original machine in Virginia. As of mid-2026 there are more than 2,000 root server instances worldwide, according to the operators’ own public statistics. There are still only 13 logical roots. There are thousands of physical ones.
Anycast is old technology by internet standards — described in RFC 1546 in 1993 by Craig Partridge and colleagues at BBN — but its rollout in the root system was slower. For years, only a handful of the 13 roots used anycast at all. Today every one of them does, and deployment sizes vary widely. F-root, operated by ISC, runs several hundred instances. Others sit in the single or low double digits. The root zone file that all of them serve is remarkably small — roughly two megabytes, generated and distributed by Verisign under contract to IANA. It contains no user domains, no MX records, no A records for individual sites. Just the delegation pointers for each top-level domain, and the DNSSEC signatures that let a resolver prove the file has not been altered.
Caching hides almost all of this
None of this happens most of the time. The root servers see relatively little traffic because resolvers cache the list of top-level domain servers for a long time — typically 48 hours for common TLDs like .com and .org, and 6 days for the root NS records themselves. In practice, a busy ISP resolver may go days without needing to ask a root server anything at all for the common TLDs, and the roots handle mostly negative answers, misconfigured queries, and lookups for obscure or newly created domains.
A 2025 study of B-root traffic conducted by researchers at USC-ISI, summarised by the Internet Society, found that more than 72 percent of all incoming queries to that root were unwanted. Chatter from misconfigured resolvers, leaked internal names like .local, botnet noise, and IoT devices with broken DNS libraries make up the bulk. ICANN’s own presentations have put daily root zone query volume in the tens of billions. Most of that volume is the DNS equivalent of dead letters, arriving because caching failed somewhere upstream. The system is designed to survive the noise, and it does — but most of what a root server hears is not a useful question.
What changed underneath, and what did not
The architecture Mockapetris described in 1983 is still recognisable four decades later, which is unusual for anything on the internet. What has changed is the transport. Classical DNS ran in cleartext over UDP port 53, which meant every resolver, every ISP and anyone with a packet capture between them could see exactly which sites a user was looking up. That is being replaced, slowly, by DNS over TLS and DNS over HTTPS, both of which encrypt the query between the client and the resolver. Android added DoT support in Android 9 in 2018. Firefox began defaulting to DoH for US users in early 2020. Apple added DoH and DoT in iOS 14 and macOS Big Sur later the same year. The hierarchy above the resolver — the roots, the TLDs, the authoritative servers — is largely unchanged.
DoH in particular has been contested. When the query is wrapped inside HTTPS traffic to a large public resolver, the ISP no longer sees which sites the user is looking up. Parental filtering services, corporate network administrators and some national regulators have all objected to browsers making that choice on the user’s behalf, and specific rollouts have been paused or scoped by jurisdiction in response. The encryption fixes one problem — passive surveillance between the client and the resolver — while shifting the trust question to whoever runs that resolver.
The system is also cryptographically signed at its most sensitive layer. DNSSEC lets a resolver verify that the answer it received from an authoritative server has not been tampered with in flight. The root zone itself is signed, and the ceremony that manages the signing key — the Key Signing Key, or KSK — is held approximately four times a year at ICANN’s two Key Management Facilities, one in Culpeper, Virginia and one in El Segundo, California. Trusted community representatives fly in. Safes are opened under dual-occupancy rules, smart cards are inserted into air-gapped hardware, the KSK signs the next quarter’s zone-signing keys, everything is filmed, and public transcripts are published afterwards. It is one of the few moments where the abstract internet becomes a room with a locked door.
The 512-byte packet limit that fixed the number of roots at 13 has itself been extended. In 1999, Paul Vixie introduced EDNS0, a mechanism by which a resolver can advertise support for larger UDP responses; it is now specified in RFC 6891. Modern resolvers regularly negotiate 4,096-byte payloads. Without that extension, DNSSEC — with its long cryptographic signatures — would have been effectively impossible over UDP. The 13-root limit stayed anyway. By the time the constraint was gone, the structure had been baked into every resolver on Earth.
The scale of the invisible
All of this — the recursive chase, the anycast routing to a nearby root instance, the TLD referral, the authoritative answer, the TLS handshake — is what happens before the browser can even ask for the first byte of HTML. On a warm cache it takes a millisecond or two. On a cold lookup to a distant authoritative server it can take a couple of hundred. Then the actual page begins to load.
The internet is full of these hidden systems that only announce themselves when they break. DNS is the one that has to work first, every single time, or nothing else on the network can begin. The next time a browser loads a page in what feels like an instant, it is worth remembering that somewhere between the keyboard and the screen, a query has just traversed a hierarchy that begins in a caching server two hops away and ends, ultimately, at a root of thirteen names — anchored, still, to a 1980s packet-size limit that everything else on the internet has quietly grown around. For more on how ordinary technology hides staggering engineering, see how GPS satellites correct for Einstein’s relativity or how Voyager 1 keeps transmitting on 22 watts of power.
