Type bbc.co.uk into a browser and, for a fraction of a second, nothing on the screen changes. In that pause, the computer is not fetching a page. It is asking a question: what is the numeric address of the machine that answers to that name? The answer will come back as something like 151.101.0.81, and only then does the browser open a connection. The lookup is called DNS — the Domain Name System — and it is one of the oldest pieces of the modern internet still doing its original job.
The reason it exists is boring and important. Computers route traffic using IP addresses, strings of digits like 142.250.72.14. Humans do not remember strings of digits. In the early 1980s, every machine on the ARPANET kept a single text file, HOSTS.TXT, listing every other host on the network. As the network grew, maintaining that file by hand became impossible. In 1983, Paul Mockapetris published RFC 882 and RFC 883, proposing a distributed, hierarchical database that any computer could query. That is the system still in use forty years later.
What actually happens when you press Enter
The browser first checks its own cache, then the operating system’s cache, then a local file (/etc/hosts on Linux and macOS, hosts on Windows). If nothing matches, the request goes out to a recursive resolver — usually run by an internet service provider, or a public one like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1. The resolver’s job is to do the legwork so the browser does not have to.
If the resolver has answered a query for the same domain recently, it returns the cached answer immediately. If not, it walks the hierarchy from the top. It asks a root server: where do I find information about .uk? The root points to the servers responsible for .uk. Those servers point to the ones responsible for .co.uk. Those point to the servers that hold the authoritative record for bbc.co.uk. The resolver collects the final IP address, hands it back to the browser, and stores it locally for a while so the next lookup is instant.
The whole exchange typically takes tens of milliseconds. On a warm cache, it takes almost none.
The 13 root servers, which are not 13 servers
At the top of the hierarchy sit the root name servers. There are exactly 13 of them, labelled A through M. This is one of the most misunderstood facts in networking. There are not 13 physical machines humming in 13 rooms. There are 13 identities — 13 IP addresses — operated by 12 different organisations, including Verisign, the University of Maryland, NASA, the U.S. Army Research Lab, ICANN, RIPE NCC, and WIDE Project in Japan.
Behind each of those identities is a global fleet. A single root server letter is served by hundreds of physical machines spread across the planet using a trick called anycast routing. Many machines advertise the same IP address, and the internet’s routing protocols steer each query to the nearest one. As of 2024, the root server system runs from more than 1,900 instances in over 150 countries. Ask a.root-servers.net a question from London and from Sydney and two entirely different machines answer, both truthfully claiming to be A.
Why exactly 13? Because early DNS responses had to fit inside a single 512-byte UDP packet, and 13 root server addresses, plus their metadata, was the largest number that fit reliably. The limit is a historical artefact, but the number stuck.
What the roots actually know
The root servers do not know where bbc.co.uk lives. They do not know where any website lives. They know one thing: for each top-level domain — .com, .uk, .org, .jp, .museum, and so on — which servers are authoritative. That list, the root zone file, is a couple of megabytes of plain text. It is edited by IANA (the Internet Assigned Numbers Authority, now part of ICANN) and published to the root operators, who serve identical copies from every one of those 1,900-plus instances.
Everything else in DNS — the addresses of billions of individual domain names — lives further down the tree, on servers operated by registries, hosting companies, and domain owners. The roots are the index at the front of the book, not the book itself.
Caching is what makes it work
If every browser lookup actually walked from the root down, the root servers would collapse under the load. They do not, because almost nothing reaches them. Each answer in DNS carries a time-to-live value telling resolvers how long they may reuse it. TLDs like .com have TTLs measured in days. Individual domain records typically last minutes to hours. A busy resolver like Cloudflare’s may answer millions of queries for google.com from a single cached record, hitting the roots only when that record eventually expires.
Measurements published by the root server operators show that the vast majority of queries that do reach the roots are for names that do not exist — typos, misconfigured devices, malware phoning home to defunct command servers. The system was designed to be answered from cache. It works because it almost always is.
The seams that show
DNS has several quirks worth knowing. The first is that lookups have historically been unencrypted. Even when a site is loaded over HTTPS, the DNS query itself has traditionally travelled in plain text, which is why HTTPS does not hide which sites you visit — your ISP can still see every domain you open. Newer protocols, DNS over TLS and DNS over HTTPS, encrypt those queries between the browser and the resolver, but adoption is uneven and the resolver itself still sees everything.
The second is that DNS is trusted by default. When a resolver returns an answer, the browser generally believes it. In 2008, security researcher Dan Kaminsky showed that this trust could be exploited: an attacker who guessed the right timing could poison a resolver’s cache with fake records and redirect traffic. The fix, still being deployed today, is DNSSEC, which signs DNS records cryptographically so a resolver can verify them. Most top-level domains are signed. Many individual domains still are not.
The third is that a small number of resolvers now handle a very large share of the world’s queries. Google’s 8.8.8.8 and Cloudflare’s 1.1.1.1 together serve billions of lookups a day. That is convenient — they are fast, well-run, and support modern encryption — but it also concentrates a lot of the internet’s most sensitive metadata in a handful of companies.
Why any of this matters
DNS is one of the few places where the internet’s original architecture is still visible in daily use. The hierarchy, the caches, the anycast fleets, the plain-text zone file at the top — it is all still there, quietly turning names into numbers billions of times a second. When a browser can’t reach a site, the failure is often not in the site or the network but in this invisible lookup, timing out somewhere between a home router and a cluster of machines in Tokyo or Amsterdam pretending to be a single computer called K.
The remarkable thing is not that DNS occasionally fails. It is that a system designed in 1983 for a network of a few thousand hosts still holds up a network of billions, and does it fast enough that most people never notice it is there.
