Re-creating a DNS zone on a new host or provider

The zone is the whole story

Creating a DNS zone on a new provider is copying every record from the old provider into a new interface, then repointing the nameservers. A "zone" is that complete list of records for the domain. Copying the A record but losing the MX, TXT or CNAME entries gives you a working website and broken everything else.

Step 1: export the definition

At the old provider, export the full zone in text (BIND format or a table). Save it somewhere other than the old provider's clipboard. Confirm what you see includes the base records for the domain:

• A (and AAAA) at the root and www or the CDN CNAME.
• MX with priorities.
• TXT records, especially SPF (the v=spf1 ... line or the _spf. host) and domain verification records.
• CNAME for subdomains.
• Any SRV and NS that the provider set (root nameserver records usually are the provider's own).

The DNS record types reference explains each type in the detail this copy needs.

Step 2: recreate the zone

Create the zone in the new provider and paste the records in, adapting:

1. Copy the host values verbatim except where the record must change (the IP for a site that lives on the new host is the new IP, per the DNS record moves guide).
2. Do not leave TTL records blank; the default is fine, but raise nothing manually unless you need the cutover fast.
3. Verify the zone parses: most panels refuse or warn on a malformed TXT or a duplicate host.

Step 3: the domain-pointing cutover

1. Update the registrar's or provider's nameservers (the NS records for the domain set where the zone lives) to the new provider's nameservers.
2. Do not change the NS records inside the zone itself (the zone serves the NS list for itself; editing the wrong copy makes the zone advertise a provider that does not host it).
3. The old zone and the new zone both resolve during the changeover window; each resolver follows whichever NS it cached first.

Step 4: verify after the switch

With the new nameservers live, test from an external resolver, not your own (your cache is the enemy; the propagation article covers the timing puzzle):

1. A and www resolve to the right IP.
2. MX is correct (send a test message and check it delivers, then that SPF passes in the headers).
3. TXT includes the site's and mail's records.
4. The SSL certificate on the web host still applies to the domain (it does; certificates are issued for the domain, not the zone).

When the zone is re-created for a new domain instead of a move, the domain transfer and domain change guides are the close relatives that handle WHOIS and content rather than just the DNS.