How to Migrate DNS Providers Without Downtime

Here's how to do it cleanly.

Before You Start

Export Your Current Zone

Get a complete snapshot of every record in your zone before you touch anything. Most DNS providers let you export as a BIND zone file or CSV. If yours doesn't, manually document every record (name, type, value, and TTL).

This export is your safety net. If something goes wrong during migration, you have a reference to restore from.

Inventory What Matters

Not all records are equal. Identify the critical ones:

• A/AAAA records for your main website and services
• MX records for email delivery
• TXT records for SPF, DKIM, and DMARC
• CNAME records for subdomains pointing to third-party services
• NS records for delegated subdomains
• CAA records for certificate issuance
• SRV records for service discovery

For each record, know what it does and verify it's still needed. Migrations are a good time to clean up stale records, but don't combine cleanup with the migration itself. Migrate first, clean up after.

Set Up the New Provider

Create your account on the new DNS provider and add your domain. Import your zone file if they support it. If not, recreate every record manually.

Verify every record matches. This is the step people rush through and regret. Compare the records on the new provider against your export, record by record. Pay attention to:

• TTL values (some providers set defaults that differ from your current values)
• Trailing dots on hostnames (some providers add them, some don't)
• TXT record quoting (long TXT records may need to be split into 255-byte chunks)
• Priority values on MX and SRV records

The Migration

Step 1: Lower TTLs (24-48 Hours Before)

Before you switch nameservers, lower the TTL on your critical records to something short; 300 seconds (5 minutes) is a good target. Do this on your current provider.

When you switch nameservers, resolvers around the world will still cache the old records until their TTLs expire. If your A record has a 24-hour TTL, some users will hit the old provider for up to 24 hours after you switch. With a 5-minute TTL, the stale cache window shrinks to just 5 minutes.

Lower the TTL at least 24-48 hours before the migration, because the old, high TTL needs to expire everywhere first.

Step 2: Verify the New Zone Is Serving Correctly

Before changing nameservers, test that the new provider returns correct responses. Query the new nameservers directly:

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

Check every critical record. If anything is wrong, fix it now before any real traffic hits the new provider.

Step 3: Update Nameservers at Your Registrar

Log into your domain registrar and change the NS records to your new provider's nameservers. This is the point of no return (though you can always change them back if needed).

The registrar will update the NS delegation in the parent zone (e.g., .com). This change propagates globally over the next few hours, though most resolvers will pick it up much faster.

Step 4: Monitor the Transition

For the next 24-48 hours, both providers may receive queries. Monitor from multiple geographic locations:

• Resolve your domain from different regions and verify the responses are correct
• Check that email is flowing normally
• Verify SSL certificate renewals still work (check CAA records)
• Watch for any services that break

DNS monitoring tools are useful here. Set up alerts for any record changes or resolution failures during the transition window.

Step 5: Raise TTLs Again

Once the migration is stable and you've confirmed everything works, raise your TTLs back to their normal values (typically 3600-86400 seconds). Keeping TTLs low forever increases query volume and adds unnecessary load to your DNS infrastructure.

Step 6: Keep the Old Provider Active (Briefly)

Don't delete your zone from the old provider immediately. Some resolvers, particularly in regions with aggressive caching, may still query the old nameservers for a while. Keep the zone live on the old provider for at least a week after the switch as a safety net.

Common Pitfalls

Forgetting about delegated subdomains. If you have NS records that delegate subdomains to other nameservers (e.g., internal.example.com delegated to a private DNS server), make sure those NS records are recreated on the new provider.

TXT record truncation. Different providers handle long TXT records differently. DKIM keys are often over 255 characters and need to be split. Verify that your new provider stores them correctly.

Glue records. If your nameservers are under the domain being migrated (e.g., ns1.example.com), you need glue records at the registrar. Most migrations use the provider's nameservers, so this doesn't apply, but it's worth checking.

DNSSEC key rollover. If your domain has DNSSEC enabled, you need to coordinate the key change. The new provider will have different DNSKEY values, and the DS record in the parent zone needs to be updated. This is the trickiest part of a DNSSEC-enabled migration. Get the timing wrong and validating resolvers will reject your domain.

After the Migration

Once everything is stable:

• Remove the zone from the old provider
• Set up monitoring on the new provider to alert on unexpected changes
• Document the new provider's access credentials and share them appropriately
• Review and clean up any stale records you identified during the inventory phase

A DNS migration is a controlled infrastructure change. Treat it like one: plan it, test it, monitor it, and verify it. The domains that go down during migrations are almost always the ones where someone skipped a step.