Move authoritative DNS providers using inventory, lowered TTLs, parallel zones, DNSSEC checks, and measured rollback criteria.
What matters first
- Inventory the complete zone before moving it.
- Prove every new authoritative server before changing the parent delegation.
- DNSSEC state can turn a routine migration into a validation outage.
- Keep the old provider correct and available beyond the relevant cache window.
Inventory before editing
Export every record and compare apex, wildcard, mail, verification, CAA, SRV, and less-visible subdomains. Record DNSSEC state and any provider-specific flattening or traffic-management behavior.
Capture the pre-change baseline with the DNS report so address, mail, nameserver and SOA evidence remain comparable.
Prove the new authority
Load the new zone, query each new server directly, compare record sets and SOA behavior, and test DNSSEC validation if enabled. Lower relevant TTLs far enough in advance for older cached data to expire.
Change and observe
Update the registrar delegation, then sample multiple recursive resolvers and query parent and child data independently. Keep the old provider active beyond the longest practical cache window.
The DNS delegation guide explains the parent, child and glue relationships behind the rollback signals.
Rollback signals
Roll back or correct immediately when the parent points to unreachable servers, the new servers are non-authoritative, DNSSEC validation fails, or business-critical record sets differ. A few stale caches alone are not proof the new delegation failed.
Compare the old and new signing state with the DNSSEC check so a stale parent DS is detected before the old keys disappear.
Evidence-to-decision table
| Evidence | What it means | Responsible next step |
|---|---|---|
| Zone inventory | Baseline record sets and TTLs | Include wildcards, subdomains and policy records |
| Direct SOA query | New server answers authoritatively | Test every server and address |
| Parent delegation | Registrar change reached registry | Compare parent and child |
| Validation result | DNSSEC chain succeeds | Test before and after DS changes |
Illustrative phased provider migration
This is an illustrative example, not a claimed real-world test.
Export and compare the old and new zones, including less-visible SRV, CAA, DKIM and verification records.
Lower selected TTLs in advance, wait out the previous TTL, and directly query all new servers.
Change delegation, observe parent and child separately, and keep old authority serving matching data until stale caches are no longer expected.
Defensible outcome: Rollback criteria are defined before the change: unreachable authority, non-authoritative answers, missing critical records or DNSSEC validation failure require immediate correction.
Action checklist
- Freeze or track concurrent edits
- Inventory every record
- Document DNSSEC
- Reduce TTL in advance
- Load and compare new zone
- Test all NS addresses
- Change delegation
- Monitor multiple resolvers
- Retain old service
Edge cases that change the answer
Dynamic DNS features
Health checks, geo answers and alias flattening may not appear in a plain zone export; reproduce behavior explicitly.
Secondary transfers
Confirm AXFR/IXFR authorization, notification and serial handling when moving secondary architecture.
DS transition
Coordinate DNSKEY and parent DS changes carefully; a stale DS pointing at absent keys causes validating resolvers to fail.
Questions this guide should settle
How far ahead should TTL be lowered?
At least long enough for the previous higher TTL to age out before the delegation change.
Should the old zone be deleted immediately?
No. Cached delegation can continue sending resolvers there after the parent changes.
How do I know migration is complete?
Parent delegation, direct authority checks, representative recursive resolvers and application tests should all agree over the expected cache window.