HowToCodePage

Migrating DNS providers without downtime

Inventorying a zone, matching TTLs and provider behaviour, a staged nameserver cutover, verifying email and verification records, and rolling back.

Inventory first

  1. Export the full zone as a BIND file from the current provider. Do not work from a screenshot of the console.
  2. List every record type present. TXT records especially hide domain verifications, site ownership proofs and email authentication that nobody remembers adding.
  3. Note the TTL of every record. Lower anything above an hour to 300 seconds at least two days before the move, and wait out the old TTL before cutting over.
  4. Identify which names anything external depends on - MX targets, CNAME targets for SaaS products, ACME validation records.
  5. Record the current nameserver set. That list is your rollback target.
  6. Export DNSSEC state. If the zone is signed, plan the DS change as a separate step, not part of the nameserver switch.
# three ways to capture the current zone - use at least two
dig AXFR example.com @ns1.example.com > zone.txt      # if transfers are permitted
dig +short ns example.com                            # current delegation
dig SOA example.com @ns1.example.com                 # current serial and timers

# a full check of the record types that matter
for t in A AAAA CNAME MX TXT NS CAA SRV; do
  echo "== $t"
  dig +short $t example.com @ns1.example.com
done

The staged cutover

StageActionVerification
PrepareCreate the zone at the new provider, keeping the current TTLsQuery the new authoritative servers with +norecurse
ShadowCompare every record between old and new providersAutomated diff of the two zone exports
Cut overChange the nameserver delegation at the registrarWatch dig +trace move to the new servers
VerifyCheck resolution, email, certificates, and each external integrationTwo public resolvers plus the authoritative servers
SettleRaise TTLs back to normal after 48 hoursNo reports of inconsistency
Rollback windowKeep the old zone live and unmodified for a weekDocumented and rehearsed
  • Do not delete the old zone. Leave it serving until the new delegation has been stable for at least a week; keeping it costs nothing and is your rollback.
  • Change the nameservers at the registrar, not the records. The delegation is the single switch.
  • Expect a mixed period. Some resolvers keep using the old servers for the remaining TTL, so answers will differ between resolvers for up to that long.
  • Recreate records exactly, including the trailing dot in fully qualified names. A missing dot turns mail.example.com. into mail.example.com.example.com. - a classic and silent error.
# confirm a resolver is now reaching the new servers
dig NS example.com @a.gtld-servers.net +norecurse

# compare answers from old and new authoritative servers before the switch
diff <(dig +short www.example.com @old-ns1) <(dig +short www.example.com @new-ns1)

# after the switch, verify from several vantage points
for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
  printf '%-12s %s\n' "$r" "$(dig +short www.example.com @$r | tr '\n' ' ')"
done

The things that break quietly

What breaksWhyCheck
Email deliveryMX or SPF lost in the copydig MX and dig TXT on the apex
Certificate renewalAn ACME validation TXT or CNAME was not recreatedRenew early, on purpose, after the move
SaaS integrationsA domain verification TXT disappearedRe-run the vendor's verification
SubdomainsRecords outside the apex were missed in the exportDiff the old and new zone files
CAAA CAA record now blocks the wrong certificate authoritydig CAA example.com
SigningDS still points at the old keyValidating resolver returns ad
Private namesSplit-horizon or internal-only records not migratedInternal resolution test
WildcardWildcard not recreated, so typo domains stop answeringQuery a nonexistent name
# a compact post-migration checklist
dig +short NS    example.com @a.gtld-servers.net +norecurse
dig +short A     example.com
dig +short MX    example.com
dig +short TXT   example.com | grep -E "spf1|google-site-verification|_dmarc"
dig +short TXT   _dmarc.example.com
dig +short CAA   example.com
dig +dnssec      example.com @1.1.1.1 | grep -c "ad;"
⚠️
Roll back by changing the nameservers at the registrar, not by trying to fix the new zone quickly. A delegation change is atomic and takes effect within the old TTL, whereas a stream of record edits in an unfamiliar console is how a short outage becomes a long one.

FAQ

How long does a provider migration take?
The cutover itself is minutes; the safe window around it is days. Lower TTLs 48 hours before, keep both zones live for a week, and raise TTLs only once the new provider has been stable.
Can I migrate the registration and the DNS at once?
Do not. Transfer the registrar first and confirm the site is stable, then move the zone. Two simultaneous changes make any failure impossible to attribute.

Registrars, registries and managing a domain DNS as code: providers and Terraform

Last refreshed 2026-09-18.