Plan a DNS cutover: four checkpoints and a scoped reversal
A DNS cutover plan should let an authorized owner decide whether a specific record change is ready, what evidence follows publication and when to stop. A submitted change is not proof that every client has moved. This original planning guide uses sources accessed October 14, 2026. It performs no DNS queries, account operations or changes and grants no operational authority.
Boletolibre editorial team
Published
Define the record change before the window
Name the service and exact record sets proposed for change. Preserve complete prior values, TTL, provider mode and relevant alias, proxy or routing metadata, together with dated evidence references. Separate proposed values from confirmed target readiness. A cropped value screenshot may omit information needed to reconstruct the prior record set.
This guide concerns a bounded record change under an unchanged DNS provider and delegation. Moving authoritative providers, hosting, databases or a public brand needs separate plans. Explicitly exclude mail and delegation changes, and assign dependency questions to their owners. An exclusion is a review boundary, not proof that a shared target cannot affect another service.
Copy a blank decision record first
Cover: service/host scope ____; window/timezone ____; provider/mode ____; change authority ____; decision owner ____; reversal authority ____; review date ____. Keep credentials and private account identifiers out of the shared plan. Repeat this two-column card for each permitted change.
| Runbook field | Your evidence or open question |
|---|---|
| Exact delta | Name/type ____; complete prior record-set reference ____; candidate reference ____. |
| Target readiness | Target owner ____; confirmation and acceptance conditions ____; missing record family ____. |
| Dependency boundary | Protected records/services ____; shared address or mail question ____; owner ____. |
| Execution boundary | Provider-correct ordering/batch assumptions ____; separately authorized operator ____. |
| Observation plan | Provider receipt ____; authoritative source ____; recursive/client and service scope/time ____. |
| Stop condition | Failure/hold trigger ____; decision owner ____; review checkpoint ____. |
| Reversal packet | Complete prior metadata ____; old-target readiness ____; provider-correct method and approval ____. |
| Decision record | Go/hold/qualified ____; unresolved gates ____; next owner and time ____. |
An empty field is a visible gap. Do not convert it into assumed readiness or permission to publish only the convenient half of a related change.
Keep four checkpoints distinct
| Checkpoint | Evidence to request under separate authority |
|---|---|
| 1 Readiness | Approved scope, confirmed target families, dependencies and a usable prior-state/reversal packet. |
| 2 Provider acceptance | Submission receipt and the provider behavior applicable to this exact mode. |
| 3 Authoritative publication | Dated observations about the relevant authoritative responses. |
| 4 Client/service acceptance | Scoped recursive/client observations and the service owner’s agreed acceptance evidence. |
Route 53 documents a change batch as a provider-side transaction: validation leads to all or none of that batch being applied. That supports a distinction between batch acceptance and a partial provider update; it does not establish a transaction across providers, clients or application state. No API request is performed here.[2]
Its PENDING and INSYNC statuses concern propagation to the Route 53 authoritative servers managing the zone. INSYNC is not evidence that every recursive cache, visitor or service has accepted the new destination. Record the provider receipt, authoritative evidence and service acceptance separately rather than promoting one status into whole-system success.[2]
Use cache arithmetic as an assumption
Cloudflare’s TTL documentation describes record caching and different controls for proxied, DNS-only and nameserver settings. It also notes that local caches may delay the change a person sees. Its displayed update is April 16, 2026. Treat mode, permitted settings and local behavior as provider-specific inputs; no one short TTL or universal completion interval follows from that page.[1]
If a separately authorized lowering is relevant, record the old TTL and evidence of when it was published. A simplified old-cache horizon can help plan observations, but earlier cached answers, local behavior and actual target readiness still need consideration. Avoid replacing observations with a countdown or changing unrelated TTLs.
Fictional Pine Lantern Fair: the missing AAAA target holds the plan
| Fictional candidate | Story evidence and unresolved gate |
|---|---|
| W-A: apex / A | OldWeb-v4 → NewWeb-v4; prior metadata retained and target-owner confirmation recorded in the story. |
| W-AAAA: apex / AAAA | OldWeb-v6 → NewWeb-v6; prior metadata retained, but candidate target confirmation is missing. |
Assume a fictional DNS-only provider permits the chosen TTL change: old TTL 1800 seconds, lowering to 300 seconds published at 08:00. The simplified horizon is 08:00 + 1800 seconds = 08:30; proposed 10:00 is 90 minutes later. This proves no actual cache state, readiness or propagation completion.
G1 baseline/reversal packet is ready in the story; G2 protected mail/delegation review is ready; G3 confirmation of both target families is pending. Thus 2 ready + 1 pending = 3 gates, and the decision is NO-GO. The ready A candidate does not authorize publishing around the missing AAAA confirmation. Assign that gap to the target owner and obtain a new decision before rescheduling.
Make reversal another evidenced decision
Route 53’s deletion documentation requires the same original values used to create the record set. This is a provider-specific reason to retain complete prior descriptions; it is not universal deletion syntax or a ready-to-run reversal instruction. Other modes/providers need their own confirmed method.[2]
For a counterfactual later approved publication, specify the service-failure trigger, decision owner, old-target readiness, exact prior record sets and authorized reversal method. After reversal, collect new provider, authoritative and client/service evidence; cached old and new answers may coexist. Repointing DNS does not recover application writes, mail or other out-of-scope state. This document does not authorize retiring either target.
Return the unresolved gate to its owner
Deliver the permitted delta, checkpoint evidence plan, missing confirmations, reversal packet and an explicit go/hold decision. A service owner may supply readiness evidence through their approved workflow; this article neither performs it nor substitutes a worksheet for acceptance.
For the fictional case, the next useful action is the missing target-family confirmation, not publication. For a real case, confirm then-current provider behavior and authority before any operation. Use separate mail-preservation, TTL-selection and zone-documentation guides for those decisions. No ownership, availability, instant recovery or global cutover deadline is established.
Sources and further reading
- TTL definition and provider-mode/local-cache distinctions; displayed update April 16, 2026Cloudflare · Accessed
- Route 53 change batches, authoritative PENDING/INSYNC scope and original-value deletion requirementsAmazon Web Services · Accessed