TTL is "how long, in seconds, you may cache this answer"
In Chapter 3 we saw that a recursive resolver walks root → TLD → authoritative, and that on a cache hit that whole journey is skipped. In this chapter we put a number — TTL, in seconds — on how long that cache lasts.
TTL is the lifetime attached to a DNS record. A recursive resolver can reuse the same RRset until that TTL expires. A longer TTL makes things faster and reduces load on authoritative servers. On the other hand, if the authoritative side changes the value, stale answers can still appear while the TTL has not yet run out.
expires_at = the expiration time, fetched_at = when the record was fetched, TTL = the record's lifetime in seconds. Add the TTL to the fetch time.remaining = remaining TTL, now = the current time. Once it drops below 0, the record can no longer be reused.0 / 7 correct. Correctness is stored only in this browser's localStorage.
Practice 5-1 — Count the seconds by hand first
Treat TTL as an actual number of seconds, not as an intuitive "long" or "short."
Q23. A recursive resolver fetched a record with TTL 300 seconds at 12:00:00. What is the remaining TTL at 12:03:20, in seconds?
Show hint
Subtract elapsed time from the fetch time. 3 minutes 20 seconds is 200 seconds.
Q24. A recursive resolver fetched an old record with TTL 300 seconds at 12:00:00, and the authoritative side switched to a new record at 12:02:00. On that resolver, for at most how many more seconds from that moment could the old record still be returned?
Show hint
The expiration time is 12:05:00. Compute the gap from the update time to that point.
Feel it with a slider
The following simulator sets up a scenario in which authoritative data is updated several times over the course of an hour. While varying the TTL, the update interval, and the query interval arriving at the same recursive resolver, compare the hit rate and the intervals during which a stale answer is returned.
Practice 5-2 — Miss counts and the freshness trade-off
Check in numbers what goes up and what goes down when you shorten TTL.
Q25. A single recursive resolver receives the same name/type query every 10 seconds over the interval 0 ≤ t < 300 seconds. TTL is 60 seconds, and the cache is initially empty. How many misses go out to the authoritative side?
Show hint
Misses happen at t = 0, 60, 120, 180, 240.
Q26. Which of the following changes is most likely when TTL is shortened?
Show hint
In exchange for not being able to hold cache for long, stale values are less likely to stick around.
Negative caching exists too
DNS also caches the result "does not exist." In other words, NXDOMAIN for a typo'd name, or a negative response saying "there is no record of that type," is also reused for a while. Without knowing this, you get confused by behavior like being told the record you just created still doesn't exist.
The retention time for a negative response is bounded by the minimum field of the SOA record (RFC 2308). The SOA record has the following fields:
| Field | Meaning |
|---|---|
| MNAME | The hostname of the master (primary) authoritative server |
| RNAME | The zone administrator's email address (with @ rewritten as .) |
| serial | The zone's serial number. When it increases, secondaries re-fetch the zone |
| refresh | How often (in seconds) a secondary checks SOA against the master |
| retry | How often (in seconds) to retry refresh after it fails |
| expire | How long (in seconds) a secondary keeps serving the zone when it cannot reach the master |
| minimum | The upper bound on the negative caching TTL (in seconds). NXDOMAIN and NODATA are cached for at most this long. |
So "how long does a typo'd NXDOMAIN linger?" is bounded by the parent zone's SOA minimum (and the response TTL).
Also, the word "cache" is too broad, so you need to separate which layer of cache you are talking about. DNS TTL is the lifetime of a name-resolution result; it is different from HTTP caches and CDN edge caches. Chapter 6 covers this in more detail.
A common practice is to lower TTL in advance before a cutover and restore it after the migration. Lowering TTL right before the change has no effect on already-distributed cache entries that still carry the old, longer TTL.
Practice 5-3 — Confirm negative responses and layer differences
Sort out how long NXDOMAIN lingers, and how it differs from non-DNS caches.
Q27. Which description of negative caching is most correct?
Show hint
"Does not exist" is itself a piece of information.
Q28. A resolver cached an NXDOMAIN response at 13:00:00 with a lifetime of 120 seconds. Suppose a record for that name is newly created at 13:01:00. From that moment, how many more seconds must you wait before the resolver can query upstream again?
Show hint
The negative cache expires at 13:02:00.
Q29. Which is correct about the relationship between DNS TTL and browser HTTP caches or CDN TTLs?
Show hint
Keep "which layer of cache" separate in your head.
Key takeaways from this chapter
- TTL is the lifetime meaning "how many seconds you may cache this answer"
- Longer TTL raises hit rate; shorter TTL raises freshness
- Even negative responses such as NXDOMAIN are cached