How DNS Actually Works

You type google.com and hit Enter. In the next hundred milliseconds, your computer starts a chain of conversations with servers it has never met. And any one of them could lie to you.

The Question Your Browser Can't Answer

Your browser doesn't know where google.com lives. So it asks your OS, which checks its cache — a short-term memory of recent lookups. Visited google.com thirty seconds ago? Answer's already there. No network traffic.

Cache empty? Your OS sends the question to a recursive resolver — a detective that goes out into the internet and finds the address. Your ISP runs one. Google runs one at 8.8.8.8. Cloudflare runs one at 1.1.1.1.

Your machine just waits. The resolver does the legwork.

Four Hops Down a Tree

The resolver starts at the absolute top: the root servers. There are 13 root server addresses, hardcoded into every resolver on Earth.

Hop	Server	What It Knows
1	Root server	Who handles .com
2	TLD server (.com)	Who handles google.com
3	Authoritative server (Google)	The actual IP address
4	Back to you	Browser connects

The root doesn't know Google's IP. But it knows who runs .com. The .com server doesn't know either, but it knows Google's authoritative name server. The authoritative server is the source of truth — it returns the IP address. Total time: roughly 80 milliseconds.

The "13 root servers" is a bit of a myth. There are 13 addresses, but behind them sit over 1,900 physical machines across every continent, using anycast — the same IP routes to whichever server is closest. Why only 13 addresses? Because in the 1980s, the root server list had to fit inside a single UDP packet.

Caching Makes It Instant

Almost nothing actually traverses all four hops. The secret is aggressive, layered caching.

Every DNS record carries a TTL (time to live) — a number that tells the resolver how many seconds it can keep the answer. A typical TTL is 300 seconds. For those five minutes, anyone using that resolver who asks for google.com gets the cached answer instantly.

Your browser caches. Your OS caches. The resolver caches. By the time a query actually reaches a root server, it's passed through three layers that all said "I don't know."

This is also why DNS changes "take 24-48 hours to propagate." There's no propagation. There's no broadcast. It's expiration — caches around the world holding the old answer until their TTL runs out.

The Attack That Nearly Broke the Internet

In 2008, security researcher Dan Kaminsky discovered a flaw that could redirect any domain on the internet. The vulnerability: when a resolver sends a query, it includes a transaction ID — only 16 bits. That's 65,536 possible values.

The attack: flood the resolver with forged responses, each guessing a different transaction ID. Guess right, and the resolver accepts a poisoned delegation record — routing an entire domain to the attacker's server. One successful guess controls everything under that domain.

Kaminsky kept it secret, quietly coordinated with every major DNS vendor, and on July 8, 2008, they all released patches simultaneously. The fix: randomize the source port on every query, turning 65,000 guessable combinations into billions.

That fix is still running right now, every time your browser loads a page. DNS was built in 1983 for a few hundred machines that all trusted each other. The patches, and later DNSSEC with cryptographic signatures, keep strengthening a system that was never designed for a hostile internet.

Watch the full animated breakdown: DNS — The Internet's Phone Book Has a Dark Side