DNS in Depth

Computers talk in numbers — an address like 93.184.216.34 (or a longer IPv6 one). People talk in names — example.com. The Domain Name System is the vast, humming translation layer between the two, and it may be the most successful distributed database ever built: it answers trillions of queries a day, has no single owner, and has never once been switched off. You met the one-line summary — "DNS turns names into addresses" — in an earlier lesson. This page is about how it pulls that off at planetary scale, which turns out to be a beautiful piece of engineering: a hierarchical, delegated, aggressively cached tree.

The magic trick is that no single machine knows where example.com lives — and it doesn't need to. The answer is assembled by walking a tree, each level pointing one step closer, with caches short-circuiting almost all of the work. Let's build that tree, then walk it.

The name is a tree, read right to left

A domain name is a path through a hierarchy, and — unlike a file path — you read it right to left, from most general to most specific. There is an invisible trailing dot: the fully-qualified name is really www.example.com.

The final . is the root — the top of the whole tree, run by a small set of coordinated root servers.
com is a top-level domain (TLD) — others are org, uk, io, museum. Each TLD is run by a registry with its own servers.
example is the second-level domain, the bit someone registered. Its owner runs (or rents) authoritative servers that hold the real answers.
www is a subdomain the owner created; they can make as many as they like below their name.

The genius is delegation: the root does not know example.com's address. It only knows "for anything ending in com, go ask the com servers." The com servers don't know the address either — they know "for example.com, go ask these authoritative servers." Authority is handed down the tree one level at a time, so no server ever has to know more than its own children. That is what lets the system grow without limit: adding a new domain touches only its parent.

The resolution walk

When your laptop needs www.example.com, it asks a resolver (usually run by your ISP or a public service like 1.1.1.1). The resolver does the legwork, walking the tree from the root down. The diagram traces the full journey — press play, or step through it.

Two words in that picture carry the whole design. A recursive query says "don't come back to me until you have the final answer" — that is what your device asks its resolver. An iterative query says "give me your best answer, even if it's just a pointer to someone else" — that is what the resolver asks the root, TLD and authoritative servers. Your device delegates the hard work once; the resolver does the patient tree-walk on its behalf. Crucially, the root and TLD servers never look anything up for you — they only ever hand back a referral to the next level down, which is exactly why they can survive the entire Internet's traffic.

What lives in the database: resource records

The answers DNS returns are resource records (RRs). A record is roughly (name, type, TTL, value). The type decides what the value means, and a handful cover almost everything you'll meet:

Type	Maps a name to…	Example use
A	an IPv4 address	`example.com → 93.184.216.34`
AAAA	an IPv6 address	`example.com → 2606:2800:220:1::`
NS	the authoritative name servers for a zone	the referrals in the walk above
MX	a mail server (with a priority)	where `@example.com` email goes
CNAME	another name (an alias)	`www.example.com → example.com`
TXT	arbitrary text	domain verification, SPF/DKIM email policy

A CNAME is worth dwelling on because it is so often misunderstood. It says "this name is just another name for that name — go resolve that one instead." When a resolver hits a CNAME it restarts the lookup on the target and follows it to a real A/AAAA record. This is the trick behind pointing www.yoursite.com at a CDN like yoursite.cdn-provider.net without ever knowing the CDN's changing IPs.

Caching and TTL: why the tree isn't hammered to death

If every one of the trillions of daily lookups actually walked from the root, the root servers would vaporise. They don't, because DNS is cached everywhere. Every record carries a TTL (time to live, in seconds) that says "you may reuse this answer for up to this long before asking again." Your resolver, your operating system, and your browser each keep a cache.

The effect is dramatic: the first person on your ISP to want example.com triggers the full walk; for the next thousand people (and for you, on your next thousand visits), the resolver answers from cache in under a millisecond. The root and TLD servers see only cache misses — a tiny fraction of real demand. TTL is the dial that trades freshness against load: a long TTL (a day) means fast, cheap answers but slow propagation of changes; a short TTL (a minute) means changes take effect quickly but the caches refill constantly.

A DNS query is tiny — a name and a type — and the answer usually fits in a single packet. Opening a TCP connection (a three-packet handshake before you even ask) for one question you'll repeat billions of times would be absurd overhead. So DNS runs over UDP port 53: fire one datagram, get one back, done — one round trip, no connection state on the server. If the answer is too big to fit (large record sets, or DNSSEC signatures), or if a response is truncated, the client retries over TCP. UDP for the common tiny case, TCP as the reliable fallback — a nice example of picking the transport to fit the traffic.

DNS as a steering wheel

Because DNS sits at the very start of every connection — you resolve a name before you talk to a server — it has quietly become the Internet's traffic-steering layer, doing far more than lookup.

Load balancing. A name can have several A records; the resolver hands them out in rotation (round-robin DNS), spreading users across servers.
Geo-routing / CDNs. A CDN's DNS can answer the same name with a different address depending on where you're asking from, sending you to the nearest edge server. This is how a content delivery network gets you a copy of the page from a machine in your own city.
Failover. Pull a dead server's A record (or lower its weight) and, once caches expire, traffic drains away from it automatically.

That last point is exactly why the misconceptions below bite so hard: the same caching that makes DNS fast also makes it slow to change its mind.

Two tangled misconceptions. First, DNS is not "the Internet" or "the web" — it is only the phone book. Resolving example.com to an IP does nothing by itself; you still have to open an HTTP connection to that IP to actually fetch anything. When people say "DNS is down so the site is down," the site is usually fine — it's just unreachable because nobody can look up its address.

Second, a CNAME is not an HTTP redirect. A redirect (301/302) is an HTTP response that changes the URL in your browser's address bar. A CNAME is invisible name resolution that happens before any HTTP at all — the browser still thinks it's talking to the original name, and the address bar never changes. They operate at different layers entirely.

And the classic operational trap: you change a record but the old value lingers. That's TTL caching, not a broken change. If a record has a 24-hour TTL, resolvers around the world may serve the stale answer for up to a day. The fix is to lower the TTL well in advance of a planned change, then raise it again afterwards.