How Does DNS Caching Work?
Learn how DNS caching works across browser, OS, and resolver layers, and how TTL controls how long answers are cached.
Expected Interview Answer
DNS caching stores the result of a domain name lookup at multiple layers — the browser, the operating system resolver, and recursive resolvers along the way — so that repeated queries for the same name are answered instantly from memory instead of triggering a fresh resolution chain, with each cached record honoring the TTL set by the authoritative server.
When a resolver first looks up a name, it walks the DNS hierarchy from root to TLD to authoritative server, and the authoritative server’s response includes a TTL (time to live) value in seconds telling every cache along the path how long the answer may be reused. A browser cache, the OS-level stub resolver, and any recursive resolver (like a router or an ISP’s DNS server) each store the answer independently and serve it directly until the TTL expires, at which point the next query triggers a fresh lookup. This dramatically reduces lookup latency and load on authoritative servers, since only a small fraction of queries ever need to traverse the full hierarchy. Because caching happens at several layers with different lifetimes, changing a DNS record can take time to fully propagate — a long TTL speeds up repeat lookups but slows down how quickly a change is seen everywhere, which is why operators often lower the TTL shortly before planning a DNS change.
- Avoids repeating the full DNS resolution chain for every request
- Reduces latency for the end user on repeat lookups
- Reduces load on root, TLD, and authoritative name servers
- TTL gives operators a lever to balance freshness against lookup cost
AI Mentor Explanation
DNS caching is like a scorer who writes a batter’s career average on a sticky note after looking it up once, instead of re-checking the official records board every single time it is mentioned during commentary. The note stays valid for a set period — say until the next match day — after which the scorer must fetch the fresh figure again in case it changed. Multiple commentators in the box might each keep their own sticky note, at different freshness, rather than all sharing one lookup. This is exactly how a TTL governs how long a DNS answer is trusted before a fresh query is required.
Step-by-Step Explanation
Step 1
First lookup
A resolver walks the DNS hierarchy (root, TLD, authoritative) to get the answer and its TTL.
Step 2
Store at multiple layers
Browser, OS stub resolver, and recursive resolvers each cache the answer independently.
Step 3
Serve from cache
Subsequent lookups for the same name are answered instantly from cache while the TTL has not expired.
Step 4
Expiry and refresh
Once the TTL elapses, the next query triggers a fresh lookup back through the hierarchy.
What Interviewer Expects
- Explains that caching happens at multiple independent layers
- Understands TTL is set by the authoritative server and controls cache lifetime
- Knows the trade-off between long TTLs (faster repeat lookups) and short TTLs (faster propagation)
- Can explain why DNS changes are not instantaneous everywhere
Common Mistakes
- Assuming DNS changes take effect everywhere immediately
- Thinking there is only one cache layer instead of several (browser, OS, resolver)
- Forgetting that lowering the TTL before a planned change speeds up propagation
- Confusing DNS caching with browser HTTP caching
Best Answer (HR Friendly)
“DNS caching means that once your computer or browser looks up a website’s address, it remembers that answer for a while instead of asking again every time. Each remembered answer comes with an expiration time set by the website’s DNS provider, so the lookup stays fast most of the time, but changes to the address can take a little while to be seen everywhere as old cached answers expire.”
Code Example
# Query a record and see its TTL (seconds remaining before cache expiry)
dig example.com A
# example.com. 287 IN A 93.184.216.34
# ^^^ TTL in seconds
# Flush the local OS DNS cache (Linux, systemd-resolved)
sudo resolvectl flush-caches
# Repeat the query immediately to see the TTL count down from a fresh value
dig example.com A +noall +answerFollow-up Questions
- Why would an operator lower a record's TTL before making a DNS change?
- What is the difference between negative caching and positive caching in DNS?
- How does a recursive resolver differ from a stub resolver in caching behavior?
- What risks come with setting an extremely long TTL on a record?
MCQ Practice
1. What does a DNS TTL value control?
TTL (time to live) specifies how long, in seconds, a resolver may cache and reuse a DNS answer.
2. Where can DNS answers be cached?
DNS caching happens independently at several layers: browser, OS stub resolver, and recursive resolvers.
3. Why might an operator lower a TTL before a planned DNS change?
A shorter TTL means caches expire and refresh sooner, so the new value is seen faster everywhere.
Flash Cards
What is DNS caching? — Storing DNS lookup results at multiple layers so repeat queries are answered instantly.
What sets the TTL? — The authoritative server includes a TTL in its response, telling caches how long to keep the answer.
Where does DNS caching happen? — Browser, OS stub resolver, and recursive resolvers, each independently.
Trade-off of a long TTL? — Faster repeat lookups but slower propagation of DNS changes.