DNS Migrations

The hardest part is that you can’t see who’s cached what

DNS migrations — changing authoritative DNS providers, moving zones between servers, or restructuring your DNS architecture — are conceptually simple but operationally treacherous. The challenge is the cache. You control your authoritative servers, but you do not control the thousands of recursive resolvers worldwide that have cached your records. A migration must work correctly for resolvers holding old data, resolvers holding new data, and resolvers in the process of transitioning.

A botched DNS migration doesn’t produce error messages. It produces unreachable services, bouncing email, broken SSL certificates, and customer support tickets from users who “can’t get to the site” — while everything looks fine from your desk.

The TTL preparation rule

The single most important migration technique: lower your TTLs before making changes.

Every DNS record has a TTL that tells resolvers how long to cache it. If your NS records have a TTL of 86,400 seconds (24 hours), it could take up to 24 hours after you change providers for all resolvers to pick up the new nameservers. During that window, some users reach the old provider and some reach the new one.

The preparation sequence:

1. 48 hours before migration: Lower the TTL on all records you plan to change to 300 seconds (5 minutes). This includes NS records, A records, MX records — everything.

2. Wait for the old TTL to expire. If the original TTL was 86,400 seconds, you must wait at least 86,400 seconds (24 hours) after lowering it. Only then can you be confident that no resolver still has the old, high-TTL version cached.

3. Make the change. Now when you switch providers, resolvers will re-query within 5 minutes.

4. After the migration is stable: Raise TTLs back to their operational values.

Skipping step 2 is the most common migration mistake. Lowering a TTL only takes effect once the previously cached record with the old TTL expires. If you lower the TTL and immediately make changes, resolvers that cached the record an hour ago will still hold it for the remainder of the original TTL.

Provider migration playbook

Changing from one managed DNS provider to another is the most common migration scenario. The goal is zero downtime — both providers serve correct answers throughout the transition.

Phase 1: Parallel setup

Set up the new provider with an exact copy of your zone data. Every record on the old provider must exist on the new provider with identical values. Verify by querying the new provider’s nameservers directly:

dig @ns1.newprovider.com example.com A
dig @ns1.newprovider.com example.com MX
dig @ns1.newprovider.com example.com TXT

Compare every response against the old provider. Automated tools like dnscontrol or OctoDNS can diff zone data between providers and flag discrepancies.

Phase 2: Lower TTLs

On the old provider, lower TTLs on all records to 300 seconds. Critically, also lower the TTL on your NS records — these control how long resolvers cache the delegation to your current nameservers.

Note: The NS record TTL at the registrar (the delegation in the parent zone) is controlled by the TLD registry, not by you. For .com, the NS record TTL in the .com zone is typically 172,800 seconds (48 hours). You cannot change this — you can only change the TTL on the NS records within your own zone, which affects resolvers that already have your zone’s NS records cached.

Wait for the old TTLs to expire.

Phase 3: Update the delegation

At your domain registrar, change the nameservers from the old provider to the new provider. This updates the NS records in the parent zone (e.g., the .com zone for a .com domain).

Both the old and new providers should continue serving correct answers during this transition. Resolvers that still have the old NS records cached will query the old provider; resolvers that pick up the new NS records will query the new provider. Since both return the same data, users see no difference.

Phase 4: Monitoring period

Keep the old provider active for at least 48–72 hours after changing the delegation. This covers the worst-case scenario: a resolver that cached the old NS records with the maximum parent-zone TTL just before you made the change.

Monitor:

• Query volume on the old provider should decline toward zero
• Query volume on the new provider should increase to your normal baseline
• Error rates on both providers should remain flat
• Email delivery (check MX record resolution)
• SSL/TLS certificate renewal (if using DNS-01 validation)

Phase 5: Decommission

Once query volume on the old provider has dropped to zero (or near-zero), you can safely remove the zone from the old provider and cancel the service.

Raise TTLs on the new provider back to their operational values.

Common pitfalls

Missing records

The most frequent migration failure: a record exists on the old provider but was not created on the new provider. This is especially common with:

• TXT records for email authentication (SPF, DKIM, DMARC) — these are easy to overlook because they’re not visible to users, but missing them breaks email delivery
• SRV records for specific services
• CNAME records that are aliased through multiple levels
• Wildcard records that silently catch unmatched queries

Export the full zone from the old provider (AXFR, API export, or manual extraction) and diff it against the new provider’s zone.

Glue record mismatches

If your nameservers are within your own domain (ns1.example.com serving example.com), the parent zone needs glue records — A records for your nameservers that are served from the parent zone to break the circular dependency. When changing providers, the glue records must be updated at the registrar to point to the new nameserver IPs.

DNSSEC key rollovers

If your domain is signed with DNSSEC, migrating providers requires careful key management. The old provider’s DNSSEC keys will not work on the new provider. The DS record in the parent zone must be updated to reference the new provider’s keys.

The safe approach:

1. Set up the new provider with DNSSEC signing
2. Add the new provider’s DS record to the parent zone alongside the old provider’s DS record (both active simultaneously)
3. Switch the delegation to the new provider
4. Remove the old provider’s DS record from the parent zone

Removing the old DS record before the delegation switch — or switching before adding the new DS record — will cause DNSSEC validation failures and make your domain unreachable from validating resolvers.

Email disruption

Email is the most sensitive service during DNS migrations because MX record resolution failures result in bounced mail that may be permanently lost. Unlike web traffic (which retries immediately), email servers follow complex retry schedules defined in RFC 5321, and some messages may bounce rather than queue if the MX lookup fails.

Verify MX resolution from multiple public resolvers both before and after the migration. Monitor your mail server logs for delivery failures during the transition period.

Infrastructure-as-code for DNS

Modern DNS operations treat zone data as code — version-controlled, reviewed, tested, and deployed through automated pipelines:

dnscontrol (by Stack Exchange) — Define DNS records in a JavaScript-based DSL, push to multiple providers simultaneously. Supports 30+ DNS providers.

OctoDNS (by GitHub) — Python-based DNS record management that syncs zone data between providers using YAML configuration files.

Terraform — The dns and provider-specific resources (aws_route53_record, cloudflare_record) manage DNS records as infrastructure-as-code alongside your other cloud resources.

These tools solve the multi-provider synchronization problem: define your zone once, deploy to all providers atomically, and diff proposed changes before applying them. They also provide an audit trail — every DNS change is a code commit with a timestamp, author, and review history.

For organizations managing more than a handful of DNS records, infrastructure-as-code is not optional — it’s the only way to maintain consistency across providers, prevent configuration drift, and safely execute migrations.