To migrate authoritative DNS safely, prepare the new zone and verify its answers before changing the domain's name servers. Keep the old provider running while resolvers may still use cached delegation information. Both providers need to return correct service records during this transition.

Moving authoritative DNS changes which name servers publish answers for a domain. The parent zone's delegation directs resolvers to those servers, so updating the registrar's settings is only one step in the process. Record inventory, cache timing, DNSSEC, and service checks all affect the outcome; no checklist can guarantee zero downtime.

Back Up and Inventory the Current Zone

Export the current zone if the provider supports it, and keep a dated copy of its record names, types, values, and TTLs. Include the zone apex, common subdomains, wildcard records, delegated subzones, and service-specific names. Compare the export with the provider's live control panel, because an automated import or quick scan may miss records.

Mail deserves a separate inventory. Preserve MX targets and priorities, SPF TXT records, DKIM selector records, DMARC TXT records, and any verification or autodiscovery records used by the mail service. Missing mail records can interrupt delivery or cause authentication failures even while the website still loads. Also check CNAMEs and TXT records that confirm ownership for third-party services.

Build the new zone before changing delegation, then compare the required service records with the inventory. Keep the new provider's assigned apex NS and SOA records unless its migration instructions require otherwise; do not overwrite them with the old provider's values. Handle signing keys and signatures through the DNSSEC migration procedure rather than copying them as ordinary service records.

Some providers proxy web traffic, flatten CNAMEs, or assign automatic TTLs. Check how the new provider will handle these features and compare the intended service behavior as well as the record values. Keep the old zone active throughout preparation.

Lower TTLs before the Change

A DNS record's TTL tells recursive resolvers how long they may reuse a cached answer. Lowering the TTL does not clear copies already cached under the previous, longer value. Reduce the relevant TTLs early enough for that previous TTL to pass before cutover, and record the original values for later restoration.

Delegation records have their own TTLs. Lowering A, AAAA, or MX TTLs does not shorten the parent zone's cached NS delegation, and changing the NS TTL inside your zone does not change the parent's NS TTL. Check the parent delegation's TTL and the controls available through the registrar or parent-zone operator. That TTL may be outside your control.

TTL planning helps define the transition window, but different resolvers can retain old information for different lengths of time. Negative answers can also remain cached. Keep both authoritative services returning correct answers during the overlap, and account for the previous delegation TTL when deciding how long to retain the old provider.

Coordinate DNSSEC with the New Provider

If DNSSEC is enabled, a DS record in the parent zone links the delegation to a DNSKEY record in the child zone. A new provider may use different signing keys. A stale DS record can cause validating resolvers to reject the new zone even when a nonvalidating lookup returns the expected address.

Choose a migration procedure supported by both providers before changing name servers. A supported multi-signer procedure can preserve validation by coordinating the published public keys, parent DS records, and delegation changes. Follow its required waiting periods for cached keys, signatures, and DS records.

If the chosen procedure requires temporarily removing the parent DS records, verify their removal and wait for previously cached DS records to expire before stopping signing or switching to a zone with unrelated keys. This temporarily removes the domain's DNSSEC protection through the parent delegation. When restoring DNSSEC, wait out the old delegation and DNSKEY cache lifetimes specified by the migration procedure. Verify that the new zone is signed and publishes the intended DNSKEY before adding the corresponding DS record to the parent.

Record who can change the parent DS records; DNS hosting access alone may not provide that control. Postpone the switch if the required signing and delegation sequence is unresolved. Include DS records, keys, and their cache lifetimes in the rollback plan, because reverting only the name servers may leave validation broken.

Switch Delegation Only after the New Zone Is Ready

Query each assigned new authoritative server directly before changing the parent delegation. Check the apex and www names, mail records, important subdomains, and any customer-facing API names against the inventory. Confirm that the server is authoritative for the zone and returns the intended records.

With dig installed, these examples check the apex A and MX records without requesting recursion. Replace NEW_NAMESERVER with an assigned authoritative server's hostname or IP address, and replace example.com with your domain. Repeat the checks for each new server and the other names and record types in the inventory.

dig @NEW_NAMESERVER example.com A +norecurse
dig @NEW_NAMESERVER example.com MX +norecurse

After the new zone passes checks and the DNSSEC plan permits the change, update the domain's name servers through the registrar or parent-zone operator. Record the old and new server names and the time when the parent delegation changes. Leave the old zone available for resolvers that still hold its delegation in cache.

Freeze ordinary record changes during the transition where possible, or apply necessary service-record changes to both providers. Changing delegation back during a rollback also takes time to reach resolvers. If application endpoints must change too, schedule those changes separately where practical so a service failure is easier to diagnose.

Verify Services before Retiring the Old DNS

Confirm the new delegation in the parent zone, then compare answers from each new authoritative server and several recursive resolvers. Use the same names and record types and record when each check was made. Test dependent services, including web pages, APIs, inbound and outbound mail, and any VPN or verification workflow. Check application and mail logs for failures that DNS queries alone would miss.

For a DNSSEC-enabled domain, check that the intended chain validates. If the BIND delv utility is available, replace example.com with your domain in this example. Read the validation result as well as the returned records: an unsigned answer does not prove that DNSSEC validation succeeded.

delv example.com A

Keep the old provider active through the relevant cached delegation window, measured from the published parent change, and any additional retention period required by the providers. Differences between networks may reflect cached information, so investigate them before retiring the old zone. Confirm that services work through the new provider and that monitoring no longer depends on the old servers.

Once service checks pass and the rollback window has closed, retire the old DNS service according to the migration plan. Restore appropriate TTLs and complete any remaining DNSSEC cleanup after its required waiting periods. Save the final zone inventory, provider contacts, and the results of the migration checks.