How to Plan a Zero-Downtime DNS Migration?

Changing DNS providers is one of those tasks that looks trivial — copy some records, update the nameservers, done — right up until a missing DKIM record sends a week of invoices to spam, or a forgotten DNSSEC DS record makes the whole domain vanish for every validating resolver. The good news is that a DNS migration can be done with zero user-visible downtime, because DNS is designed to let old and new servers coexist. The trick is that "zero downtime" is a result of planning, not of the cutover itself. If you need the basic mechanics of moving a zone first, read how to transfer DNS management to another provider; this article goes deeper on the planning, verification, and timing that make the move invisible.

You will build a complete migration runbook: a reliable record inventory, a TTL timeline, an automated script that proves the new provider answers identically, a safe approach to DNSSEC, the cutover itself, monitoring, and a rollback plan.

Why DNS Migrations Can Be Zero-Downtime

When you change nameservers at the registrar, the internet does not switch over all at once. Resolvers that have the old NS records cached keep asking the old provider until those records expire, while resolvers that look the domain up fresh go to the new provider. For a period that can last up to two days, both providers are answering real traffic.

That overlap is the key to everything. If both providers return the same answers throughout the overlap, it does not matter which one a given resolver uses, and users notice nothing. Every step in this plan exists to guarantee that sameness — and to shorten the window in which anything could differ. Understanding DNS propagation delay helps here: there is no push, only caches expiring.

Phase 1: Build a Complete Inventory

You cannot verify what you have not listed. Get an authoritative copy of the current zone rather than reconstructing it from memory.

Try a zone transfer. Some providers allow AXFR to authorized IPs, and self-hosted servers usually can:

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

If the transfer is refused (most managed providers refuse it by default), use the provider's zone export feature, which usually produces a BIND-format file, or its API.

Do not rely on guessing names. Querying common names like www, mail, and api with dig will miss records such as _dmarc, DKIM selectors like s1._domainkey, _acme-challenge, SRV records like _sip._tls, and verification TXT records for SaaS tools. DNS does not provide a way to list all names in a zone from the outside, which is precisely why the export matters.

Once you have the file, review it for the record types that commonly cause trouble:

Record type	Why it needs attention
Long TXT records (DKIM)	Strings over 255 characters must be split; some import tools mangle them
ALIAS / ANAME / flattened apex	Provider-specific; the new provider may implement it differently or not at all
Proxied or "orange cloud" records	Exports contain origin IPs, but the old provider was answering with its own proxy IPs
Wildcards	Easy to miss and easy to import with the wrong scope
CAA	Missing or changed CAA can block certificate renewals
NS records for delegated subdomains	Delegations like dev.example.com must be recreated or that subdomain disappears
Geo, weighted, or failover records	Routing policies rarely export; rebuild them by hand

Also list everything that depends on DNS but lives outside the zone: email providers, SSL automation using the DNS-01 challenge, monitoring checks, and any API credentials your deploy scripts use to edit records at the old provider. Those scripts will silently keep editing the old zone after cutover unless you update them. Email is the most fragile dependency; how changing DNS affects email services covers what to double-check.

Phase 2: Build the Zone at the New Provider

Import the zone file or recreate records through the new provider's API. Then fix provider-specific records by hand: rebuild apex aliases using the new provider's equivalent, decide whether proxied records should point at origin IPs or a new CDN, and recreate any routing policies.

Do not change the nameservers yet. At this stage, the new provider is serving your zone, but nobody on the internet is asking it.

Phase 3: Verify Record by Record

This is the step that separates a smooth migration from a stressful one. Query the old and new providers directly and compare every answer. The following Python script uses dnspython (pip install dnspython) and a simple list of names and types taken from your inventory:

import dns.exception
import dns.resolver

OLD_NS = "198.51.100.10"   # IP of an old provider nameserver
NEW_NS = "192.0.2.20"      # IP of a new provider nameserver

RECORDS = [
    ("example.com", "A"),
    ("example.com", "AAAA"),
    ("example.com", "MX"),
    ("example.com", "TXT"),
    ("example.com", "CAA"),
    ("www.example.com", "CNAME"),
    ("_dmarc.example.com", "TXT"),
    ("s1._domainkey.example.com", "TXT"),
    ("_sip._tls.example.com", "SRV"),
]


def query(server, name, rtype):
    resolver = dns.resolver.Resolver(configure=False)
    resolver.nameservers = [server]
    resolver.lifetime = 5
    try:
        answer = resolver.resolve(name, rtype)
        return sorted(rdata.to_text() for rdata in answer)
    except dns.resolver.NXDOMAIN:
        return ["NXDOMAIN"]
    except dns.resolver.NoAnswer:
        return ["NOANSWER"]
    except dns.exception.Timeout:
        return ["TIMEOUT"]


mismatches = 0
for name, rtype in RECORDS:
    old = query(OLD_NS, name, rtype)
    new = query(NEW_NS, name, rtype)
    status = "OK  " if old == new else "DIFF"
    if old != new:
        mismatches += 1
    print(f"{status} {rtype:6} {name}")
    if old != new:
        print(f"     old: {old}")
        print(f"     new: {new}")

print(f"\n{mismatches} mismatch(es) found")

The script asks each provider's nameserver directly, normalises the answers by sorting them, and prints any record where the two differ. Find the nameserver IPs with dig +short ns1.new-provider.net. Run it until it reports zero mismatches, and expect a few legitimate differences, such as apex records that the old provider returned as proxy IPs. Investigate each one rather than waving it through.

If you prefer the shell, a quick spot check works the same way:

for name in example.com www.example.com _dmarc.example.com; do
  for type in A AAAA CNAME MX TXT; do
    old=$(dig @ns1.old-provider.net "$name" "$type" +short | sort)
    new=$(dig @ns1.new-provider.net "$name" "$type" +short | sort)
    [ "$old" != "$new" ] && echo "DIFF $type $name"
  done
done

Only differing records are printed, so silence means the sampled records match.

Phase 4: Lower TTLs Ahead of Time

TTLs decide how long caches hold the old answers, so they decide how long your overlap window lasts. There are two different TTLs to think about.

1. Record TTLs inside your zone. If you are also changing any record values (for example moving to a new CDN at the same time), lower those records' TTLs at the old provider to 300 seconds at least one full old-TTL period before the change. A record with an 86400-second TTL needs at least a day of notice. Mirror the low TTLs at the new provider.
2. NS record TTLs. The NS records that matter most are the delegation records at the TLD, and those TTLs are set by the registry, not by you. For .com and .net they are 172800 seconds (two days). You cannot shorten this, which is why the old provider must keep serving the zone for at least two days after cutover. The NS TTL inside your own zone at the old provider also matters for resolvers that prefer child-side data; lowering it there a couple of days ahead is a cheap extra step.

If no record values are changing — you are only moving providers — the record TTLs matter less, because both providers return identical data. The NS timing is what you plan around. The post on what a TTL is in DNS has more on how caches count down.

Phase 5: Handle DNSSEC Carefully

If the domain is signed with DNSSEC, this is the step most likely to cause a real outage. The DS record at the registry points at the old provider's signing key. If you switch nameservers to a provider that signs with different keys, validating resolvers see signatures that do not match the DS record and return SERVFAIL for the whole domain.

There are two safe approaches:

• Go insecure temporarily (simplest). Remove the DS record at the registrar, then wait at least the DS record's TTL (often one or two days) plus a margin so no resolver still expects signatures. Migrate as an unsigned zone. Once the new provider is serving all traffic, enable signing there and publish its DS record.
• Multi-signer migration (no insecure window). Some providers support the multi-signer model from RFC 8901, where each provider's keys are published in both zones and the DS set covers both. This keeps the domain validated throughout but requires both providers to support importing each other's DNSKEY records.

Check the current state before deciding:

dig example.com DS +short
dig @ns1.new-provider.net example.com DNSKEY +short

If the first command returns nothing, the domain is unsigned and you can skip this phase.

Phase 6: Cut Over

With records verified, TTLs adjusted, and DNSSEC handled:

• Freeze changes. Announce a change freeze on the zone from now until the end of the overlap. If a change is unavoidable, make it at both providers.
• Update the nameservers at the registrar to the new provider's set. Replace all of them in one change rather than mixing old and new nameservers, unless both providers are deliberately kept in sync as a multi-provider setup.
• Confirm the registry has the new delegation. Ask a TLD server directly rather than a resolver, which may be serving cached data:

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

The authority section should list the new nameservers within minutes of the registrar change for most gTLDs. Some ccTLDs update on a schedule, so it may take longer.

• Leave the old zone exactly as it is. Do not delete it, do not cancel the account. It is still answering a share of the world's queries.

Phase 7: Monitor the Overlap

Track which nameservers popular public resolvers are seeing and whether answers remain consistent:

for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
  echo "$r: $(dig @"$r" example.com NS +short | sort | tr '\n' ' ')"
done

Over the next 48 hours the old nameservers disappear from the results as caches expire. Meanwhile, watch the things users actually experience: website uptime checks, email delivery (send test messages to Gmail and Outlook addresses and check authentication headers), certificate renewals, and any API integrations. Online tools for checking DNS propagation give a quick global view.

Re-run the comparison script against the new provider at the end of the overlap as a final check.

Rollback Plan

Because the old zone is still intact, rolling back is just reverting the nameservers at the registrar. Write down, before you start:

• The exact old nameserver hostnames.
• Who has registrar access and how to reach them during the cutover window.
• The conditions that trigger rollback, such as email authentication failures or SERVFAIL responses from validating resolvers.

Rolling back faces the same caching rules as rolling forward, so resolvers that already moved will keep using the new provider for up to two days. That is another reason the two zones must stay identical: a rollback only helps if the old zone is still correct.

Decommission the Old Provider

Only after the overlap has fully passed — at least the TLD NS TTL plus a day of margin, and with monitoring showing no traffic issues — should you clean up:

1. Delete or disable the zone at the old provider.
2. Revoke API keys that pointed at the old provider and confirm automation now targets the new one.
3. Restore normal TTLs on any records you lowered.
4. If you went insecure for DNSSEC, enable signing at the new provider and publish the new DS record.

Deleting the old zone too early is a common cause of "partial outages" that only affect users behind certain resolvers. Leaving it a week costs nothing.

---

DNS Migration FAQ

Conclusion

A zero-downtime DNS migration is less about the moment you click "save" at the registrar and more about everything you do before and after it. Get a real export of the zone, rebuild provider-specific records deliberately, and prove with a script that the old and new providers return identical answers. Plan around the registry's NS TTL rather than hoping it is short, take DNSSEC off the table or handle it with a multi-signer approach, and keep the old zone untouched until the overlap has fully expired.

Treat it as a runbook with checkpoints and a written rollback plan, and the migration becomes routine. Users never notice, email keeps flowing, certificates keep renewing, and the only evidence that anything happened is a different set of nameservers in your dig output.

Here are some useful references for planning a DNS migration:

1. RFC 8901: Multi-Signer DNSSEC Models — how two providers can sign the same zone during a migration without an insecure window.
2. RFC 1034: Domain Names - Concepts and Facilities — the caching and delegation behaviour that makes overlapping providers possible.
3. dnspython Documentation: dnspython manual — reference for the resolver API used in the verification script.
4. Cloudflare Learning Center: What is DNSSEC? — background on DS and DNSKEY records and why mismatches break resolution.
5. AWS Documentation: Migrating DNS service for an existing domain to Amazon Route 53 — one provider's step-by-step migration checklist, useful as a cross-reference.