Choose DNS TTL values for a migration: record the assumptions

Choose an expectation before choosing a number

Name the permitted record/type, reason for a temporary setting, DNS provider, mode and evidence owner. Separate the current value, candidate value and any inherited default. Mark each field editable, fixed or unknown with a dated provider reference. A displayed TTL does not necessarily mean an editable record setting.

This decision record is narrower than a cutover runbook. Keep publication sequence, operational checkpoints and reversal in that plan, and mail dependencies in their own review. Do not change unrelated records or delegation merely to make a timing proposal look shorter.

Start with a blank TTL decision record

Cover: purpose/record scope ____; provider/mode/plan reference and date ____; owner ____; proposed window/timezone ____; protected dependencies ____; separate cutover owner ____. Use approved evidence references rather than credentials or private zone values. Repeat the card per record or expectation.

A blank or unknown field is an explicit limit. Neither a proposed publication time nor a formula proves an operation occurred. Record later observations with their own source, time and scope if separately authorized.

Check duration and provider control separately

RFC 8767 Section 4 describes TTL as a duration in seconds before the source must be consulted again; zero is scoped to the transaction in progress. It also permits conditional use of expired data when authoritative refresh fails. This March 2020 document therefore does not support treating TTL as an unconditional freshness deadline. It does not say every resolver uses serve-stale.[1]

Cloudflare’s page, updated April 16, 2026, documents fixed Auto 300 seconds for proxied records, selectable plan-dependent options for DNS-only records, and a separate nameserver-TTL feature. It also warns that local caches can delay the change a user sees. Verify the actual mode and current options before use: Auto and editability are not universal provider properties.[2]

Treat an absent answer as a separate branch

RFC 2308 Sections 3–5 describe the scoped negative-answer lifetime using the smaller of the SOA record TTL and SOA.MINIMUM. They distinguish NXDOMAIN’s name/class cache key from NODATA’s name/type/class key. A timeout, other error or empty response is not automatically either absence case. Ask the relevant owner what evidence applies; this guide makes no query.[3]

The March 1998 document also distinguishes the master-file $TTL default for following records without an explicit TTL from SOA.MINIMUM. A positive A/AAAA candidate or $TTL default is not a substitute for negative-cache evidence. Historical signature details and numerical resolver recommendations are outside this guide; no assumption is made that a provider exposes these controls.[3]

Fictional Birch Lantern Migration: revise the proposed lead

T1 proposes publishing the lower TTL at 08:00 and a separate cutover at 09:30. 7200 seconds = 2 hours, so the simplified horizon is 08:00 + 2 hours = 10:00. The proposal gives 90 minutes of lead, 30 minutes short: REVISE. Even 10:00 would not prove all caches expired or service readiness. Candidate 600 does not retroactively replace old 7200 in cached answers.

For T3, min(1800,900) = 900 seconds = 15 minutes. If one fictional resolver stored that scoped NXDOMAIN answer at 14:05, its ordinary negative-TTL model reaches 14:20. A 14:10 use proposal is 5 minutes after insertion, 10 minutes short. This is independent of T1’s 600 candidate, not a shared insertion time or an actual absence finding. NODATA and other errors must retain their own classification.

Three rows: 1 configurable setting with lead revision + 1 fixed-mode edit rejection + 1 independent negative-policy case = 3. No universal TTL is selected. No publication, cache flush or target retirement follows. Fictional review owner Mira will revisit T1 only after separately authorized cutover acceptance evidence, which is not supplied.

Write a conditional timing expectation

A shorter candidate can reduce the normal lifetime of future cached answers, with a caching-versus-refresh tradeoff. It does not cure a target failure, delegation problem, local-cache behavior or failed refresh. Keep the prior TTL and planned publication on different lines from the future candidate.[2]

State what is still unknown about actual prior refreshes and conditional serve-stale policy. A simplified old-value horizon can expose an obviously short lead, but it does not establish a final expiry everywhere, an effective maximum stale interval or service acceptance. No automatic 60/300 second or 24–48 hour recipe follows.[1]

Assign the next evidence and review owner

Hand over the supported candidate and reason, controllability evidence, old-answer assumption, separate negative branch, unresolved questions and qualified timing statement. Name who reviews a temporary TTL after the separate cutover is accepted and what triggers that review. Restoring a longer value creates its own expectation; this worksheet neither executes that action nor authorizes service retirement.