Build fluency in the vocabulary of how long a resolver may reuse a cached DNS answer.
0 / 5 completed
1 / 5
At standup, a dev mentions a DNS record specifying how many seconds a resolver is allowed to keep reusing a cached answer before it must ask the authoritative server again. What is this value called?
Time to live, or TTL, is the value attached to a DNS record specifying how many seconds a resolver may keep reusing a cached answer before it's required to query the authoritative server again for a fresh one. A CDN cache invalidation is a related but distinct concept about purging cached content at the edge, not about how long a DNS answer itself stays cached. This TTL is what determines the tradeoff between fast, cache-served lookups and how quickly a DNS change actually propagates out to every resolver that's already cached the old answer.
2 / 5
During a design review, the team lowers a record's TTL to a much shorter value in the hours leading up to a planned server migration, specifically so resolvers won't hold onto the old IP address for long once the record actually changes. Which capability does this lowered TTL provide?
Lowering the TTL ahead of time provides faster propagation of the upcoming change, since resolvers are forced to expire and re-check the record much sooner, meaning once the actual migration happens, most resolvers will only be serving the stale answer for a short window instead of however long the original, longer TTL would have allowed. Resolvers do not re-check with the authoritative server on every lookup regardless of TTL, since honoring the cached TTL is exactly the point of DNS caching in the first place. This planned TTL reduction ahead of a migration is a standard, well-known technique for minimizing the window of stale DNS answers during a cutover.
3 / 5
In a code review, a dev notices a critical record's TTL is set to twenty-four hours, and the team is planning a same-day emergency failover to a different IP address. What does this represent?
This is a propagation risk, since any resolver that already cached the old answer under a twenty-four-hour TTL has no reason to re-check the authoritative server until that TTL expires, meaning it will keep serving the stale IP address for up to a full day even after the emergency failover has already happened. A CSRF token is an unrelated web security concept, not a DNS caching one. This is exactly why a long-lived TTL on a record that might need an emergency failover is a liability, and why proactively lowering TTLs on critical records ahead of any planned or anticipated change is considered good practice.
4 / 5
An incident report shows a large fraction of users kept hitting a decommissioned server for nearly a full day after a DNS failover, because the record's TTL had been left at twenty-four hours with no advance reduction before the change was made. What practice would prevent this?
Lowering the record's TTL well in advance of any planned change gives resolvers time to expire and re-cache with the new, shorter value before the actual failover happens, so once the change is made, resolvers only serve the stale answer for that shorter window instead of up to a full day. Leaving the TTL at its long-lived default with no advance reduction is exactly what caused users to keep hitting the decommissioned server for nearly a day in this incident. This advance TTL-lowering is a standard, well-established practice for any planned DNS cutover where minimizing the stale-answer window actually matters.
5 / 5
During a PR review, a teammate asks why the team temporarily lowers a record's TTL before a planned migration instead of just leaving it at its normal, longer-lived value throughout. What is the reasoning?
A resolver won't re-check the authoritative server until its already-cached copy's TTL expires, so leaving a long TTL in place straight through a migration means any resolver that cached the old answer just before the cutover keeps serving that stale answer for the entire remaining duration of that long TTL. Temporarily shortening the TTL ahead of time ensures resolvers naturally expire their cached copies and re-check far sooner, catching the new answer shortly after it's published. The tradeoff is a temporary increase in DNS query volume against the authoritative server while the shortened TTL is in effect, a small cost against meaningfully shrinking the stale-answer window during a change that actually matters.