Migrating DNS providers is one of those jobs that looks trivial on paper – export a zone, import it somewhere else, flip the nameservers – and then quietly breaks email, certificate renewals or a forgotten partner API three days later. This guide covers how to plan and run a DNS provider migration without downtime or lost records. It explains what actually happens during the cutover, where records usually go missing, and how to verify the new zone before any resolver ever queries it.
The good news is that a zero-downtime move is entirely achievable. Both providers can answer authoritatively at the same time, so if the zones are identical, resolvers never notice the switch.
Why DNS Migrations Fail Quietly
Most migrations don’t fail at the moment of the nameserver change. They fail when a record that nobody knew about stops resolving. That might be a DKIM selector for a marketing platform, a TXT verification token for Microsoft 365, or a CAA record limiting certificate issuance to Let’s Encrypt.
A familiar scenario: a team moves a zone of roughly 340 records from a registrar’s bundled DNS to AWS Route 53. The web records are checked carefully and the site stays up. Nobody checks the two SendGrid CNAMEs at s1._domainkey and s2._domainkey because they were added years ago by a contractor. Transactional email starts failing DKIM, DMARC at p=reject drops it, and the support queue fills up before anyone connects it to the migration.
The zone you can see in the dashboard is rarely the whole picture. Treat the migration as an inventory project first and a DNS change second.
Debunking the 48-Hour Propagation Myth
“DNS takes up to 48 hours to propagate” is repeated everywhere, and it’s misleading. DNS doesn’t propagate. Resolvers cache answers for as long as the TTL allows, then ask again.
There are two TTLs that matter. The first is the TTL on your own records, which you control. The second is the TTL on the NS delegation in the parent zone – for .com and .net, Verisign publishes NS records with a TTL of 172800 seconds, or 48 hours. That is where the folklore comes from. You can’t shorten the parent’s TTL, but it doesn’t matter as long as both the old and new providers serve the same data during that window. For the details on caching behavior, see how TTL settings affect caching.
Step-by-Step DNS Provider Migration Plan
An experienced DNS administrator works through the migration in a fixed order and doesn’t skip ahead.
Step 1 – Build a complete inventory. Export the zone using whatever the old provider offers: a BIND zone file from Cloudflare, AXFR if your provider allows it, or the API (Route 53 doesn’t support outbound AXFR, so use the AWS CLI or a tool like octoDNS or DNSControl). Compare the export against passive DNS data and certificate transparency logs, so you catch subdomains the export misses or that live in delegated child zones.
Step 2 – Take a baseline snapshot. Before changing anything, run dig against every name and type from the old authoritative servers and save the output. That file becomes your reference for comparing later. The same approach powers baseline snapshots for detecting unauthorized changes.
Step 3 – Lower TTLs early. At least 48 hours before cutover, drop TTLs on critical records to 300 seconds. Then wait out the old TTL in full. If MX records had a TTL of 86400, lowering it an hour before cutover does nothing.
Step 4 – Build and verify the new zone. Import the records, then query the new provider’s nameservers directly (dig @ns-123.awsdns-15.com example.com TXT) and diff the results against the baseline. Proprietary record types need to be rebuilt by hand. Route 53 ALIAS records, Cloudflare CNAME flattening at the apex and NS1 filter chains don’t export cleanly.
Step 5 – Handle DNSSEC before touching NS records. If the zone is signed, you have two options. You can use a multi-signer setup as described in RFC 8901, where both providers’ DNSKEYs are published. Or you can remove the DS record at the registrar, wait for the DS TTL to expire (86400 seconds for .com), migrate, then re-sign and publish the new DS. Skip this step and validating resolvers such as Google Public DNS and Quad9 will return SERVFAIL for the whole domain.
Step 6 – Update the delegation. Change the NS records at the registrar. Also update the apex NS records inside both zones so they list the new nameservers. Otherwise resolvers still talking to the old provider get pointed back to it.
Step 7 – Run both providers in parallel. Keep the old zone live and unchanged for at least 7 days. Freeze record changes during this window, or apply every change to both providers.
Step 8 – Decommission carefully. Raise TTLs back to normal values (3600 or more), confirm that no traffic reaches the old nameservers, and only then delete the old zone.
Common Mistakes During Provider Cutover
Changing registrar and DNS provider on the same day. A registrar transfer locks the domain for 60 days under ICANN policy and can reset nameserver settings. Do the two moves separately, and make sure you have a tested rollback procedure for a bad DNS change before either one.
Trusting the import summary. “Imported 338 of 340 records” is easy to skim past. The two that failed are often long TXT records split into multiple strings, such as 2048-bit DKIM keys, or SPF records with unusual escaping. Verify by querying the new nameservers, not by reading the provider’s import report.
Leaving delegated subdomains dangling. If dev.example.com is delegated to a separate zone at the old provider, and that zone is deleted while the NS records remain, anyone who can create that zone on the same provider may take control of the subdomain. Several managed DNS platforms have been exploited this way. Delete the delegation before you delete the zone.
Edge Cases Where Standard Advice Breaks
Split-horizon setups are the most common exception. If internal BIND or Active Directory DNS serves a different view of the same zone, the public migration doesn’t touch it, but conditional forwarders that point to the old provider’s IPs will break. Air-gapped or on-prem environments that use hardcoded resolver IPs need their own change ticket.
Small teams with fewer than 20 records can often skip tooling such as octoDNS and verify by hand in an afternoon. Regulated environments – PCI DSS, or financial services under DORA since January 2025 – usually need documented change approval and evidence of verification. Plan for the paperwork to take longer than the migration itself.
FAQ
How long should the old DNS provider stay active after migration?
Keep it running for at least 7 days, and 14 if your zone has long TTLs or you serve resolvers that are known to ignore TTLs. The cost of one extra month on the old plan is trivial compared to a partial outage.
Will email be interrupted during a DNS provider migration?
Not if the MX, SPF, DKIM and DMARC records are identical on both providers before the NS change. Sending servers retry for up to 4-5 days anyway, so a brief resolution error rarely loses mail. A missing DKIM selector, however, causes rejections rather than retries.
Can DNSSEC stay enabled throughout the migration?
Yes, but only with a multi-signer configuration that both providers support. Otherwise, going unsigned for 2-3 days is the safer and more common approach.
Final Checklist Before Flipping Nameservers
A zero-downtime migration comes down to one principle: both providers must give identical answers for as long as any resolver might ask either one. Inventory everything, including records nobody remembers adding. Lower TTLs well in advance, sort out DNSSEC first, and diff the new zone against a saved baseline. Then keep the old provider running longer than feels necessary.
One last tip: after cutover, rerun the full baseline comparison against public resolvers – 8.8.8.8, 1.1.1.1 and 9.9.9.9 – rather than only against your new nameservers. That’s the view your users and mail servers actually see.