How to change DNS hosting without breaking anything

Changing DNS hosting is one of those tasks that’s either completely uneventful or memorably bad, with very little in between. The difference comes down to one thing: whether every record made the trip. The outage nobody predicts isn’t the website — it’s the DKIM selector for the invoicing tool, or the TXT record some service quietly depends on, existing only in the zone you just walked away from.

To be clear about what’s moving: this changes which provider publishes your DNS answers. The domain stays at your registrar, and the website stays on its host. If it’s the registrar you want to leave, that’s a domain transfer — a different task, best done separately. (The DNS explainer covers how these roles fit together.)

1. Capture the complete zone

Export the zone file if the current provider offers it — most panels do, and it’s the difference between copying a list and reconstructing one from memory. If there’s no export, go through the panel and record every record: type, name, value, priority, and TTL.

The records that get forgotten are rarely the obvious ones. Watch for:

• TXT verification records for third-party services,
• DKIM selectors under _domainkey,
• DMARC and SPF policies,
• subdomains nobody has thought about in a year,
• CAA records and service-specific CNAMEs.

Don’t count on tooling to enumerate the zone for you — public zone transfers (AXFR) are refused by most providers for good reason, so dig can only confirm records you already know to ask about.

One special case: if your current DNS is bundled with a registrar or host you’re also leaving, confirm when that zone stops being served. You want the new provider live before the old one disappears, not after.

2. Rebuild the zone at the new provider — before delegation

Recreate every record at the new provider while the old one still serves all traffic. This is the pleasant part of the job: nothing is live, so nothing can break.

Then verify by querying the new provider’s nameservers directly:

dig @ns1.new-provider.example example.com A +short
dig @ns1.new-provider.example example.com MX +short
dig @ns1.new-provider.example selector1._domainkey.example.com TXT +short

Compare against the old zone record by record — a short script beats eyeballing if the zone is large. Every mismatch you find now is an outage you didn’t have.

3. Handle DNSSEC before you move

If the domain has DNSSEC enabled — a DS record at the registrar — stop and deal with it first. The old provider holds the signing keys; point delegation at a new provider that doesn’t have matching keys and validating resolvers will return SERVFAIL for the whole domain. That’s a hard outage, and it looks baffling until you know to check for it.

The straightforward path: remove the DS record at the registrar, wait for it to expire from caches (its TTL, plus margin), complete the provider move, then re-enable DNSSEC with the new provider’s keys. Coordinated key transfers between providers exist but require support on both sides. If you’re not sure whether DNSSEC is on, dig example.com DS +short at the parent will tell you.

4. Change delegation, then respect the overlap

Update the nameservers at the registrar. Here’s the part that surprises people: the delegation records cached from the parent zone commonly carry TTLs of up to 48 hours at major registries, and that number isn’t yours to change. For a day or two, some resolvers will keep asking the old provider while others ask the new one — and both will get answers.

That overlap is fine, with two rules:

• Keep the old zone running and untouched. Don’t cancel the old service, don’t let it lapse mid-move.
• Freeze routine DNS changes. If an urgent change can’t wait, make it identically in both zones.

5. Verify, then retire the old zone

Confirm the parent now hands out the new nameservers, then check answers from public resolvers:

dig example.com NS +trace
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com MX +short

Watch the services that fail quietly — mail delivery above all — for several days. After at least the parent TTL plus a comfortable margin (a week is cheap insurance), retire the old zone deliberately and update your documentation to point at the new provider.

If anything resolves strangely mid-move, the DNS troubleshooting workflow separates delegation problems from record problems in a few queries.

Sources and further reading

• RFC 1034: DNS concepts and facilities
• RFC 1035: DNS implementation and specification
• IANA: Root Zone Database