TL;DR: Your stub resolver sends one query with the recursion-desired bit to a recursive resolver. That resolver walks referrals from root to TLD to the zone's authoritative servers and caches every answer, including NXDOMAIN, by its TTL. Recursion is work the resolver does for you; authority is a property of the servers that own the zone.
How to approach it
Split the cast into three roles first: stub resolver on your host, recursive resolver in the middle, authoritative servers at the edge, then layer caching on top. Blur those roles and no follow-up about TTLs or failures survives.
A strong answer
Before DNS even runs, /etc/nsswitch.conf decides lookup order; hosts: files dns means /etc/hosts wins. The glibc stub then reads /etc/resolv.conf, picks a nameserver, and sends one query over UDP 53 with the RD (recursion desired) bit set. That nameserver is a corporate resolver, a cloud VPC resolver such as AWS's link-local endpoint, or a public one. The stub does not talk to root servers. Ever.
The recursive resolver checks its cache. On a miss it performs iterative queries on the client's behalf: root hints point it at the 13 anycast root letter groups, which return not an answer but a referral to the .com TLD servers; the TLD returns a referral to the zone's authoritative nameservers; the authoritative server finally answers with the record and its TTL. A cold lookup costs those three or four sequential round trips, commonly 50 to 300 milliseconds depending on where the recursor sits; a warm hit answers in single-digit milliseconds, which is why resolver placement matters more than resolver brand.
Caching depends on the component: glibc alone does not provide a persistent DNS cache, while an application, systemd-resolved or the recursor may cache. RFC 2308 derives the negative-cache TTL from the lesser of the SOA record TTL and SOA.MINIMUM, so a typo'd hostname keeps failing fast after you fix the typo's source.
| Role | Runs where | Behaviour | Caches |
|---|---|---|---|
| Stub resolver | libc in your process | forwards one query with RD set | only via OS cache |
| Recursive resolver | enterprise, VPC, public | performs iterative referrals for clients | yes, the main cache |
| Authoritative server | zone owner's infra | answers its zones, refers elsewhere | no |
Wire details worth having ready: oversized responses set the TC flag and the stub retries over TCP 53; EDNS0 lifts the classic 512-byte ceiling, according to the advertised payload size; many deployments use around 1232 bytes to avoid fragmentation. In Kubernetes, names below the ndots threshold can try search domains first. A trailing-dot fully qualified name bypasses expansion, and caching/resolver behavior determines the actual multiplier.
dig +trace example.com replays the referral chain, and ordinary dig output already proves the cache story: Query time near zero plus a decremented TTL means you hit a cache.
My position: run a local recursor such as unbound close to your workloads, because you inherit warm cache without sending every internal name to a public resolver. Reverse that when nobody will operate it; a stale unbound is worse than the provider's managed resolver.
What interviewers probe next
"Recursive versus iterative query, precisely?" The RD bit asks for recursion; iterative queries are what the recursor sends outward, accepting referrals instead of demanding final answers.
"A lookup intermittently takes exactly five seconds." That number is glibc's default timeout in resolv.conf: one possible cause is an unresponsive nameserver followed by a retry. Check packet traces, resolver options and upstream behavior before concluding which component is dead.
"How do you watch a TTL expire?" Run dig repeatedly against the same resolver and read the shrinking TTL in the answer section.
Common mistakes
Saying the browser contacts the root servers. It never leaves the configured resolver.
Claiming authoritative servers cache client queries as part of resolution. They answer; they do not build your cache.
Ignoring negative caching, then being surprised that removing a bad record did not stop NXDOMAIN storms immediately.
References