How DNS Works: The Invisible Phone Book That Runs the Internet

From Tukuk-OS Wiki, the free knowledge base.

Every click starts with a lookup you never see: a name becomes a number in tens of milliseconds, through a global, cached, hierarchical database nobody centrally controls. Here is the machinery of DNS — roots, TLDs, resolvers, records and TTLs — and its documented weak spots.

The Problem DNS Solves

Computers route traffic by numeric address — IPv4's dotted quad like 104.26.10.78, IPv6's long colon-hex string — while humans think in names. DNS, the Domain Name System, is the translation layer, designed in the early 1980s by Paul Mockapetris to replace a single hand-maintained hosts file that had become an impossible bottleneck at a few hundred internet sites. The design requirement was cleverness under scarcity: a global name-to-address database, queried trillions of times a day, that no single organisation runs, no single outage can kill, and that stays fast enough that you never notice it. The answer was a hierarchy plus caching. The namespace is a tree, read right to left: the root at the dot that ends every formal domain name, below it the top-level domains — .com, .org, .my, .dev, the two-letter country codes — below those the second-level domains people actually register, below those hosts and subdomains. Each level is delegated: the root server operators do not know where tukuk.org lives; they only know who is authoritative for .org, and .org's servers only know who is authoritative for tukuk.org. Responsibility, like the tree, flows downward.

What Happens in the Milliseconds After You Click

When your browser needs example.com, it asks your operating system, which consults local caches first, then the recursive resolver — usually your ISP's, or a public one like 1.1.1.1 or 8.8.8.8. The resolver does the hierarchy walk on your behalf: it asks a root server (using a hardcoded list called root hints), which refers it to the .com TLD servers, which refer it to the two or four authoritative name servers the domain's owner configured — the ones holding the domain's actual zone file. The zone answers with records, and the record types are the real vocabulary of the system: A and AAAA map a name to IPv4 and IPv6 addresses; CNAME aliases one name to another; MX designates mail servers, which is why email broke first whenever DNS broke; TXT carries free-form text used for domain verification and anti-spam policy; NS names the authoritative servers themselves; and each record carries a TTL, a time-to-live in seconds, telling every cache along the path how long the answer may be remembered — five minutes for a service that moves fast, a day for one that does not. The resolver returns the final address to your browser and caches every step of the answer, so the next visitor to the same domain in the same city gets it instantly. That caching cascade — browser cache, OS cache, resolver cache, and the network-effect of popular names being cached everywhere — is why the lookup normally costs a round trip to a resolver a few milliseconds away rather than the six-server walk the system would otherwise perform.

The Design's Age Shows, Honest Version

DNS was specified when the internet was a few hundred trusted institutions, and three consequences still bite. It is, by default, unauthenticated: an authoritative answer is a claim, not a proof, and until DNSSEC rolled out — cryptographic signatures on zone data that validators can verify up to a trusted anchor — an attacker who could spoof a resolver's traffic could poison its cache with a false address for a popular domain; the 2008 Kaminsky attack, which demonstrated the flaw at scale, is the reason DNSSEC now exists on a meaningful share of domains, though adoption is uneven because it requires work from every zone operator in the chain. It is largely plaintext: classic DNS queries on port 53 are visible to anyone on your network path, revealing every domain you contact — the privacy problem that motivated DNS-over-HTTPS and its siblings, which tunnel lookups inside encrypted transport, covered properly in our DNS-over-HTTPS explainer. It is centralised at the registration layer: while resolution is distributed, the root zone and TLDs are administered through a handful of organisations under US jurisdiction, a real geopolitical fact no protocol design has changed. And TTLs create the operational double-edge that any site mover learns the hard way: caches make DNS fast, and make changes slow — you must shorten the TTL before moving servers, or visitors keep receiving the old address until patience runs out.

Why It Deserves a Place in Your Mental Model

Most web performance and reliability advice quietly involves DNS: the "DNS lookup" sliver in your browser's network timings, the reason a CDN needs low-TTL records to failover region by region, the way a reverse proxy sees your visitor's real IP only after both name and address cooperate, and the reason a domain expiry can take a business offline days after the payment card simply lapsed. A domain name is not a resource you own so much as a delegation you rent inside somebody else's tree — renewed annually, pointed through name servers, resolved trillions of times a day by a 40-year-old hierarchy whose core design (hierarchy, delegation, caching, eventual consistency) is now textbook distributed-systems practice. The next time a page loads instantly, spare a thought for the quiet part: before any byte of the page moved, your machine raced through a global phone book, asked the root of the internet's naming tree a polite question, and got an address back in time you could measure in milliseconds — a system old enough to be infrastructure, and strange enough to still run the world.

See also

• Undersea Cables: The Physical Internet Under Your Ocean
• Reverse Proxies and the Death of "Real" Client IPs
• How Fiber Optics Turned Light Into the Internet
• DNS over HTTPS (DoH): When Your Resolver Starts Lying
• Cloudflare Anycast and What It Means for Global Availability