Moving DNS Providers Without Downtime

Plan the move before you touch anything

Start with an inventory. Write down every name server currently delegated for the zone, which records exist, which systems update records automatically (ACME certificate clients, Kubernetes external-dns, dynamic DNS clients, CI pipelines), and which provider-specific features you rely on. Apex aliasing (often called ALIAS, ANAME, or CNAME flattening), geographic routing, health-checked failover, and weighted records are not standard record types. They will not survive a plain zone file export, so each one needs a deliberate equivalent at the new provider. If you need a refresher on why these exist, see CNAME at the Apex: ALIAS and Flattening.

Also decide on a change freeze. Between copying the zone and finishing the cutover, any edit must be made at both providers. A short freeze, or a single source of truth such as an infrastructure-as-code repository that pushes to both, removes a whole class of mistakes.

Step 1: Lower TTLs ahead of time

The TTL on a record is how long a resolver may reuse it. If your A records carry a TTL of 86400 seconds, a resolver that fetched them just before your change can keep serving the old answer for a full day. Lower the TTLs on records that might change during the move, typically to 300 seconds, and then wait at least as long as the old TTL so that every cached copy has expired. Lowering a TTL only helps after the old, longer TTL has run out. DNS TTLs and Caching Explained covers the mechanics in more depth.

Two TTLs are easy to miss. The first is the NS record set inside your own zone, which many providers publish with a long default. Lower it too. The second is the delegation in the parent zone, which you do not control. The .com and .net registries publish delegation NS records with a TTL of 172800 seconds (two days), so some resolvers will keep asking your old name servers for up to two days after you change the delegation, no matter what you do. That is the main reason the old provider has to stay up.

If the zone is signed, note the TTL of the DS record at the parent as well. You will need it in Step 4.

Step 2: Copy the zone to the new provider

Get the most complete export you can. Many providers offer a BIND-format zone file download. Some allow a zone transfer (AXFR, defined in RFC 5936, DNS Zone Transfer Protocol) to an address you allow-list, and some new providers can pull the zone from the old one directly. If you only have an API or a web console, script the export rather than copying records by hand.

When you import, leave out the apex SOA and NS records from the old provider. The new provider creates its own SOA and its own NS set, and importing the old ones can leave the new zone pointing at the old servers. Then rebuild every provider-specific record by hand: aliases at the apex, geo or latency policies, and health checks. Finally, make sure automated writers (certificate clients, dynamic DNS) are either pointed at the new provider or paused.

Before anything is live, query the new provider's name servers directly. They will answer authoritatively for your zone even though the world is not using them yet. Compare against the old servers:

$ dig +norec +noall +answer @ns1.old-dns.example.net www.example.com A
www.example.com.        300     IN      A       203.0.113.10

$ dig +norec +noall +answer @ns1.new-dns.example.net www.example.com A
www.example.com.        300     IN      A       203.0.113.10

$ dig +norec +noall +answer @ns1.new-dns.example.net example.com MX
example.com.            300     IN      MX      10 mail.example.com.

Repeat for every name and type that matters: apex A and AAAA, www, MX, the SPF and verification TXT records, DKIM selectors, _dmarc, SRV, CAA, and any CNAMEs to third-party services.

Step 3: Compare old and new side by side

Spot checks catch the obvious records, but a zone with hundreds of entries needs a systematic comparison. Export the zone from both providers in BIND format and review them together. Zone Analyzer parses BIND-style exports locally in your browser, so you can load each export, filter by record type or hostname, and export the filtered rows as CSV. Diffing the two CSV files (or the two zone files, after sorting) shows records that are missing, duplicated, or have different values. Expect harmless differences in SOA serials, NS records, and TTLs. Everything else should match.

Pay special attention to TXT records with long values. Some providers split strings longer than 255 characters differently, and some web consoles silently strip or add quotes. A DKIM key that was split into two strings by one provider and mangled by the other will break email signing without any visible error in a web browser.

Step 4: Hand over DNSSEC safely

If the zone is not signed, skip this step. If it is, this is where migrations fail. The parent zone publishes a DS record that points at your current key-signing key. If you switch name servers and the new provider signs with different keys, validating resolvers will find signatures that do not match the DS record and will return SERVFAIL. For those users, your domain is simply gone. There are two safe ways through.

Option A: multi-signer handover

RFC 8901, Multi-Signer DNSSEC Models describes how two providers can both sign the same zone during the move. In its second model, which most managed providers use, each provider keeps its own key-signing key, publishes the other's zone-signing key in its DNSKEY set, and the parent carries DS records for both key-signing keys. In its first model the providers share one key-signing key and only exchange zone-signing keys, so the DS does not change. Once that is in place, an answer from either provider validates, so the NS change becomes as safe as it would be for an unsigned zone. After the move, you remove the old provider's keys and DS record. This option needs both providers to support importing external DNSKEY records, which not all do.

A simpler variant exists when the providers allow it: export the signing keys from the old provider and import them into the new one, so the new provider signs with keys the existing DS already covers. Check both providers' documentation; many managed services do not let you export or import private keys.

Option B: go unsigned, move, then re-sign

If none of these is supported, remove the DS record at your registrar first. Wait until the old DS record has expired from caches, which means at least its TTL (check it with dig example.com DS) plus a safety margin. Only then is the zone treated as unsigned everywhere, and you can move it. After the cutover has settled, enable signing at the new provider, publish the new DS record at the registrar, and verify validation. The zone is unprotected by DNSSEC for a while, which is a real trade-off, but it does not cause an outage. DNSSEC Key Rollovers (ZSK and KSK) explains why the timing rules exist.

What you must not do is change name servers while the old DS record is still published and the new provider is signing with keys that DS does not cover.

Step 5: Swap the NS records, monitor, then raise TTLs

With identical data on both providers and DNSSEC handled, change the name servers at your registrar to the new provider's set. Do not mix old and new name servers in the delegation unless both are serving identical, validating data, because resolvers pick among listed servers. If you use vanity name servers under your own domain (for example ns1.example.com), update the glue records as well; DNS Delegation and Glue Records explains when glue is needed.

Confirm what the parent now publishes by asking a TLD server directly rather than your local resolver:

$ dig +norec +noall +authority @a.gtld-servers.net example.com NS
example.com.            172800  IN      NS      ns1.new-dns.example.net.
example.com.            172800  IN      NS      ns2.new-dns.example.net.

Now monitor. Query traffic on the old provider should fall steadily over the next one to two days as delegation caches expire, and traffic on the new provider should rise. Check resolution from several public resolvers and networks, because each has its own cache. Watch for SERVFAIL rates, mail delivery, and certificate renewals. Keep the old zone unchanged and active during this window; if you must edit a record, edit it in both places.

When the old provider is receiving close to zero queries and at least the parent NS TTL plus your old NS TTL has passed, raise the TTLs at the new provider back to normal values, then remove the zone from the old provider. If you removed DNSSEC in Step 4, re-sign now. Old resolver caches are the reason DNS Propagation Myths exist, so a little patience at this stage saves a lot of confusion.

How DNS Panopticon helps

Use Zone Analyzer before the cutover to review each provider's export, filter it down to the record types you care about, export CSV for a diff, and run HTTP status or screenshot checks on selected web-facing names. Its parsing happens in your browser, so the zone file itself is not uploaded.

After the NS change, run Domain Visualizer to scan the live public DNS for the domain. It displays records and their graph; use Security Posture for delegation, DNSSEC, mail and web remediation findings. Visualizer has a separate application cache: scans are cached for 24 hours by default, and the administrator can configure that lifetime from one minute to seven days. A DNS record’s TTL expiring does not expire the saved scan. For a post-migration check, wait for the configured scan cache to expire or ask an administrator to purge the cached scan before rescanning. Query the authoritative name servers directly when you need to verify a change immediately. Website Recon matches the domain's name servers against its provider catalog, so it is a quick way to confirm which DNS provider the public delegation now points at.