How long does DNS propagation take after a change?

For recursive resolver caches, the practical stale-answer window is usually bounded by the TTL that was cached before the change, plus any resolver or application cache policy. Authoritative server updates may be fast, but cached answers expire on their own schedule.

When should I lower DNS TTL before a cutover?

Lower the TTL at least one old effective TTL before the planned cutover, plus any operational safety buffer. That allows caches holding the old high TTL to expire before the record value changes.

Why can stale DNS answers remain after I lowered TTL early?

A resolver can refresh the old answer shortly before the cutover using the lowered TTL. After the cutover, that resolver may keep the old value until the lowered TTL expires.

What is negative DNS caching?

Negative caching is caching of NXDOMAIN or no-data answers. RFC 2308 uses the SOA-derived negative TTL to indicate how long a resolver may cache a negative answer.

Is this DNS TTL calculator private?

Yes. Inputs are processed locally in your browser and are not submitted to a backend.

DNS TTL Propagation Calculator

Plan DNS cache expiry before a record cutover. Estimate when to lower TTL, how long old answers can remain after the change, how negative caching affects newly created records, and how long rollback answers may stay cached.

All calculations run locally in your browser. Use this as a planning model, then verify behavior with your DNS provider, authoritative servers, recursive resolvers, and application caches.

Inputs

Old record TTL The TTL that may already be cached before you lower it.

Old TTL unit

Lowered / cutover TTL The TTL used shortly before the cutover and usually kept for rollback.

Lowered TTL unit

Cutover timing

TTL lowered before cutover How long the old TTL has been lowered before changing the record value.

Lead time unit

Planned cutover time Optional. Leave blank to show relative timing only.

Safety buffer

Buffer unit

Record state before cutover

Resolver policy assumptions

Resolver minimum TTL clamp Use 0 when you do not want to model a local minimum.

Minimum TTL unit

Resolver maximum TTL cap Use 0 for no modeled cap.

Maximum TTL unit

Negative cache TTL SOA-derived NXDOMAIN or no-data cache lifetime for newly added names.

Negative TTL unit

Cutover presets

Results

Cutover status-

Stale after cutover-

Lower TTL by-

All-clear time-

Effective TTLs

Old TTL after resolver policy:-

Lowered TTL after resolver policy:-

Negative TTL after resolver policy:-

TTL lowering lead entered:-

Safety buffer:-

Cache expiry model

Old high-TTL cache remaining at cutover:-

Low-TTL refresh risk after cutover:-

Negative cache risk after cutover:-

Recommended lower-TTL lead:-

Additional lead needed:-

Rollback exposure:-

Timeline

Lower TTL-

Cut over record-

Expected all-clear-

Advertisement

How to use this DNS TTL propagation calculator

Enter the old TTL: use the TTL that resolvers may already have cached before you lower the record.
Enter the lowered TTL: this is the TTL you plan to use before and during the cutover.
Add the lead time: enter how long the lower TTL has been in place before the record value changes.
Model resolver policy: add a minimum TTL clamp, maximum TTL cap, or negative cache TTL when you know they apply.
Review the timeline: compare the recommended lower-TTL lead and post-cutover stale window with your maintenance plan.

Formula and assumptions

Effective TTL: min(max(configured TTL, resolver minimum), resolver maximum) when a maximum cap is provided. With no maximum cap, only the minimum clamp is applied.

Old cache remaining at cutover: max(0, effective old TTL - TTL lowering lead)

Positive stale window after cutover: max(old cache remaining, effective lowered TTL). The lowered TTL still matters because a resolver can refresh the old value shortly before cutover.

Recommended lower-TTL lead: effective old TTL + safety buffer

Negative cache risk: for newly created records that may have been queried before creation, the model adds the effective negative TTL as a possible post-cutover stale window.

DNS TTL is defined as seconds that a resource record may be cached. RFC 2181 clarifies the valid TTL range as 0 through 2^31 - 1 seconds. RFC 2308 defines the SOA-derived TTL used for negative answers.

Common DNS cutover scenarios

Scenario	What to watch	Planning note
A or AAAA record move	Old IP address remains cached until its TTL expires	Keep the old service online through the stale-answer window when possible.
MX cutover	Mail senders may keep old MX answers until cache expiry	Run old and new mail paths in parallel during the transition window.
New subdomain	Earlier NXDOMAIN or no-data responses can be cached	Pre-create records before launch to avoid negative cache delays.
Provider migration	NS, DS, glue, and zone transfer timing may be separate from record TTL	Do not treat a single record TTL as proof that the whole delegation has moved.

Why DNS changes can appear slow

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.

Methodology

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.

Last reviewed: June 2026. References: RFC 1035 for resource record TTL behavior, RFC 2181 for TTL range clarification, and RFC 2308 for negative caching.

FAQs

Is DNS propagation the same as authoritative update time?

No. Authoritative DNS changes can publish quickly, while recursive resolvers and application caches may keep old answers until their cached TTL expires.

Can I force every resolver to drop the old DNS answer?

Generally no. Some providers offer cache flush tools for their own resolvers, but you should plan public cutovers as TTL-driven cache expiry.

Should I use TTL 0 for a production cutover?

TTL 0 tells resolvers not to reuse the answer beyond the current transaction, but not every intermediate cache or application behaves identically. Very low TTLs also increase query load, so use them deliberately.

Why does the tool include negative caching?

If users or monitors query a name before it exists, a recursive resolver may cache the negative answer. Creating the record later does not always make that cached NXDOMAIN disappear immediately.

Is this calculator private?

Yes. Inputs are processed locally and are not submitted to a backend.

Disclaimer

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.