Calculate when an old DNS answer should expire and estimate the time remaining after a change. You can also check live public-resolver answers or plan when to lower TTL before a migration.
Effective TTL: min(max(configured TTL, resolver minimum), resolver maximum) when a maximum cap is provided; otherwise only the minimum clamp applies.
Already changed: remaining = max(0, old effective TTL - elapsed since update) and deadline = update timestamp + old effective TTL. A lower TTL published after the update cannot rewrite the lifetime on copies already cached.
Future cutover: old cache remaining = max(0, old effective TTL - lowering lead); positive stale window = max(old cache remaining, lowered effective TTL); recommended lead = old effective TTL + safety buffer.
New names: the negative-cache window uses the effective negative TTL. Under RFC 2308 section 5, the negative TTL placed in a response is the lesser of the SOA record TTL and SOA.MINIMUM.
Inputs: old TTL 3,600 s; lowered TTL 300 s; lead 2 h (7,200 s); buffer 30 min (1,800 s).
old remaining = max(0, 3,600 - 7,200) = 0 s
stale window = max(0, 300) = 300 s
recommended lead = 3,600 + 1,800 = 5,400 s
Result: high-TTL copies are drained; a resolver may still refresh the old value for 5 minutes. Lower TTL at least 90 minutes before cutover.
Action: keep the old endpoint available for at least 5 minutes after the change, then verify clients.
Inputs: old TTL 14,400 s; lowered TTL 600 s; lead 5 h (18,000 s); buffer 1 h (3,600 s).
old remaining = max(0, 14,400 - 18,000) = 0 s
stale window = max(0, 600) = 600 s
recommended lead = 14,400 + 3,600 = 18,000 s
Result: the five-hour lead meets the model and old MX answers may remain for 10 minutes after cutover.
Action: accept mail on both paths through the cache window and retain normal mail-queue retry handling.
Inputs: new name; SOA TTL 3,600 s; SOA.MINIMUM 900 s; pre-launch lead 0; buffer 900 s.
negative TTL = min(3,600, 900) = 900 s
negative remaining = max(0, 900 - 0) = 900 s
recommended pre-create lead = 900 + 900 = 1,800 s
Result: a resolver that cached NXDOMAIN can hide the new record for 15 minutes.
Action: pre-create the name at least 30 minutes before launch or allow for the negative-cache window.
Inputs: old TTL 86,400 s; new TTL 300 s; change made 1 h ago; buffer 1 h.
remaining = max(0, 86,400 - 3,600) = 82,800 s = 23 h
deadline = update time + 24 h
Result: lowering to 300 seconds now does not shorten a copy cached with the old 24-hour TTL.
Action: keep the old endpoint working until the 24-hour cache-expiry deadline, then verify before retiring it.
| TTL seconds | Duration | Typical use | Trade-off |
|---|---|---|---|
| 60 | 1 minute | Short failover test or active incident | Fast changes; highest authoritative query load |
| 300 | 5 minutes | Cutovers, proxied or dynamic services | Fast rollback; increased query volume |
| 900 | 15 minutes | Frequently changed service records | Responsive without extreme query load |
| 1,800 | 30 minutes | General web records with occasional changes | Balanced change speed and caching |
| 3,600 | 1 hour | Common A, AAAA, CNAME, MX, or TXT baseline | Moderate cache efficiency and change delay |
| 14,400 | 4 hours | Stable mail and infrastructure records | Lower query load; slower emergency changes |
| 86,400 | 24 hours | Very stable records or delegations | Efficient caching; long migration and rollback window |
Provider controls can override your choice. For example, Cloudflare documents a fixed 300-second automatic TTL for proxied records; other managed or proxied products may use fixed or automatic TTLs.
DNS propagation is often cache expiry rather than copying data around the internet. When you change an authoritative record, recursive resolvers that already cached the old answer can continue serving it until the cached TTL reaches zero. Browsers, operating systems, forwarders, and applications may also have their own cache behavior outside the authoritative DNS zone.
Lowering TTL early helps only after the previous high-TTL cache has aged out. Once all active caches have seen the lower TTL, the remaining post-cutover stale-answer window is usually close to the lowered TTL, plus any local resolver or application caching policy.
Even after a modeled deadline, RFC 8767 serve-stale behavior, forwarding caches, browser or application caches, CNAME-chain TTLs, and authoritative failures can extend the old answer a user observes.
The calculator models the worst practical resolver cache window for a record-value cutover. It assumes a resolver could have cached the old answer immediately before TTL lowering, then may refresh the old answer again immediately before cutover using the lower TTL. It also models negative caching for newly created names and lets you add resolver minimum or maximum TTL policy when that is part of your environment.
Primary references: RFC 1035 §3.2.1 defines the TTL field; RFC 2181 §8 clarifies its 31-bit range; RFC 2308 §5 defines negative-cache TTL selection; and RFC 8767 describes serving stale data.
Live lookup implementation: requests follow the documented Google Public DNS JSON API, Cloudflare JSON DoH API, and Quad9 RFC 8484 endpoint. Returned TTLs are resolver observations at query time, not necessarily the zone's original published TTL.
Published test cases: old TTL 3,600 with 7,200 seconds of lead returns 0 seconds of high-TTL remainder; a change made 3,600 seconds ago with an old TTL of 86,400 returns 82,800 seconds remaining; SOA TTL 3,600 and SOA.MINIMUM 900 produce a 900-second negative TTL; resolver minimum 600 applied to a configured TTL of 300 produces an effective TTL of 600.
Limitations: the model cannot know when every resolver first cached a record, private forwarding policy, application cache lifetimes, DNS provider publication delay, DNSSEC/delegation errors, or whether a client uses serve-stale. It intentionally reports a modeled cache-expiry deadline, not a worldwide completion guarantee.
Copies cached before the change follow the old TTL they received. The new TTL applies only to answers fetched after it is published, so the old TTL controls the worst-case lifetime of pre-change copies.
It does not shorten old answers already cached with the previous TTL. It helps only when a resolver refreshes after the lower TTL is authoritative.
They are 5 minutes, 1 hour, and 24 hours. Each is an upper bound counted from when a compliant resolver cached its copy, not necessarily from when you clicked Save.
Serve-stale resolver behavior, forwarding caches, browser or application caches, CNAME chains, authoritative failures, and clock or observation differences can extend the old answer users observe.
Restore it after the new endpoint is stable, rollback is no longer likely, and monitoring shows the migration is healthy. Allow the short TTL to support the operational rollback window first.
Run dig example.com A; the answer section's numeric field before IN is the remaining TTL in seconds. With nslookup, try nslookup -type=A example.com; TTL display varies by operating system, so PowerShell's Resolve-DnsName or dig may be clearer.
A nameserver migration involves the parent-zone delegation, child-zone NS records, glue, and sometimes DS records. Those records have separate caches and registry or registrar publication steps.
RFC 2308 defines it as the lesser of the SOA record TTL and the SOA.MINIMUM field included with the negative response. That value controls caching of NXDOMAIN and no-data answers.
Not inherently. A normal record change is usually governed by the TTL already cached. The familiar 24–48 hour warning is a conservative convention that may cover long TTLs, delegation changes, provider processes, and caches outside authoritative DNS.
This is an infrastructure planning aid. Validate DNS changes with your DNS provider, authoritative server configuration, DNSSEC state, delegation records, monitoring, and change-management requirements before a production cutover.
Starlight Tools