KNOWLEDGE ARTICLE

What Is DNS TTL?

Time to Live, DNS cache lifetime

Specifies how long a DNS record can be cached.

At a glance

TTL is measured in seconds. Shorter values permit quicker rechecking but increase lookup traffic; longer values reduce queries but prolong cached old answers.

TTL controls how long an answer can be reused

DNS Time to Live tells recursive resolvers and clients how many seconds they may cache a record. A cache hit avoids another authoritative query, reducing waiting and query load. After expiry, the resolver needs a current answer.

TTL is not a fixed time for copying records across the entire Internet. Users see old or new answers because earlier cached records expire at different times. Browser, operating-system and application caches can add further variation.

Positive answers, negative answers and alias chains

  • Successful A, AAAA and MX answers use their own TTLs. Different record sets in one response can have different lifetimes.
  • NXDOMAIN and no-data answers can also be cached. Negative-cache duration is normally related to SOA parameters.
  • CNAME aliases and final addresses are cached separately. Expiry at one layer may trigger only a partial re-query.
  • Resolvers may impose minimum or maximum cache policies. Authoritative TTL matters, but actual behavior also depends on implementation and network policy.
A records, negative answers and CNAME layers expiring and refreshing at different times
When different DNS caches expireSeparate positive, negative and per-alias cache lifetimes

Balancing failover and routine performance

Short TTLs can make planned migrations and DNS failover visible sooner, but increase authoritative queries and do not terminate existing connections. Longer TTLs suit stable records and improve cache reuse, while prolonging the effects of old addresses or mistakes.

Use different policies for different change rates. Stable mail and verification records need not have extremely short TTLs. Lower a migration target's TTL one or more old-TTL periods beforehand, then raise it after stabilization. Lowering it only at switchover cannot clear already cached high-TTL answers.

Practical use and interpretation

TTL can be displayed directly, but neither high nor low is universally better. Low values may support dynamic routing or planned changes; high ones may suit stable configuration. Suitability depends on service goals, change procedures and DNS capacity.

For CDNs and alias chains, consider each layer's TTL rather than inferring propagation from the final address alone. If TTL is unavailable or a special cache obscures it, the state remains unknown.

Points to consider

TTL is a caching policy, not a standalone speed or security score. Evaluate change frequency, failover needs and resolver behavior.

Frequently asked questions

Does TTL zero make a change immediate?

Not necessarily. Existing answers may still be cached under their previous TTL, and some resolvers impose a minimum.

Does lower TTL make a website faster?

Usually not. More frequent expiry can increase lookups. Speed also depends on resolvers, networks, servers and page resources.

How early should I lower TTL before a change?

Allow at least the current old TTL plus operational margin. The exact interval depends on the current value and migration risk.

References