DNS TTL
Calculate DNS record cache expiration and propagation timing from TTL values.
About DNS TTL
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
Worked example
With the default values below, DNS TTL returns Worst-Case Propagation Time of 1 hours. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Current TTLminimum 0 seconds
- 3,600 seconds
- Expected Record Changes per Monthminimum 0
- 1
- DNS Queries per Dayminimum 0
- 100,000
Results
- 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
- 1Values used
- 2Worst-case propagation time
- 3Approximate cache hit ratio
- 4Worst-Case Propagation Time= 1 hours
- 5Estimated Cache Hit Ratio= 99.98
- 6Authoritative Server Load Reduction= 99.98
- 7Queries Reaching Authoritative Server= 24 /day
- 8Stale-Record Risk= Low — TTL is short relative to how often records change.
Assumptions and limits
- The result is derived only from the 3 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
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.