{{ summaryHeading }} {{ summaryPrimary }} {{ summaryLine }} Readiness{{ readinessLabel }} Safe drain{{ formatDuration(values.safe_drain_seconds) }} Observe{{ formatDuration(values.observation_seconds) }}

Window rail unavailable

CheckpointTimingRunbook useCopy
{{ row.checkpoint }}{{ row.timing }}{{ row.use }}

Operator guardrails

{{ item.title }}

{{ item.status }}

{{ item.current }}

{{ item.action }}

DNS Cache Capacity Calculator Estimate DNS resolver cache memory from insert churn and TTL, then compare budget headroom with upstream QPS and hit-versus-miss latency.
DNS Propagation Checker Check DNS propagation across public resolvers, compare the intended record set, and identify cache holdouts with TTL and failure evidence.
EDNS Client Subnet (ECS) Tester Compare DNS answers with and without an EDNS Client Subnet hint, then inspect answer steering, echoed scope, TTL drift, and privacy clues.
DNS Delegation Trace Analyzer Trace a public hostname through DNS delegation and aliases, compare resolver views, and inspect DNSSEC or negative-cache clues.

A planned DNS change has two clocks. Authoritative nameservers must publish the new data, while recursive resolvers may continue serving an older answer until its remaining time to live (TTL) expires. Lowering TTL shortly before the cutover does not shorten copies that were cached earlier with the old value.

That is why a controlled change begins before the record is edited. The temporary lower TTL must remain published long enough for old cached answers to drain, then the changed answer needs its own observation period before a normal TTL is restored.

PhaseWhat is happeningWhat to verify
Pre-lowerThe old answer may still be cached under its earlier TTL.All authoritative servers publish the lower TTL.
CutoverThe authoritative record changes after the modeled drain interval.Expected record set, status, and authoritative agreement.
ObserveRecursive caches replace old answers on different schedules.Resolver samples and service health remain correct.
RestoreA longer production TTL is published after the temporary period.The new answer is stable before increasing cache lifetime.

Positive and negative answers have separate cache concerns. If a name or record type was queried while it did not exist, an NXDOMAIN or NODATA response can remain cached according to the zone's negative-cache TTL. Creating the record later does not make that earlier negative answer disappear immediately.

TTL is a maximum cache lifetime carried in DNS data, not a universal propagation deadline. Resolver caps, serve-stale behavior, split DNS, DNSSEC failures, provider rollout, delegation caches, CNAME chains, and client-side caches can extend or change what users observe. A timeline estimate must be paired with authoritative checks and resolver sampling.

Very short TTLs also increase refresh frequency. They can improve rollback cadence during a bounded change, but holding them for long periods may raise authoritative query load and reduce the protection that caching provides.

How to Use This Tool:

Build the plan from the longest cache that can still control the change, not just the TTL you intend to publish.

  1. Enter the Current TTL and the Temporary lowered TTL using the units shown by the DNS provider.
  2. Enter how long the lower TTL has already been published as Pre-lower lead, then choose a safety factor from 1.0× through 3.0×.
  3. Add the estimated cutover action time and the number of temporary-TTL verification cycles to observe after the answer changes.
  4. Enter a known longer cache or negative-cache TTL when evidence shows one can outlast the current record TTL. Zero leaves that optional source neutral.
  5. Review Additional wait. Do not change the answer until it reaches zero, and restore the longer TTL only after authoritative, resolver, and service checks pass.

Interpreting Results:

Ready now means the entered pre-lower lead covers the modeled safe drain. It does not prove that the authoritative zone is consistent or that every client path has refreshed. Check the expected record set on every authoritative server, then compare the same query through representative recursive resolvers.

Additional wait is the shortfall between elapsed lead and safe drain. Restore checkpoint is the earliest modeled point for returning to the steady-state TTL; service health and resolver evidence can justify waiting longer, never restoring earlier merely because the clock elapsed.

Query turnover is the current TTL divided by the temporary TTL. A value of 12× means caches can refresh up to twelve times as often under the simplified steady-query assumption. It is a pressure indicator, not a traffic forecast.

Technical Details:

The timing model converts every duration to seconds. It takes the maximum of the current record TTL, a known longer cache, and the negative-cache TTL, then applies an operator-selected safety factor. The longer optional values control only when they exceed the current TTL.

Formula Core:

The safe drain and any remaining delay before cutover are:

L=max(Tcurrent,Tknown,Tnegative) D=LF W=max(0,D−E)

L is the longest entered cache, F is the safety factor, D is safe drain, E is elapsed pre-lower lead, and W is additional wait.

Observation and restore timing use the temporary TTL after the answer changes.

O=TlowN C=max(D,E) R=C+A+O

O is observation time, Tlow is the temporary TTL, N is verification cycles, C is the planned cutover time measured from TTL lowering, A is cutover action time, and R is the restore checkpoint measured from the original lowering.

The minimum controlled window is safe drain plus action time plus observation. Stable-after-planned-cutover is additional wait plus action time plus observation, which is useful when the original cutover time was too early.

Turnover=TcurrentTlow

Rule Core:

RuleBoundaryResult
ReadinessAdditional wait = 0Ready
ReadinessAdditional wait > 0 and ≤ the larger of two temporary TTLs or 600 secondsNearly ready
ReadinessAdditional wait above that limitWait
Temporary TTL≤ 300 secondsFast
Temporary TTL> 300 and ≤ 600 secondsModerate
Temporary TTL> 600 secondsExtended

Positive TTLs must be greater than zero; lead, known longer cache, negative cache, and cutover time may be zero. Safety factor is 1.0 to 3.0, verification cycles are 0.5 to 6, cutover action is 0 to 1,440 minutes, and converted TTL values cannot exceed 2,147,483,647 seconds.

Limitations:

  • The safety factor and verification-cycle count are planning choices, not values required by the DNS standards.
  • The model does not query DNS, inspect SOA records, test authoritative agreement, measure actual resolver caches, or predict provider propagation.
  • Delegation, DS, DNSSEC, and multi-record or CNAME changes may involve additional cache lifetimes not represented by one record TTL.
  • Resolver policy may cap TTLs, retain stale data, or cache failures differently. Test from the networks and resolver paths that matter.

Worked Examples:

Prepared one-day lead

A 3,600-second current TTL, 300-second temporary TTL, 24-hour lead, and 1.5× safety factor produce a 5,400-second safe drain. The lead already covers it, so additional wait is zero. Two verification cycles add 600 seconds of observation after the cutover action.

Lowered too late

A four-hour current TTL lowered only one hour before the planned change, with a 1.25× factor, needs a five-hour safe drain. Additional wait is four hours. A five-minute temporary TTL also implies 48× cache turnover compared with the earlier four-hour value.

References: