DNS: The Internet’s Phone Book

The problem

Adda has a real name now. Ria paid for adda.com so Fahim would stop typing a raw IP address into his browser like it was 1994. It felt like a milestone — until the link started dying.

The trouble is that Adda still runs on the laptop under Ria's desk, behind her home internet connection, and her ISP hands that connection a different IP address every few days. Every time it rotates, the number the network needs to reach Ria's laptop changes — but the name Fahim typed does not. Something has to sit between the name and the number, and update itself when the number moves. And this translation happens before every single connection: get it slow and every page on Adda inherits the delay; get it wrong and Adda simply vanishes for Fahim, even though the laptop is humming along perfectly. This is quiet infrastructure that, when it hiccups, takes the whole site down with it.

A first attempt

Ria's first idea was the blunt one: keep a little file mapping adda.com to the current IP — like the old /etc/hosts — and just make sure everyone has a copy.

That works when your "everyone" is Fahim and you can text him the new number. It falls apart the instant Adda has more than a handful of users. The real internet has hundreds of millions of domains changing constantly; a single shared file would be enormous, instantly stale, and impossible to update everywhere at once. Worse, one central authority editing one file becomes both a bottleneck and a single point of failure for the entire planet. A flat, centralized lookup does not scale — Ria needs something distributed and hierarchical.

The insight

Split the phone book into a tree, and let each level answer only for the part it owns.

Nobody knows every name. Instead, responsibility is delegated: root servers know where to find the .com servers; the .com servers know where to find adda.com's servers; and those servers know the actual IP of Ria's laptop. Each node hands you off to the next. Layer caching on top — everyone remembers answers for a while (the TTL) — and most lookups never travel the full tree at all. Distribution solves scale; caching solves speed.

How it works

The delegation chain, top to bottom:

Common record types Ria will actually name in a design:

• A / AAAA — name → IPv4 / IPv6 address.
• CNAME — name → another name (alias, e.g. www → adda.com).
• NS — which name servers are authoritative for a zone.
• MX — mail servers for the domain.

The numbers

Adda's real DNS behavior once the record is live:

• Cold lookup (full tree walk): ~4 queries, often 50–200 ms total depending on distance to each server.
• Warm lookup (cached): < 1 ms — served from the resolver or the OS.
• Cache hit rate at a busy resolver is typically 90%+, which is why DNS rarely dominates Adda's page load.
• TTL choices: because Ria's home IP keeps moving, she keeps Adda's TTL low — 30–60 s — so a change propagates fast. A stable corporate site might use 24 h to cut lookup volume.
• Propagation: after Ria changes the record, old answers linger in caches worldwide for up to the previous TTL — so she lowers the TTL a day before a planned move.

Practice

Recap

• DNS is a distributed, hierarchical lookup: root → TLD → authoritative, each level delegating to the next.
• Caching with TTLs makes it fast — most lookups never leave the resolver.
• DNS doubles as a routing and failover control, but its TTL is a genuine agility-vs-load trade-off and a real single point of failure — which is exactly why Adda keeps its TTL short while its address is still moving.