How DNS Resolution Actually Works

“It’s always DNS” is a running joke in operations because it’s a running truth. Name resolution sits underneath almost everything, it fails in quiet and confusing ways, and most people treat it as a single magic step: name goes in, address comes out. It isn’t one step. It’s a chain of caches backed by a walk down a global tree, and once you can picture that chain, the joke turns into an actual troubleshooting method.

The tree, and the walk down it

Domain names are hierarchical, read right to left. www.example.com. is: the root (the trailing dot), then the top-level domain com, then example, then the host www. That hierarchy is also how the answer is found — by asking down the tree:

1. Ask a root server: where do I find com? It replies with the TLD servers for com.
2. Ask a com server: where do I find example.com? It replies with the authoritative servers for that domain.
3. Ask the authoritative server for example.com: what’s the address of www? It gives the actual answer.

The server doing this walking on your behalf is a recursive resolver — the one your machine or network points at. It does the legwork of asking down the tree; the servers along the way are authoritative (they hold the real records for their slice). That split — recursive resolvers that find answers vs authoritative servers that hold them — is the core of DNS.

Nobody actually walks the tree most of the time

If every lookup walked from the root, DNS would be slow and the root servers would melt. The whole thing is saved by caching at every layer, and the cache is the part that matters most for debugging:

• Your application and OS cache recent answers.
• Your recursive resolver caches aggressively — if it looked up example.com a minute ago, it answers from memory instead of walking the tree again.
• Each record carries a TTL (time to live) that says how long it may be cached.

So a “resolution” is usually just a cache hit somewhere near you. The full walk only happens on a cache miss. This is efficient and it’s also the source of DNS’s most infamous behavior: you changed a record and the old answer is still coming back. Not because anything’s broken — because a cache somewhere is still inside the TTL and hasn’t asked again. The change is real; a cache in the chain hasn’t caught up. It’s the canonical case of when in doubt, suspect the cache: the record updated, but layers of caches between you and the truth each hold their own copy.

Records are more than name-to-address

A DNS answer isn’t only “name → IP.” The record type matters:

• A / AAAA — the IPv4 / IPv6 address for a name. (Publishing an AAAA record is also how a host becomes reachable — and discoverable — over IPv6, which is its own security consideration.)
• CNAME — an alias pointing one name at another, resolved by following the chain.
• MX — where mail for the domain should go.
• TXT — arbitrary text, used for domain verification, email authentication (SPF/DKIM), and more.
• NS — which servers are authoritative for the domain (the delegation the walk follows).

A lot of “DNS problems” are really the wrong record type or a record that resolves but points somewhere stale — the name works, the destination is wrong.

Why this is a debugging superpower

Knowing the chain turns vague “DNS is broken” into precise questions you can actually answer:

• Is it a cache, or the source? Query your normal resolver, then query an authoritative server (or a different public resolver) directly and compare. If they disagree, you’ve got a caching/propagation issue, not a bad record — wait out the TTL or flush.
• Where does the chain break? Trace the resolution and watch which delegation step fails — a missing NS record, a lame delegation, an authoritative server not answering.
• Right answer, wrong type? Confirm you’re looking at the record type the client actually uses (an app wanting AAAA won’t be helped by a correct A record).
• Is resolution even the problem? Half the time “the site is down” is really “the name resolves fine and the service is refusing” — which you rule out in seconds once you can separate the lookup from the connection.

DNS feels like magic until you see it’s a cached walk down a tree, at which point it becomes one of the most diagnosable systems you deal with — every failure is a specific link in a specific chain. That’s why “it’s always DNS” isn’t fatalism; it’s a reminder to check the layer everything else quietly depends on. If you’ve caught a gnarly DNS issue by finding the exact link that broke, I’d like to hear about it.