How to move your DNS hosting without downtime?

To move your DNS hosting without downtime, recreate every record from your current zone at the new provider before you touch the nameservers, then query the new provider's nameservers directly to confirm they return identical answers. Only then update the nameservers at your registrar, keep the old zone running unchanged for at least a few days while resolvers switch over, and deal with DNSSEC in the right order so validation never breaks. Because both providers serve the same answers during the changeover, it doesn't matter which one a visitor's resolver happens to ask.

Most DNS migration outages aren't caused by the switch itself. They come from a forgotten record, such as a DKIM key or a verification TXT record, an old zone deleted too early, or a DS record left pointing at keys that no longer exist. This guide walks through a migration plan that avoids all three: taking a full inventory, building the new zone, checking it record by record, cutting over, monitoring and finally decommissioning the old provider.

Why DNS Migrations Can Cause Downtime

When you change nameservers, the change happens at your domain's parent zone, for example the .com registry. Recursive resolvers around the world have cached the old NS records, often for up to 48 hours, because the .com and .net registries publish delegation NS records with a TTL of 172,800 seconds. During that window, some resolvers ask your old provider and some ask the new one.

That overlap is completely safe if both providers give the same answers. It goes wrong when:

• The new zone is incomplete: Resolvers that have switched get NXDOMAIN or empty answers for missing records.
• The old zone is deleted too soon: Resolvers still using the cached delegation get REFUSED or SERVFAIL from the old provider.
• Records change mid-migration: You edit a record at one provider but not the other, so visitors see different results depending on which provider they hit.
• DNSSEC doesn't match: The parent zone's DS record points at the old provider's keys, so validating resolvers reject the new provider's signed answers.

The whole plan below is about removing each of those risks.

Step 1: Take a Complete Inventory of Your Current Zone

You can't reliably discover every record in a zone by querying it from outside. DNS has no "list everything" query for normal clients, and the old ANY query type is now answered minimally by most providers. You need an export from the provider itself.

Export From Your Current Provider

Most providers have an export option in the dashboard that produces a BIND-style zone file. Others offer it only through their API or CLI. A few examples:

# Cloudflare: export a BIND zone file via the API
curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/export" \
  -H "Authorization: Bearer $CF_API_TOKEN" > example.com.zone

# Google Cloud DNS
gcloud dns record-sets export example.com.zone \
  --zone=example-com --zone-file-format

# Azure DNS
az network dns zone export -g my-resource-group -n example.com -f example.com.zone

# Amazon Route 53 (JSON, not BIND format)
aws route53 list-resource-record-sets --hosted-zone-id Z0123456789ABCDEFGHIJ > example.com.json

If your current provider runs BIND or another server that allows zone transfers from your IP, you can also pull the zone with AXFR:

dig @ns1.old-provider.example AXFR example.com > example.com.zone

Most managed providers block AXFR by default, so don't be surprised if it fails.

Check for Records the Export Might Miss

Exports usually include every standard record, but some provider features don't appear as normal records:

• Proxied or "flattened" records: Cloudflare proxied records and ALIAS/ANAME records at other providers may export as plain A records or as a provider-specific type.
• URL redirects and forwarding: Registrar "URL forwarding" or "web redirect" features aren't DNS records at all. They're a web server run by the provider, and they stop working when you move.
• Email forwarding: Registrar-provided email forwarding relies on their MX records and their mail servers.
• Dynamic or health-checked records: Failover, geo-routing and weighted records often export as a single static value.

Write these down separately, because you'll need to rebuild them with a different mechanism at the new provider.

Cross-Check the Records You Care About Most

Even with an export, it's worth querying the critical names yourself so you have a baseline to compare against later:

for name in example.com www.example.com mail.example.com; do
  for type in A AAAA CNAME MX TXT; do
    dig +noall +answer "$name" "$type"
  done
done
dig +noall +answer _dmarc.example.com TXT
dig +noall +answer google._domainkey.example.com TXT

Pay special attention to DKIM selectors, which live at names like selector1._domainkey. They're easy to overlook because you can't guess the selector names without knowing which email services you use.

Step 2: Build the Zone at the New Provider

Create the zone at the new provider and import your records. Most providers accept a BIND zone file upload, which saves a lot of manual work and reduces typing errors.

Before importing, clean the file up:

1. Remove the old SOA and NS records: The new provider generates its own. Importing the old NS records at the apex can confuse things.
2. Remove provider-specific records: Lines such as Cloudflare's cf-proxied comments or vendor-only record types won't import elsewhere.
3. Check for relative names: Make sure names are either fully qualified with a trailing dot (mail.example.com.) or correctly relative to the $ORIGIN.
4. Keep the same TTLs for now, unless you've already lowered them as part of a wider migration.

A tidy zone file ready for import looks something like this:

$ORIGIN example.com.
$TTL 3600
@               IN  A      192.0.2.10
@               IN  AAAA   2001:db8::10
www             IN  CNAME  example.com.
@               IN  MX     10 mx1.mail.example.net.
@               IN  MX     20 mx2.mail.example.net.
@               IN  TXT    "v=spf1 include:_spf.mail.example.net -all"
_dmarc          IN  TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
s1._domainkey   IN  CNAME  s1.dkim.mail.example.net.
api             IN  A      198.51.100.20

You can validate the syntax locally with named-checkzone, which ships with BIND's utilities:

named-checkzone example.com example.com.zone

zone example.com/IN: loaded serial 0
OK

Note that named-checkzone will warn if the file has no SOA or NS records. That's fine for an import file, but you can add a temporary SOA and NS pair if you want a clean check.

Step 3: Verify the New Nameservers Directly

This is the most important step and the one people skip. Your new provider is already serving the zone on its nameservers, even though the world isn't using them yet. You can query them directly with dig @server to see exactly what resolvers will get after the switch.

dig @ns1.new-provider.example example.com A +short
dig @ns1.new-provider.example www.example.com CNAME +short
dig @ns1.new-provider.example example.com MX +short

Compare Old and New Automatically

Checking records one at a time is slow and error-prone. A small script that queries both providers for a list of names and types makes differences obvious:

#!/usr/bin/env bash
# compare-dns.sh - compare answers from old and new nameservers
OLD=ns1.old-provider.example
NEW=ns1.new-provider.example
NAMES="example.com www.example.com api.example.com mail.example.com _dmarc.example.com s1._domainkey.example.com"
TYPES="A AAAA CNAME MX TXT CAA SRV"

for name in $NAMES; do
  for type in $TYPES; do
    old=$(dig @"$OLD" +short "$name" "$type" | sort)
    new=$(dig @"$NEW" +short "$name" "$type" | sort)
    if [ "$old" != "$new" ]; then
      echo "MISMATCH $name $type"
      echo "  old: $old"
      echo "  new: $new"
    fi
  done
done
echo "Comparison complete."

chmod +x compare-dns.sh
./compare-dns.sh

MISMATCH s1._domainkey.example.com CNAME
  old: s1.dkim.mail.example.net.
  new:
Comparison complete.

A mismatch like that is exactly what you want to catch now, rather than after customers' emails start failing DKIM checks. Fix it at the new provider and run the script again until it prints nothing but the final line.

If you have a full zone export, you can generate the list of names from the file rather than typing them out, so every record gets compared.

Expected Differences

A few differences are normal:

• SOA records: Each provider has its own primary nameserver, contact and serial.
• NS records at the apex: The new provider returns its own nameservers.
• Flattened or proxied apex records: If the old provider flattened a CNAME at the apex, the IP addresses returned may differ from the new provider's flattened result, while still reaching the same service.
• Round-robin ordering: That's why the script sorts the output.

Step 4: Handle DNSSEC Before You Switch

If your domain doesn't use DNSSEC, skip this step. If it does, this is where migrations most often break.

Check whether a DS record exists at the parent:

dig example.com DS +short

2371 13 2 1F987CC6583E92DF0890718C42C4D1B4D7D7F1E3A2C1B9E8D7C6B5A4F3E2D1C0

If you see output, the parent zone vouches for your old provider's key. When resolvers start asking the new provider, its answers will be signed with a different key (or not signed at all), and validating resolvers will return SERVFAIL.

You have two safe options:

Option A: Go Insecure Temporarily

This is the simplest approach and works with every provider:

1. Remove the DS record at your registrar.
2. Wait for the DS record's TTL to expire at resolvers. For .com that's typically up to a day; check the TTL with dig example.com DS against a public resolver.
3. Confirm dig example.com DS +short returns nothing.
4. Switch nameservers (Step 5).
5. Once the new provider is serving everyone, enable DNSSEC there and add its new DS record at the registrar.

Your domain is unsigned for a short time, but it never fails to resolve.

Option B: Multi-Signer Migration

Some providers support a multi-signer setup, where both providers' keys are published in each other's DNSKEY sets during the transition, so either provider's answers validate. It avoids the unsigned window but requires both providers to let you add foreign DNSKEY records. If your providers don't explicitly document support for this, use Option A.

Step 5: Change the Nameservers at Your Registrar

With the new zone verified and DNSSEC sorted, log in to your registrar and replace the old nameservers with the new provider's. Enter them exactly as given and include every one, usually between two and four hostnames.

Freeze record changes from this point. If something absolutely has to change during the migration window, make the identical change at both providers.

You can confirm the registry has accepted the change by asking a TLD server directly, which bypasses resolver caches:

dig @a.gtld-servers.net example.com NS +norecurse

;; AUTHORITY SECTION:
example.com.		172800	IN	NS	ns1.new-provider.example.
example.com.		172800	IN	NS	ns2.new-provider.example.

The TTL of 172800 seconds in the output shows why resolvers can keep using the old delegation for up to two days. You can't shorten it, because the registry controls that TTL, not you.

Step 6: Monitor the Changeover

For the next couple of days, check that public resolvers are moving over and that everything still resolves.

for r in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
  echo "== $r"
  dig @"$r" example.com NS +short
  dig @"$r" www.example.com A +short
done

At the same time, keep an eye on the things that would fail quietly:

• Email delivery: Send test messages to and from external accounts, and check that DKIM and SPF still pass in the message headers.
• Certificate renewals: If a certificate is due to renew, make sure the validation method still works. DNS-01 challenges in particular depend on API credentials for the new provider.
• Automation: Scripts, dynamic DNS clients, ACME clients and Terraform state that talk to the old provider's API need updating, or they'll keep changing a zone nobody reads.
• Monitoring and uptime checks: Make sure alerts are still firing from the right places.

Step 7: Decommission the Old Provider

Wait at least as long as the parent's NS TTL plus a safety margin before you delete the old zone. A week is a comfortable rule for most domains. Some badly behaved resolvers cache longer than they should, and there's no benefit to rushing.

Before deleting, check the old provider's query statistics if it offers them. When queries have dropped to almost nothing, it's safe to remove the zone. If you're on a paid plan, cancel it only after the zone has been removed.

A Migration Checklist

Stage	Task	Done when
Inventory	Export full zone, note redirects and forwarding	You have a file with every record
Build	Import into new provider, rebuild special features	New zone mirrors the old one
Verify	Compare old and new nameservers name by name	Comparison script shows no mismatches
DNSSEC	Remove DS or set up multi-signer	dig DS shows the right state
Switch	Update nameservers at registrar	TLD servers return new NS
Monitor	Check resolvers, email, certificates, automation	All public resolvers show new NS
Clean up	Delete old zone, re-enable DNSSEC, cancel plan	Old provider receives no queries

Common Mistakes to Avoid

1. Relying on online lookup tools for the inventory: They only see the names they guess. Always export from the provider.
2. Forgetting registrar extras: URL forwarding and email forwarding disappear the moment you change nameservers.
3. Deleting the old zone the same day: This is the classic cause of "it works for me but not for some customers" outages.
4. Leaving a DS record in place: It turns a routine migration into a full outage for users of validating resolvers.
5. Editing only one provider during the overlap: Visitors get inconsistent answers that are hard to debug.
6. Ignoring CAA records: If your old zone had a CAA record, copy it, or your certificate authority may refuse to issue renewals. If the new provider needs to issue certificates for you, make sure its CA is allowed.

---

FAQ: Moving DNS Hosting

---

Conclusion

A DNS migration without downtime comes down to one principle: make the new provider an exact copy of the old one before the world starts using it, and keep the old one alive until the world has finished moving. Export the full zone, rebuild it, compare the two providers directly with dig, and only then change the nameservers.

Handle DNSSEC first, freeze changes during the overlap, and watch the quiet failures such as email authentication, certificate renewals and automation that still points at the old API. Give the old zone a week before you delete it, and your visitors will never know anything changed.