DNS TTL
Calculate DNS record cache expiration and propagation timing from TTL values.
Inputs
Used to estimate cache hit ratio and resolver load reduction
Worst-Case Propagation Time
1 hours
Estimated Cache Hit Ratio
99.98%
Authoritative Server Load Reduction
99.98%
Queries Reaching Authoritative Server
24/day
Stale-Record Risk
Low — TTL is short relative to how often records change.
Step by step
Values used
Current TTL = 3,600 seconds; Expected Record Changes per Month = 1; DNS Queries per Day = 100,000
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)
Worst-Case Propagation Time
= 1 hours
Estimated Cache Hit Ratio
= 99.98
Authoritative Server Load Reduction
= 99.98
Queries Reaching Authoritative Server
= 24 /day
Stale-Record Risk
= Low — TTL is short relative to how often records change.
How it works
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.
Formulas
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)
- q
- Average number of queries received within one TTL-length window
Frequently Asked Questions
Why lower the TTL before making a DNS change?
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.
Does a low TTL guarantee instant propagation everywhere?
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.
What's a reasonable default TTL for a stable record?
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.
Why does a very short TTL increase load on authoritative servers?
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.