DNS cutovers are state transitions, not record imports
A DNS migration changes which servers are authoritative for a zone. Copying visible records is necessary but insufficient: delegation, DNSSEC, hidden provider features, dynamic updates and cached data all affect the result. Resolvers may hold older positive or negative answers until their TTLs expire. That means rollback is time-dependent; changing nameservers back does not instantly erase cached answers.
Build the migration as a series of reversible gates. Preserve the source service until the new authority has served correct answers for at least the relevant cache and business observation windows. Define who can change the registrar, parent zone, old provider, new provider, DNSSEC material and dependent applications. Verify those access paths before the change window.
Discover the real zone and its dependencies
Export the zone through a supported provider method or AXFR where authorized and available. RFC 5936 defines AXFR for transferring a complete DNS zone, but many hosted platforms use proprietary exports or APIs instead.[1] Compare the export with direct authoritative queries and provider configuration. Capture the SOA, NS, A, AAAA, CNAME, MX, TXT, SRV, CAA, PTR dependencies, delegations, wildcards and DNSSEC records. Include low-visibility names used by certificate validation, mail, VPN, device enrolment, monitoring and service discovery.
Inventory features that do not map cleanly to standard records: alias or flattening behaviour at the apex, geo or latency steering, health checks, failover pools, weighted answers, traffic management, provider-specific proxying, synthesized records and dynamic DNS. Document split-horizon views and private zones separately. A public lookup cannot reveal internal answers.
Search configuration repositories, certificate inventories, mail systems and cloud resources for domain references. Query from more than one resolver and network, but distinguish recursive cache observations from direct authoritative answers.
Create a canonical, reviewable target
Normalize the exported data into a canonical inventory with owner and purpose for each record. Preserve values exactly while accounting for presentation differences such as trailing dots, quoting and provider-specific TTL displays. Check that aliases do not coexist with other data where prohibited and that apex behaviour is supported by the destination.
Build the target zone before changing delegation. Query each new authoritative nameserver directly for representative positive answers, nonexistent names, wildcard boundaries, delegated children and DNSSEC material. Confirm consistent serial and data across the provider's authoritative set. Test UDP and TCP responses where practical, plus IPv4 and IPv6 reachability. DNS terminology distinguishes a server that has a local copy from a server actually delegated by the parent; pre-delegation direct answers prove zone loading, not public authority.[2]
Validate dependent protocols, not just DNS syntax. Confirm that mail destinations accept expected traffic, certificates cover new endpoints, CAA permits intended issuance, and application host routing recognizes every migrated name.
Plan TTL changes using the existing cache lifetime
Lower selected TTLs before the migration by at least their current TTL plus operational margin. A new lower value only helps queries answered after it is published; caches holding the previous value can retain it for the older lifetime. Record the time each reduction became authoritative and the earliest point at which the old value should have aged out.
Lower the records likely to change during cutover or rollback. The parent delegation has its own TTL and operational behaviour, which may not be controlled from the child zone. Negative answers are cached too; RFC 2308 specifies negative caching, so testing an uncreated name shortly before adding it can produce confusing results until the negative cache expires.[3]
Avoid unnecessarily tiny TTLs for a long period. They increase query volume and dependence on authoritative availability. After stability is established, restore values that match the service's change frequency and recovery design.
Handle DNSSEC as a separate trust-chain change
DNSSEC adds parent-held delegation signer (DS) state to the migration. A signed child zone with mismatched keys or signatures can validate as bogus and fail for validating resolvers even while non-validating tests appear normal. RFCs 4033, 4034 and 4035 define the core DNSSEC model and validation behaviour.[4]
Choose a provider-supported transfer procedure. Depending on provider and registrar capabilities, this may involve a pre-publish key rollover, coordinated DS update or a controlled transition to an insecure delegation before re-enabling signing. Do not improvise by copying DNSKEY records without access to the corresponding private keys and signing process. Record key tags, algorithms, DS values, signature timing and exact parent state at each gate.
Use validating tools and public validating resolvers to test the chain from the root to the zone. A direct query showing an RRSIG is not enough; validate that the parent DS matches a current DNSKEY and that signatures are valid. The rollback plan must include DNSSEC state. Reverting only NS records while leaving an incompatible DS can prolong failure.
Choose a cutover pattern and define authority overlap
The common pattern is to fully configure the new provider, then replace the delegation at the registrar or parent. During propagation, some resolvers will query the old authority and others the new one. Keep both zones serving equivalent answers. Freeze routine DNS changes or apply every approved change to both providers until the overlap ends.
Adding new nameservers to the existing delegation before removing old ones is not automatically a safe canary. Resolvers may select any delegated server, so inconsistent zones produce nondeterministic answers rather than a controlled percentage rollout. Use mixed delegation only when both providers serve equivalent data and the DNSSEC design explicitly supports it.
Set a precise change window in UTC, list the exact old and new nameserver sets, confirm registrar lock and MFA procedures, and capture parent and child NS answers immediately before change. If in-bailiwick nameservers or glue records are involved, include registrar or registry glue updates in the plan.
Validate through three independent views
First, query every new authoritative server directly and confirm the authoritative answer, SOA, negative response and DNSSEC data. Second, query the parent to confirm the delegation and DS state it currently publishes. Third, test through multiple recursive resolvers and user networks to observe cache transition. These views answer different questions and should not be conflated.
Run protocol-level smoke tests for the apex, `www`, APIs, mail, authentication, VPN and certificate issuance. Check HTTP host routing, TLS certificate and application response—not only the resolved address. Monitor DNS response codes, authoritative query volume, application errors, mail queues and support channels.
Record timestamps, resolver addresses, command output and interpretation. Avoid declaring completion because one laptop resolves correctly; its cache may be empty or may use a resolver that has already refreshed.
Define rollback by failure mode
Rollback should identify what failed. If one record is wrong on the new provider, correct that record on both authorities rather than immediately reverting delegation. If the new authoritative service is broadly unavailable or the zone is incomplete, restore the old NS set. If DNSSEC validation fails, follow the pre-approved DS and key-state recovery path. Registrar and parent updates may take time, so escalation contacts and access are part of recovery.
Specify triggers: sustained SERVFAIL from validating resolvers, inconsistent authoritative answers, failed critical transactions or a defined application error threshold. Assign one decision-maker and one operator, with a second reviewer for exact values. Preserve evidence before changing state, but do not delay recovery to perfect the incident record.
After rollback, query the parent, both authoritative sets and recursive resolvers; then run application tests. Keep the new service intact for analysis. Do not delete either zone until caches, DNSSEC state and business telemetry demonstrate stability.
Close the migration deliberately
After the maximum relevant delegation and record TTLs have elapsed and monitoring is clean, restore planned TTLs, unfreeze record changes and designate the new system of record. Re-enable automation only after updating API endpoints, credentials and record identifiers. Test a low-risk automated change and verify it on all authoritative servers.
Remove obsolete provider access and billing only after the rollback retention period. Archive the source export, target inventory, registrar change record, DNSSEC state, validation evidence and incident notes. Update diagrams and ownership records. Schedule a later review for stale records, DNSSEC rollover readiness and emergency registrar access.
Implementation checklist
- Verify access to the registrar, parent, old provider and new provider.
- Export and archive the source zone plus provider-specific routing features.
- Inventory public, private, delegated, dynamic and protocol-specific dependencies.
- Build a canonical record list with owner and purpose.
- Load the destination and query every new authoritative server directly.
- Validate apex aliases, wildcards, negative answers, mail, CAA and application routing.
- Lower selected TTLs early enough for the previous values to expire.
- Document parent delegation TTL and negative-cache effects.
- Choose and peer-review a provider-supported DNSSEC transition.
- Keep old and new zones equivalent throughout authority overlap.
- Freeze DNS changes or replicate each approved change to both providers.
- Capture exact NS, glue and DS values before changing the parent.
- Validate authoritative, parent and recursive views independently.
- Set measurable rollback triggers and failure-specific recovery steps.
- Retain both providers until cache windows and business monitoring are clean.