Changing nameservers (DNS providers) without downtime

How delegation works

Two places define your nameservers:

1. The parent zone (for example.com, the .com registry) holds NS records pointing at your provider. You change these through your registrar.
2. Your zone at the provider also contains NS records, which should match.

Resolvers learn your nameservers from the parent and cache them for the parent's NS TTL. For .com and .net that's 172,800 seconds (two days). You can't shorten it, so plan for it.

Before you start

• Export the current zone if the provider allows it (BIND zone file or CSV). Otherwise list everything manually; the DNS Name Lookup helps confirm individual records.
• Find records you can't see from outside. Exports catch most of them, but check for:
  • DKIM CNAMEs (selector1._domainkey, vendor selectors)
  • verification TXT records (Microsoft 365, Google, Apple, SaaS ownership checks)
  • _dmarc, _mta-sts and _smtp._tls records
  • autodiscover, SRV records for VoIP or Teams
  • CAA records
  • records on subdomains nobody remembers
• Note any provider-specific features, such as ALIAS/flattened apex records, geo-routing, health-checked failover or proxied records (Cloudflare's orange cloud). They need an equivalent at the new provider, or a plain record, and the behaviour may differ.

The migration plan

1. Lower TTLs at the old provider (a day or more ahead)

Reduce TTLs on records you might need to change during the cut-over (A, MX, CNAME) to 300 seconds. This doesn't affect the NS delegation cache, but it means that if a record turns out to be wrong after the switch, you can correct it quickly.

2. Build the zone at the new provider

Recreate every record. Don't add the new nameservers at the registrar yet.

3. Verify against the new nameservers directly

Query the new provider's nameservers, bypassing the delegation:

dig @ns1.newprovider.example example.com MX +short
dig @ns1.newprovider.example selector1._domainkey.example.com CNAME +short
dig @ns1.newprovider.example example.com TXT +short

Compare each answer with the old provider's (dig @ns1.oldprovider.example …). Scripted comparisons of the full record list catch the record everyone forgot.

4. Handle DNSSEC first

If DNSSEC is enabled, a careless switch breaks resolution completely for validating resolvers. Either:

• Simplest: remove the DS record at the registrar, wait for the DS TTL plus the parent's TTL (often one to two days), switch providers, then re-enable DNSSEC at the new provider and publish its new DS; or
• Zero-gap: follow a multi-signer key rollover, where both providers' keys are trusted during the transition. Only do this if both providers support it.

5. Change the nameservers at the registrar

Replace the old NS entries with the new provider's. Then check what the parent now serves with the Nameserver Lookup.

6. Keep the old provider running

For at least the parent NS TTL (48 hours for .com) plus a margin, leave the old zone in place and don't change records at either provider unless you change both. Some resolvers will still ask the old nameservers until their cache expires.

7. Clean up

After a week, remove the zone from the old provider, update the NS records inside the new zone if needed, and restore normal TTLs.

Running two providers on purpose

Some organisations deliberately list nameservers from two providers for resilience. That works only if both serve identical zones, kept in sync by zone transfer or automation. The Nameserver Lookup flags mixed providers. If it isn't deliberate, it usually means a migration was left half-finished.

Common mistakes

• Forgetting DKIM CNAMEs. Every message from that platform fails DKIM until they're restored.
• Switching with DNSSEC still on. Validating resolvers return SERVFAIL, so the domain disappears for a large share of users.
• Deleting the old zone the same day. Resolvers that cached the old delegation get no answers.
• Editing records in only one place during the overlap. Users see different answers depending on which nameserver their resolver asks.
• Only one nameserver at the new provider. Use at least two, ideally on separate networks.

From the field: Some registrars do not allow you to preconfigure DNS and will require downtime to move your records to them. Ensure you properly plan ahead if that is the case.

Sources

• RFC 1034: Domain names, concepts and facilities
• RFC 8901: Multi-signer DNSSEC models
• RFC 2182: Selection and operation of secondary DNS servers