Cybersecurity glossary
What is TTL (Time to Live) in DNS?
Learn what TTL means in DNS, how resolvers cache answers until the timer expires, why TTL affects cutovers and outages, and which myths about DNS propagation lead teams astray.
Definition
TTL, or Time to Live, is the number of seconds a DNS answer may be cached before a resolver or client should refresh it from an authoritative source.
TTL is a control knob, not a footnote
Teams often talk about DNS propagation as if it were a vague force of nature. In reality, TTL is the main timer that governs how long caches are allowed to keep using an answer before they need to refresh it.
That makes TTL a planning tool. It affects failovers, maintenance windows, recovery speed, query volume, and even how long a mistake keeps hurting after you fix it authoritatively. Choosing a value is a tradeoff between freshness and stability, not a cosmetic setting.
What TTL controls in practice
TTL sounds simple, but its practical impact shows up in several different layers of DNS behavior and operator expectations.
Answer freshness window
Resolvers may keep serving the cached answer until the TTL counts down to zero.
Query load
Lower TTLs force more refreshes and therefore more traffic toward authoritative infrastructure.
Cutover speed
Shorter TTLs can help migrations land faster because old answers are forgotten sooner.
Negative caching behavior
TTL-related rules also affect how long caches remember that a name did not exist.
How TTL affects a DNS answer over time
The authoritative server publishes a record
The answer includes a TTL value measured in seconds.
A resolver caches the result
After the first query, the resolver stores the answer and starts counting the TTL down.
Clients reuse the cached answer
Until expiry, later queries can be answered from cache with no upstream lookup.
The timer reaches zero
Once the cached entry expires, the resolver should refresh from authoritative sources before reusing it.
New data becomes visible after refresh
If the authoritative answer changed, refreshed clients begin seeing the new value.
Operators repeat the cycle intentionally
During planned changes, teams often lower TTL in advance, perform the cutover, then raise TTL again after stability is confirmed.
TTL choices by common scenario
There is no single perfect TTL. Good values depend on how costly stale data would be versus how expensive extra DNS traffic or volatility would become.
| Scenario | TTL goal | Practical guidance |
|---|---|---|
| Stable brochure site | Reduce query volume while preserving adequate correctness. | Longer TTLs are often fine when endpoint changes are rare and failover is not urgent. |
| Planned migration | Make old answers age out before or soon after the cutover. | Lower the TTL well before the migration so existing caches are already carrying the shorter lifetime. |
| Frequently shifting cloud endpoint | Avoid users sticking to obsolete infrastructure for too long. | Use moderate TTLs and pair them with stable front-door services where possible. |
| Critical failover record | Limit how long degraded routing persists in downstream caches. | Short TTLs help, but test client and resolver behavior instead of assuming instant failover. |
TTL planning habits worth adopting
TTL works best when it is chosen as part of an operational plan instead of copied from a default template and forgotten.
- Decide TTL based on the record’s change frequency and outage sensitivity rather than using one value everywhere.
- Lower TTLs far enough in advance of a migration for existing caches to actually observe the shorter value.
- Remember that resolvers are not the only caches; applications, browsers, and load balancers may add their own behavior.
- Track negative-caching implications when launching a new name that may previously have returned NXDOMAIN.
- Raise TTLs again after a risky change if long-term stability and lower query load matter more than agility.
- Test failover using real recursive resolvers and realistic client paths instead of a single authoritative query.
- Avoid very low TTLs as a substitute for sound architecture if stable front-door services can absorb endpoint churn.
- Document expected TTL behavior in change plans so support teams know what “fully propagated” really means.
Common TTL misconceptions
One recurring mistake is treating TTL as a guarantee instead of a limit on cache reuse. A short TTL encourages freshness, but users may still observe delays because of application caches, stale local resolvers, or simply because they never performed a new lookup yet.
Another mistake is leaving TTLs high everywhere and then expecting emergency DNS changes to save the day. TTL choices should be made before incidents, not while racing against caches that are behaving exactly as configured.
The practical takeaway
TTL is the timer that tells DNS caches how long they may keep an answer. It directly affects how fast changes become visible, how much query traffic you generate, and how long stale answers can persist.
Use TTL deliberately: lower it before changes that need agility, keep it higher where stability matters, and treat propagation as a measurable caching behavior rather than a mystery.
Related security terms
DNS Resolver
Resolvers honor TTL values when deciding how long they can reuse cached answers.
A Record
Address-record migrations and failovers are heavily influenced by TTL choices.
CNAME Record
Alias changes also depend on how quickly caches are allowed to forget old answers.
SOA Record
SOA values influence negative caching behavior and interact with TTL planning.
NXDOMAIN
Negative responses can be cached too, which surprises teams during new-record rollouts.
Frequently asked questions
What does TTL mean in DNS?
TTL means Time to Live. It tells caches how long they may reuse a DNS answer before asking again.
Does a low TTL guarantee instant propagation?
No. It improves the chance that caches refresh sooner, but clients, intermediate resolvers, and application behavior can still delay what users observe.
Why would someone use a high TTL?
Higher TTLs reduce query load and can improve resilience to short-lived authoritative outages because caches keep usable answers longer.
Should every record use the same TTL?
Usually not. Stable records can often use longer TTLs, while frequently changed or failover-sensitive records may need shorter values.
Can NXDOMAIN be cached?
Yes. Negative responses can be cached, which is why a newly created record may still look absent for some time after launch.
Is TTL a security control?
Not directly, but it influences how long stale or maliciously changed answers persist in caches before they are refreshed.
References
Explore authoritative guidance and frameworks related to ttl (time to live).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.