The Internet's Phone Book Runs on 13 Servers That Aren't Really 13

On the evening of October 2, a submarine cable segment between the Philippines and Singapore went dark. PLDT, one of the country's largest carriers, said it lost roughly 300 gigabits per second of international capacity. Globe and Converge scrambled to reroute traffic through backup cables, and by October 4 service had largely normalized. The physical internet, it turns out, is surprisingly fragile: a bad day on the seafloor can slow a whole country.

But one detail went unremarked through the whole episode. While the cables were broken, the names kept working: every slowed-down website still resolved to the right address. The outage broke paths, not names, because the system that turns names into numbers is a separate layer of the internet, engineered to survive failures that would cripple almost anything else. It is called the Domain Name System, and almost nobody who depends on it understands how it works.

Four stops between a keystroke and an IP address

Type calder-brief.pages.dev into a browser and, before anything visible happens, your machine asks a question: what number is this name? The question travels a short, strict chain, and the elegant part is that you only ever talk to the first stop.

Stop one is the stub resolver, a small piece of software inside your operating system that knows almost nothing about DNS. Its only job is to forward your question to stop two: a recursive resolver, usually run by your internet provider, though millions now use public alternatives like Cloudflare's 1.1.1.1, Google's 8.8.8.8, or Quad9's 9.9.9.9. The recursive resolver is the only component that does real detective work: it asks the questions, follows the referrals, and hands your device a single final answer.

For a name nobody has looked up recently, the detective work runs up the hierarchy. Stop three is one of the thirteen root servers, which does not know where calder-brief.pages.dev lives. It only knows which servers handle .dev, and it says so. The resolver asks a .dev server, which points to the authoritative nameserver for the domain, and that final server returns the actual IP address. Four stops, one answer, and the upper three tiers never speak to each other. Only the recursive resolver talks to all of them.

Why the famous number is thirteen

The internet famously runs on thirteen root servers, lettered A through M, and the number is an accident of engineering history. In the original DNS specification, a UDP response was limited to 512 bytes, and thirteen server addresses was roughly what fit. An extension called EDNS0 removed that limit long ago, but the thirteen identities remain.

They are identities, not machines. The thirteen names are operated by twelve independent organizations: Verisign runs two (A and J), and the rest belong to universities, companies, nonprofits, and government agencies, including USC, the University of Maryland, NASA, the Internet Systems Consortium, Netnod, RIPE NCC, ICANN, and the WIDE Project. Behind each identity sit dozens or hundreds of physical servers worldwide, all announcing the same IP address through a routing technique called anycast. When your resolver queries a root server, the internet's own routing delivers the question to whichever copy is closest, so a flood of malicious traffic gets absorbed by the nearest copies instead of taking down the whole system.

Getting started requires breaking a chicken-and-egg problem: to look up anything, you first need a root server's address, which you cannot look up. The industry solves it with a tiny published file called root.hints, about 3 kilobytes, that resolvers ship with. The root zone itself, the file of roughly 1,500 delegations saying who runs .com, .uk, .dev, and every other top-level domain, is published openly and mirrored freely. The data and the people serving it are deliberately separate things.

The root server never answers your question. It only points you toward someone who can, and that is the whole trick.

The busiest part of DNS is the part that avoids doing work

Here is the paradox that makes the whole system scale. The thirteen root identities can serve a planet because almost nobody asks them anything. DNS is, above all, a caching system, and caching happens at every level.

Every DNS answer carries a time to live, a TTL, set by the domain's owner, saying how long the answer may be reused. Your browser caches answers, your operating system caches answers, and your recursive resolver caches answers for every device behind it. When you visit a popular site, the resolver almost certainly already knows the address and responds in milliseconds. The full chain only runs for names that have expired from every cache along the way. As ICANN's own training materials note, most DNS queries are never handled by a root server, because recursive servers remember the answers they were given.

This is also why the system degrades gracefully instead of collapsing. Caches turn a live dependency into a slowly expiring one: even if large parts of the hierarchy went dark, the internet would keep resolving names for as long as cached answers lasted, measured in hours or days, not seconds. The design assumes failure and buys time with memory.

What keeps the answers honest

A system this distributed needs a way to prove that answers have not been tampered with, and that is the job of DNSSEC. The root zone is cryptographically signed, and each layer signs the next, forming a chain of trust from the root down to individual domains. A validating resolver can detect a forged answer the way you would detect a broken seal on a letter. Running the zone data and serving it are separate responsibilities, so no single operator can quietly rewrite the directory.

Privacy has been the slower upgrade. Classic DNS is plaintext on UDP port 53, so anyone on your network path could historically see every name you looked up. DNS-over-HTTPS and DNS-over-TLS now encrypt the link between your device and your resolver, and an IETF standard called QNAME minimization means the root typically sees only the top-level domain you ask about, not the full name. Neither hides your lookups from your resolver itself, so choosing a resolver you trust remains a meaningful decision.

So what could actually break it?

The honest answer is less dramatic than the mythology. The root is protected by anycast redundancy, twelve operators across jurisdictions, a zone file anyone can download, and caches that buy days of grace. The realistic failure modes are mundane and local: your ISP's resolver misbehaving, a misconfigured update at a registry, a bad software push at a big public resolver. Those happen, and they feel like the internet breaking, but they are outages of a provider, not of the naming system.

That is the perspective the cable cut in the Philippines quietly demonstrated. The seafloor is the fragile part of the internet: physical fiber, vulnerable to anchors, faults, and time, with repairs that take weeks and ships to perform. The naming layer above it is the resilient part, built from open data, aggressive caching, cryptographic signatures, and a hierarchy whose most famous thirteen servers are asked almost nothing at all. Every page you load depends on both, but only one of them was designed to be taken for granted.