ClueDNSSearch

playbook · advanced

Switch authoritative DNS providers safely

Export, stage, compare, sequence DNSSEC, change delegation once, verify every service, and preserve a working rollback provider.

Published
Jul 28, 2026
Last verified
Review by
Risk
availability-impacting
Provider
neutral

An authoritative-provider migration changes where the parent sends resolvers for the entire child zone. The new provider must already publish a complete, consistent zone before the parent delegation changes. Keep the old provider serving throughout the overlap and coordinate DNSSEC as its own parent-and-child sequence.

Blast radius and owners

The blast radius is every name and service in the zone, including delegated subzones, web, email, certificates, verification, and DNSSEC.

Control point Responsible owner
Parent NS, glue, and DS submission Registrant or authorized registrar owner
Old zone, signing, and retention Old DNS provider owner
New zone, nameservers, signing, and import New DNS provider owner
Web, CDN, certificate, and origin Web owners
MX, exchangers, sender policy, and delivery Email owners
Approval, observation, rollback, and communication Migration owner

Do not combine this change with a registrar transfer. Registration and authoritative hosting are separate control planes.

Prerequisites

  • authorized access and tested recovery for registrar and both DNS providers;
  • a complete machine-readable old-zone export;
  • a supported method to stage and query the new zone before delegation;
  • an explicit DNSSEC transition design;
  • retention agreement for the old service;
  • application owners available during the window;
  • rollback nameserver set and prior DS state; and
  • monitoring that separates DNS, TLS, HTTP, and email.

Inventory and export

Export and independently query:

  • parent NS, glue, DS, and TTLs;
  • child-apex SOA and NS from every old authority;
  • all A, AAAA, CNAME, MX, TXT, CAA, SRV, and other RRsets;
  • wildcard records and empty non-terminals where relevant;
  • delegated subzones and nameserver addresses;
  • DNSKEY, RRSIG, NSEC or NSEC3, and validation state;
  • provider-specific proxy, flattening, routing, health, or signing behavior;
  • apex and www TLS, redirects, headers, CDN, and origin;
  • inbound and outbound email plus authentication; and
  • exact old nameserver and DNSSEC values for rollback.

Query results and a zone export serve different purposes. Preserve both.

Preflight

  1. Import or reproduce the complete zone at the new provider.
  2. Compare the new zone with the export and authoritative observations.
  3. Query every new nameserver directly for SOA, NS, web, mail, verification, wildcard, and subdelegation data.
  4. Confirm all new servers agree and answer authoritatively over their published network paths.
  5. Resolve every nameserver target and identify required parent glue.
  6. Prepare web, CDN, origin, certificate, and email behavior for any provider-specific differences.
  7. Capture parent DS TTL and decide between a supported multi-signer transition and a reviewed insecure interval.
  8. Use the DNS Lookup pathway and Domain Registration Lookup pathway for named external observations.

Glue supports referral reachability when resolving a nameserver target would otherwise depend on reaching the child [6].

Stop conditions

Stop before changing parent delegation if:

  • either zone cannot be exported;
  • the new zone differs without an approved explanation;
  • any new authority is non-authoritative, unreachable, or inconsistent;
  • web, mail, verification, wildcard, or subdelegation records are missing;
  • provider-specific proxy or alias behavior is unresolved;
  • required glue is absent or disputed;
  • parent DS state or DNSSEC sequence is unknown;
  • old-provider retention is shorter than the cache and rollback window; or
  • rollback access, values, or owner are unavailable.

Stop adding changes after the first unexplained resolver or application result.

Ordered steps

  1. Freeze unrelated zone cleanup and record the approved migration baseline.
  2. Keep the old provider authoritative and reproduce the complete zone at the new provider.
  3. Verify every new authority directly until the staged service is consistent.
  4. Sequence DNSSEC:
    • for a supported multi-signer design, follow the reviewed provider procedure and validate every intermediate chain;
    • for an insecure interval, remove old parent DS, wait through its observed cache lifetime, and prove the delegation is insecure before serving unrelated new keys.
  5. Submit the complete new parent nameserver set once. Update required glue in the same reviewed parent control path.
  6. Record submission time, parent NS TTL, and the exact accepted values.
  7. Verify parent, new authorities, named resolvers, DNSSEC state, web, email, and delegated subzones.
  8. Keep the old provider serving the captured zone for the approved overlap.
  9. After delegation and applications are stable, establish the intended new DNSSEC chain and verify validating resolvers. DNSSEC authenticates DNS data through the parent-to-child chain [4].
  10. Retire the old service only after observed cache windows, monitoring, and rollback criteria are closed.

The parent delegation establishes the administrative cut between zones [1]. DNSSEC timing and key transitions require explicit operational coordination [5].

Verification

Verify in order:

  1. parent NS, required glue, and intended DS;
  2. authoritative SOA, NS, and complete required RRsets on every new server;
  3. named recursive-resolver answers with times and TTLs;
  4. DNSSEC secure or intentionally insecure state;
  5. apex, www, TLS, redirects, headers, CDN, and origin;
  6. MX, exchanger addresses, SPF, DKIM, DMARC, and mail flow;
  7. delegated subzones, verification records, and less-visible services;
  8. monitoring and representative user journeys; and
  9. continued old-provider availability during the overlap.

Negative caches and positive RRsets age independently [3]. Record observers instead of claiming a global propagation percentage.

Rollback

Rollback when new authorities disagree, required records are absent, DNSSEC becomes bogus, or critical applications cross the approved failure threshold.

  1. If a new DS was submitted, use the reviewed DNSSEC recovery sequence and keep matching child signing available through the DS cache lifetime.
  2. Restore the complete prior parent nameserver set once.
  3. Restore prior required glue where the parent change included it.
  4. Confirm every old authority still publishes the captured zone.
  5. Keep both providers serving compatible data for cached delegations.
  6. Verify parent, old authorities, named resolvers, DNSSEC, web, and email.
  7. Record mixed cache windows and do not flip delegation repeatedly.

An NS RRset names authorities; it does not prove they are reachable, consistent, or serving the intended zone [2].

Next step

If the migration produces a symptom, use website failure after changing nameservers, parent and child NS or glue differences, or DNSSEC bogus after a change according to the evidence.