The question tests whether you treat DNS as a real distributed cache with correctness tradeoffs — not just "it looks up the IP." The interesting mechanics are TTL decrement, negative caching, and the cold-miss path.
The mental model: every answer carries an expiry, and every cache honors it independently.
A DNS response isn't just "the IP." It carries the record plus a TTL — the number of seconds any cache may reuse it. Every cache in the path (browser, OS stub resolver, recursive resolver) starts its own countdown from the moment it stores the record. A TTL of 300 from the authoritative server means each hop re-serves the answer for up to 5 minutes, then treats it as expired and re-queries upstream.
When the record expires, the cache doesn't just forget the address — it goes back to the recursive resolver with a fresh query. The interesting failure mode is the reverse: the recursive resolver asks the authoritative server, gets the record, caches it with its own countdown. The machine's actual behavior on a cache miss: stub resolver sends a UDP query (one datagram, one reply, ~1 RTT), the recursive resolver walks from root to TLD to authoritative server if it doesn't have the NS glue cached — typically 2-4 round trips on a truly cold cache. That's why the first lookup after a flush feels slow.
Negative caching is the subtle part. A failed lookup (NXDOMAIN, or a name that exists but has no A record) is itself cached, with a TTL the authoritative server sets — often 300-3600 seconds. This protects the resolver from being hammered by a client polling a dead hostname, but it's also why a newly created record can take minutes to appear: the resolver is serving the cached NXDOMAIN until the negative TTL expires.
Tradeoffs and edge cases: TTL is a latency-vs-consistency dial. Long TTLs (hours, like default A records) make lookups cheap but delay failover when you move an IP. Short TTLs (60s or lower, common for load-balancer frontends) propagate changes in minutes at the cost of more queries upstream. Every cache layer respects the record TTL, not the parent's — and a client may still pin an IP in its connection pool past TTL expiry, which is why DNS-only failover never cuts over instantly.