Calculate DNS record cache expiration and propagation timing from TTL values.
DNS TTL (Time To Live) controls how long resolvers may cache a record before re-querying the authoritative nameserver. This creates a direct trade-off: a longer TTL reduces load on authoritative servers and speeds up resolution for end users (higher cache hit ratio), but worst-case propagation time for any DNS change equals the TTL — a resolver that cached the old value right before a change won't see the update until that cache entry expires. A shorter TTL propagates changes faster at the cost of more frequent authoritative queries and, at very short TTLs, negligible caching benefit at all.
Worst-case propagation time
propagation_time = TTL (a resolver's cached copy is valid for up to this long)
Approximate cache hit ratio
hit_ratio ≈ 1 − 1/(queries per TTL window)
Lowering TTL well in advance of a planned change (e.g. a day before, if changing from a 24-hour TTL) lets old, longer-cached entries expire first, so once you actually make the change, the shorter TTL ensures resolvers pick up the new value quickly.
No — TTL is advisory, and some resolvers, ISPs, or misconfigured caching layers don't strictly honor it, occasionally serving stale records longer than the TTL specifies. TTL sets the intended maximum cache lifetime, not an absolute guarantee across every resolver on the internet.
3600 seconds (1 hour) to 86400 seconds (24 hours) is common for records that rarely change, balancing reasonable propagation speed against caching efficiency. Records expected to change frequently (like during migrations) are often set much lower, e.g. 300 seconds (5 minutes) or less.
Every time a cached entry expires, the next query for that name must go all the way to the authoritative nameserver instead of being served from a resolver's cache. Shorter TTLs mean entries expire more often, so a larger fraction of total queries bypass caching entirely.