DNS Configuration & Hosting Cutover
Executive Summary
Execute a controlled DNS configuration and hosting cutover with zero service interruption. This playbook coordinates the DNS lead, database owner, and on-call SRE through authoritative zone preparation, TTL reduction, staging synchronisation, traffic routing, and post-switch validation. The outcome is a deterministic switch where every global resolver adopts the new origin within minutes, mail routing stays intact, search signals are preserved, and a rehearsed rollback path stands ready if any threshold is breached.
A hosting cutover is the single highest-risk hour of most technical migrations because it touches every layer at once: the authoritative DNS zone, the recursive resolver caches you do not control, the CDN edge, the origin servers, the database, and the mail flow. The failure modes compound — a forgotten SOA serial increment hides a stale secondary, an unlowered TTL strands a fraction of users on a dead IP for a day, and an unaligned auto-increment offset corrupts rows the moment writes resume. The discipline that prevents all of this is sequencing. Each of the four working phases below has a single owner, a clear entry condition, an explicit exit gate, and a numeric rollback trigger, so no one improvises mid-switch. Treat the timeline as a contract: TTL reduction completes before sync, sync proves parity before the record swap, and the swap is never declared done until propagation tracking confirms global adoption.
The four phases map onto four detailed runbooks. TTL Optimization Strategies shrinks the cache window so the switch — and any reversal — takes minutes rather than days. Staging to Production Sync makes the new origin byte-identical to what was tested and captures the final transactional delta. Zero-Downtime Cutover Plans chooses and drives the switching mechanism — weighted DNS or blue-green — so traffic shifts gradually with an instant reversal at every step. DNS Propagation Tracking proves the change reached every region before the legacy origin is retired. When a phase breaches its threshold, the Migration Rollback Playbooks define the reversal, and the Search Console Handover protects search equity once the dust settles.
Prerequisites
Every item below exists because a cutover has failed without it. Gather them as artefacts, not intentions — a credential someone “can get” during the window is a credential you do not have, and a backup nobody has restored is a backup that does not exist. Assign each line to a named person before the window opens.
- Full administrative access to authoritative DNS providers, registrar consoles, and CDN dashboards.
- Read/write database backups, GTID positions, and static asset snapshots captured immediately before the window.
- Staging environment matching production topology: OS kernel, runtime versions, schema, and TLS chains.
- Audited SPF, DKIM, and DMARC records so mail routing survives the IP change.
- Baseline organic traffic, indexation, and origin latency metrics for validation comparison.
- Defined rollback triggers and an incident communication channel agreed with stakeholders.
Two of these deserve a rehearsal rather than a checkbox. First, restore the database backup into a scratch host and run the application against it; a dump that completes without error but omits routines, triggers, or the GTID position will only reveal itself when you need it most. Second, exercise the registrar credentials before the window — registrar accounts are frequently held by a finance or procurement owner, protected by an MFA device nobody in the room has, and locked by a 60-day transfer hold that cannot be lifted in an afternoon. The registrar is the one layer in this playbook with no workaround: if you cannot change delegation, there is no cutover.
Baseline metrics deserve the same rigour. Capture organic traffic, indexation counts, and origin latency percentiles as stored artefacts, not dashboard screenshots, because the question after cutover is never “does this look about right” but “is p95 latency worse than the number we recorded on Tuesday”. Without a stored baseline, every post-cutover anomaly becomes an argument.
Step-by-Step Execution
1. Reduce TTL and Prepare Authoritative Zones
Audit every authoritative zone for orphaned A, AAAA, CNAME, MX, and TXT records and delete stale entries before propagation begins. Reduce cache retention windows using the staged schedule in TTL Optimization Strategies 48–72 hours before execution so global resolver caches expire in time. Validate nameserver delegation chains and confirm secondary DNS is fully synchronised.
The zone audit matters more than it sounds. Most production zones accumulate a decade of records — a TXT verification token for a tool nobody uses, an A record for a subdomain that was decommissioned in a previous migration, a CNAME pointing at a vendor who no longer exists. Each is harmless while the origin IP is stable and actively dangerous during a cutover, because a stale record that still resolves gives traffic, crawlers, and certificate issuers a route to infrastructure you are about to switch off. Delete them before the TTL reduction so the deletions propagate on the same schedule as everything else, and keep the removed set in the rollback snapshot in case one of them turns out to be load-bearing.
Delegation is the other half of this step. Confirm that the NS records at the registrar match the NS records inside the zone itself, and that every listed nameserver actually answers authoritatively for the domain. A mismatch here produces the most confusing class of cutover bug: the change works when you query your provider directly and appears not to have happened when you query the internet, because some resolvers are following delegation to a nameserver that never received the update.
2. Synchronise Staging and Production Data
Run automated database replication between legacy and target hosts, then verify static assets and file permissions. Enforce the parity protocol in Staging to Production Sync to eliminate configuration drift, schema mismatches, and auto-increment collisions. Run synthetic transactions against staging IPs and confirm SSL/TLS chains and WAF rules match production.
Parity is a stricter standard than “works”. A staging environment that serves the right pages can still differ in the ways that break a cutover: a different PHP or Node minor version that changes date handling, a character_set_server that silently mangles non-ASCII on write, an auto-increment counter that starts below the highest primary key already in production, or a WAF running in log-only mode so rules that will block real traffic have never actually fired. Compare these as configuration values, not behaviours — diff the outputs of SHOW VARIABLES, the runtime version strings, and the WAF rule set, because behavioural testing only finds the differences your test data happens to trigger.
The final sync is where sequencing becomes non-negotiable. Writes must be frozen before the last delta is captured, or the delta is captured against a moving target and rows written between the snapshot and the switch exist on the legacy origin only. That data is not recoverable by re-running the sync afterwards, because by then the new origin has begun issuing its own primary keys in the same range. The write lock is short — usually ten to fifteen minutes — and it is the cheapest insurance in the entire migration.
3. Stage the Cutover Routing Plan
Choose the switching mechanism — weighted DNS, blue-green, or geographic load balancing — using Zero-Downtime Cutover Plans. Pre-stage the new records pointing at staging IPs for a dry run, and reconcile the redirect map from URL Mapping & Redirect Architecture so legacy paths resolve cleanly on the new origin.
The choice of mechanism is really a choice about how you want to reverse. Weighted DNS shifts a percentage of resolvers to the new origin and reverses by shifting the weight back, but the reversal is still bounded by resolver cache lifetime, so it inherits whatever TTL is in force. Blue-green keeps both origins warm behind a load balancer and reverses at the balancer, which is effectively instant and independent of DNS — at the cost of running two full environments and keeping their data consistent for the duration. For a single-region site with a well-lowered TTL, weighted DNS is usually enough; for anything transactional, the instant reversal of blue-green is worth the extra infrastructure.
The dry run is the part teams skip and regret. Pointing the new records at staging IPs and walking the top landing pages, the checkout flow, and the login path exercises the entire chain — delegation, TLS, routing, application, database — under real DNS resolution rather than a hosts-file override. A hosts-file test proves the origin works; it proves nothing about the resolution path that will actually carry your users.
4. Swap Authoritative Records
Lock source writes, finalise the incremental data sync, then update authoritative A/AAAA records to the new origin IPs during an off-peak window. Increment the SOA serial on every change and confirm secondary nameservers adopt it before you trust the switch. Watch real-time query resolution and NXDOMAIN spikes from the first second, because the cheapest moment to abort is before any meaningful traffic has reached the new origin.
Off-peak is chosen for blast radius, not for politeness. The window should be the trough in your own traffic curve, which for most sites is not the small hours in your head office timezone but the small hours in whichever region dominates your sessions. Check the curve rather than assuming it. Equally, avoid windows that sit immediately before a period when nobody is available: a cutover at 02:00 on a Saturday that goes wrong at 09:00 on a Sunday is a cutover with no one watching it.
The SOA serial is the single most commonly skipped detail in this step and the most expensive. Secondary nameservers decide whether to pull a zone transfer by comparing serials; if the serial has not increased, a secondary that already holds the old zone will keep serving it indefinitely no matter how many times you push the change. The failure presents as partial propagation that never resolves, and it is invisible unless you query each authoritative nameserver directly rather than querying the domain and accepting whichever nameserver answers.
5. Track Global Propagation
Confirm resolver cache adoption across regions with DNS Propagation Tracking before decommissioning anything. Do not retire legacy infrastructure until worldwide record adoption is verified and CDN edges pull from the new origin rather than cached legacy IPs.
“Retire” should be staged rather than binary. Keep the legacy origin running and serving correctly for at least a full TTL cycle beyond the point where tracking says adoption is complete, then stop the application but leave the host reachable for another few days, and only then release the IP. Releasing an IP early is uniquely unrecoverable: cloud providers recycle addresses quickly, and a resolver still holding your old record will send your users to whoever holds that address next. That is a far worse outcome than a timeout.
6. Integrate the Edge and Verify Search Signals
Reconfigure CDN origin pull endpoints to the new host IPs and purge stale edge objects immediately after the DNS update. Validate cache-control headers, canonical tags, and robots.txt accessibility. Submit updated sitemaps and begin the Search Console Handover so crawl budget tracks the new property without organic visibility loss.
Order matters at the edge as much as it does in DNS. Purging before propagation completes simply re-pins edge nodes to whichever origin they can currently resolve, which during a partial propagation is often the legacy one — so an early purge actively extends the split. Wait for the adoption threshold, then purge, then verify by requesting a known-changed asset through the edge and confirming the response carries the new origin’s headers rather than a cache hit.
The search-side checks are easy to defer and expensive to defer. A robots.txt that was permissive on the legacy origin and restrictive in the new repository will de-index the site faster than any redirect mistake, and because it is served correctly with a 200 response, nothing in the infrastructure validation will flag it. Fetch robots.txt, the XML sitemap, and a representative canonical tag from the new origin as the first three requests after the swap.
Written out as a grid, the contract behind those six steps is easier to hold in one head during the window: who owns the phase, what proves it finished, and the single number that ends it.
Technical Configs
These fragments cover the layers a cutover touches in order: the zone metadata that governs caching and validation, the reverse-DNS and health-check plumbing that keeps mail and failover honest, and the API call that performs the swap. Adapt the placeholders to your provider but keep the sequence — verify FCrDNS and health checks before the swap, not after.
SOA record values — increment the serial on every zone change:
; serial = YYYYMMDDNN (e.g., 2026061901) — bump or secondaries ignore the change
; refresh = 3600
; retry = 900
; expire = 604800
; minimum = 300 ; controls negative (NXDOMAIN) cache durationDNSSEC rollover parameters (BIND/Knot zone signing policy):
# Keep KSK active while the ZSK rolls to avoid SERVFAIL on validating resolvers
dnssec_rollover:
algorithm: ECDSAP256SHA256
key_signing_key: active
zone_signing_key: rollover_pending
signature_validity: 30dForward-confirmed reverse DNS check (dig):
# FCrDNS must agree both directions or mail filters will penalise the new origin
NEW_IP="203.0.113.10"
dig -x "$NEW_IP" +short # should return new-origin.example.com.
dig new-origin.example.com +short # should return $NEW_IPRoute53 health check (AWS CLI JSON fragment):
# Drives automatic failover when the new origin stops answering /healthz
anycast_health_check:
Type: HTTP
RequestInterval: 10
FailureThreshold: 3
ResourcePath: /healthz
FullyQualifiedDomainName: origin.example.comCloudflare API — swap an A record to the new origin (dig-verifiable):
# PATCH the record, then confirm propagation with dig before purging caches
curl -s -X PATCH "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records/{record_id}" \
-H "Authorization: Bearer {token}" \
-H "Content-Type: application/json" \
-d '{"content":"203.0.113.10","ttl":60}'What those fragments have in common is that each one addresses a different layer, and the layers differ in something that matters more than their configuration syntax: whether you can change them on demand at all. Sequencing a cutover is largely a matter of respecting that boundary.
Validation & Rollback
Confirm the switch empirically before standing down. Keep the rollback path warm until global adoption is proven.
Post-Cutover Validation Checklist:
Common Pitfalls:
- Leaving TTL at the default 86400 s, stretching propagation to 24–48 hours.
- Modifying mail routing before DNS logs confirm 100% resolution to the new origin.
- Forgetting to increment the SOA serial, so secondaries silently keep stale data.
- Purging CDN caches before propagation completes, forcing re-fetch from the old origin.
- Trusting a single resolver instead of checking adoption across regions.
Rollback Protocol:
- Revert authoritative A/AAAA records to legacy IPs and restore the prior SOA serial increment.
- Restore previous CDN origin configuration and invalidate edge caches for affected paths.
- Confirm HTTP 200 on legacy paths and resolver agreement on the old IP.
- Notify stakeholders, follow the Migration Rollback Playbooks, and document failure vectors.
Trigger rollback when NXDOMAIN rates exceed 5% for more than 15 minutes, database replication lag passes the agreed ceiling, email deliverability drops from SPF/DKIM misalignment, or enterprise ISP caching creates localised traffic blackholes.
Two properties separate a rollback protocol that works from one that only reads well. The first is that it must be rehearsed against the real infrastructure, not reasoned about — run the revert in a staging window, time it end to end, and record the number. If reverting takes longer than the watch window in which you promised to detect a failure, the protocol is decorative. The second is that the decision to invoke it must belong to one named person with the authority to call it without convening anybody, because rollbacks are most valuable in the first fifteen minutes and consensus does not form that fast.
There is also a decision the protocol above deliberately does not make for you: whether to roll back or roll forward. Reverting DNS is correct when the new origin is broadly broken — wrong content, failing TLS, an application that will not start. It is often the wrong move for a narrow defect affecting a subset of routes, because a revert re-caches the legacy IP across every resolver and buys you a second full propagation cycle before you can try again. For a bounded problem, fixing forward on the new origin while traffic is still weighted low is usually faster and cheaper. Decide which class of failure you are looking at before reaching for the revert, and write that distinction into the runbook so the on-call engineer is not making a taxonomy judgement at three in the morning.
Finally, capture evidence as you go rather than afterwards. Resolver answers, CDN error rates, origin logs, and the exact timestamps of each phase transition are cheap to collect during the window and effectively impossible to reconstruct once caches have turned over. A cutover that succeeded without evidence teaches you nothing for the next one.
FAQ
How long before cutover should TTL values be reduced? Reduce TTLs to 60–300 seconds 48–72 hours before execution so global resolver caches expire and the new IP is adopted within minutes of the authoritative update; stage the reduction rather than dropping straight to 60 s.
How do we maintain email service continuity during DNS switching? Keep identical MX, SPF, DKIM, and DMARC records across both zones until propagation is verified, and do not touch mail routing until DNS query logs confirm 100% resolution to the new infrastructure.
What metrics indicate a successful DNS cutover? A query failure rate below 1% in authoritative logs, consistent HTTP 200/301 responses from the new origin, zero SSL handshake errors, and resolver alignment confirmed across multiple regions.
How should the CDN cache be handled during the transition? Use origin shield routing, purge critical paths immediately after the DNS update completes propagation, validate cache-control headers, and keep a dual-origin fallback until edge caches fully repopulate.
Can I cut over without lowering TTL first? You can, but expect 24–48 hours of split traffic while cached records expire, and accept that a rollback during that period is equally slow — you are choosing to run without a fast reversal. It is occasionally the right trade for a low-traffic site where the legacy origin can stay live indefinitely and a slow tail costs nothing. For anything transactional it is not, because the split period is exactly when writes are landing on two origins. For a controlled switch always run the staged TTL reduction described in TTL Optimization Strategies first.
What if some resolvers never adopt the new record? A residual few percent is normal and usually traceable to enterprise firewalls and legacy office appliances that enforce their own cache minimums regardless of your TTL. Do not wait them out indefinitely. Keep the legacy IP answering with a permanent redirect to the new origin so stragglers are carried across rather than stranded, and only release the address once traffic to it has decayed to effectively zero. Trying to reach 100% adoption before proceeding will stall the migration on a population you cannot influence.
Who should own the decision to roll back? One named person, agreed before the window, with the authority to invoke the revert without seeking approval. Rollback value decays fast — the difference between calling it at minute five and minute forty is often the difference between a non-event and a recovery project — so the protocol must not require a meeting. Everyone else’s role during the window is to feed that person numbers against the agreed thresholds.
Related
- TTL Optimization Strategies
- Staging to Production Sync
- DNS Propagation Tracking
- Zero-Downtime Cutover Plans
- Migration Rollback Playbooks
← Back to Home