Following One Lookup Through Every Cache

Resolution is a fall-through. The browser has its own small host cache. Below it the OS stub resolver checks /etc/hosts and, on many systems, a local caching daemon (systemd-resolved on most Linux desktops, mDNSResponder on macOS, the DNS Client service on Windows). Below that, the recursive resolver — configured by DHCP or by hand — has a large shared cache. Only when all of those miss does anyone contact an authoritative server.

Each cache is independent, has its own view of the TTL, and is flushed by different means. That independence is a feature for performance and the source of every "works on my machine" DNS story. Note also that the stub does not usually cache negative answers or partial results; the recursive resolver does — the resolver’s cache is the one that matters.

dig +trace makes the recursive resolver’s job visible by doing it from your machine: ask a root server, follow the referral, ask the TLD, follow the referral, ask the authoritative server. Three round trips (plus one to fetch the root hints) is the cold cost; with a typical root or TLD instance 10–30 ms away, that is 50–100 ms before a TCP connection can even start. A warm resolver answers the same question from cache in well under a millisecond of its own time, so the round trip to the resolver dominates.

Notice what each server returns. The root does not know engineer-atlas.dev; it returns the NS records for dev. and, in the additional section, the addresses of those servers (glue) so the resolver can reach them. The dev. servers do the same for engineer-atlas.dev.. Only the last server answers the actual question. In practice, a resolver that has served any .dev name in the last two days already has the first referral cached and starts at step two.

Every record carries a TTL in seconds set by the zone owner. A cache may serve the record for that long and must then discard it. The TTL counts down as the record sits in a cache, and a resolver hands its remaining TTL to the client, which is why dig shows 287 for a record whose zone says 300. A TTL is a promise the zone owner makes to the world: "you may be this stale". Choosing it is a trade between the load and latency of frequent re-fetching and the time a change takes to be seen everywhere — DNS Record Types and What They Are For discusses the migration playbook.

Negative caching (RFC 2308) is the part people forget. "This name does not exist" (NXDOMAIN) is also cached, for a duration taken from the zone’s SOA record (its *minimum* field, conventionally 5–60 minutes for public zones). If you query a record before you created it, the resolver you used will keep saying it does not exist until that negative TTL expires — a classic self-inflicted outage during a deployment. Errors like SERVFAIL are also briefly cached by many resolvers.

Resolvers do not honour TTLs perfectly. Most cap very long TTLs (a day or a week is a common ceiling), some enforce a minimum, browsers keep their own short cache regardless of TTL, and some resolvers serve stale data when the authoritative servers are unreachable (RFC 8767 "serve-stale") — which keeps sites up during authoritative outages and also keeps them pointing at dead addresses. Do not reason about DNS as if every cache read the specification.

The same name legitimately resolves to different addresses for different clients, and understanding why is most of DNS debugging. Cache state: your resolver cached the old address five minutes ago; your colleague’s resolver fetched the new one just now. Resolver choice: you use the corporate resolver, which has a split-horizon view of internal names; the browser uses DoH to a public resolver, which does not. Geographic answers: CDNs and large services hand out an address near the *resolver* that asked, on the assumption that clients are near their resolver — which is why using a resolver in another country makes a CDN slow.

EDNS Client Subnet (ECS) refines that last case: a public resolver like 8.8.8.8 can include the client’s network prefix (typically a /24) in its query to the authoritative server, which then answers for the client’s location rather than the resolver’s, and caches per subnet. It fixes the geography problem and multiplies the number of distinct answers a resolver may hold for one name. Anycast resolvers (Internet Routing: Autonomous Systems and BGP) add another layer: 1.1.1.1 is hundreds of independent caches, and which one you reach depends on BGP.

The consequence for you: dig @8.8.8.8 name and dig @1.1.1.1 name and dig name from the affected machine are three different questions, and during an incident you should ask all three. DNS Debugging: Who Answered, and With What? gives the procedure.

Two circularities make DNS work at all. First: to ask the root you must know its address before you have DNS — every resolver ships with a root hints file of the thirteen names and their addresses, and refreshes it by asking one of them (the *priming* query). Second: if engineer-atlas.dev’s name servers are ns1.engineer-atlas.dev, resolving the name server’s name requires the zone you are trying to reach. The parent breaks the loop by storing the name servers’ addresses alongside the delegation — the glue records you saw in the +trace additional sections.

Stale glue is a real failure: you renumber your name servers, update your own zone, and forget that the registry still holds the old addresses. Resolvers that follow the delegation reach the old servers, which either no longer answer or answer with old data. The fix is at the registrar, not in your zone file. It is the DNS equivalent of updating the record but not the pointer to it.