DNS Resolution Path
Prompt
Your browser has a hostname and needs an IP. Walk me through the resolution from cache miss all the way to the answer — and be precise about the difference between the resolver doing the work and the servers that hold the authoritative data.
How this round runs
This is a conversation that escalates — I'll keep asking "and what happens when…" until I find the edge of what you know. I want the recursive-vs-authoritative distinction to be crisp, and I'll push into caching of negative answers and what DNSSEC does and does not buy you — be honest at that boundary.
Model answer
I'll trace it and keep the two roles separate, because that's the distinction that
matters. On a cache miss the stub resolver in the OS asks a recursive resolver (your ISP's,
or a public one). "Recursive" describes behavior: that resolver does the legwork — it queries
a root server, which doesn't know the host but refers it to the .com TLD servers; the TLD
server refers it to the domain's authoritative nameservers; the authoritative server is the
one that actually holds the zone and returns the A/AAAA record. So root and TLD servers
are referral (iterative) servers — they answer "ask over there," never the final IP — while
the recursive resolver chains those referrals on the client's behalf and the authoritative
server is the source of truth for that zone. That separation is what lets the system scale:
roots never store individual hostnames, and each layer caches.
Caching is governed by the record's TTL, and the consequence is propagation: a low TTL lets
you move an IP fast but multiplies query volume; a high TTL is cheap but means a change
lingers in caches until it expires. The piece people forget — and where the first follow-up
goes — is negative caching: a NXDOMAIN (name doesn't exist) is also cached, with a
duration driven by the zone's SOA minimum/negative-TTL field, so a typo or a not-yet-created
record can stay "missing" in your resolver's cache even after you create it.
DNSSEC is where I'll mark my boundary precisely, because what it protects is narrower than people assume. It signs records so a resolver can verify a chain of trust from the root down and detect forged or tampered answers — it protects integrity and authenticity. It does not encrypt anything: the query and answer are still in cleartext on the wire, so DNSSEC gives you no confidentiality — that's what DoH/DoT are for. And it authenticates the data, not the transport, so it doesn't by itself stop an observer from seeing which domains you look up. I'm confident on that integrity-vs-confidentiality split; the exact signing-algorithm rollover mechanics I'd verify rather than assert.
- Kept role (recursive = does the legwork) separate from authority (holds the zone) instead of blurring them
- Identified root/TLD as referral servers that never return the final IP
- Tied TTL to the real consequence — propagation delay vs. query volume
- Brought up negative caching (NXDOMAIN via SOA) as a distinct, often-missed mechanism
- Drew the DNSSEC boundary precisely: integrity/authenticity yes, confidentiality no
- You create a record that someone already queried and got NXDOMAIN — why might they still not see it? → negative caching: the NXDOMAIN is cached for the SOA negative TTL
- What exactly does DNSSEC protect, and what does it NOT? → protects integrity/authenticity via a signed chain of trust; does NOT encrypt or hide which domains you query
- And what happens when you lower a record's TTL right before a planned IP migration? → only helps once the OLD high-TTL entries already cached have expired; lower it ahead of time