Moving a signed zone without a SERVFAIL

The fastest way to turn a healthy signed zone into a SERVFAIL is to change its nameservers while the parent still publishes a DS record for a key that exists only at the old provider. The safe non-cooperating-provider sequence is to remove that DS, wait out its cache lifetime, move the delegation while the zone is intentionally insecure, then sign at the destination and publish the new DS.

The parent and child have to agree#

DNSSEC validation crosses a zone boundary. The parent zone publishes a DS RRset for the child. That DS identifies a DNSKEY at the child, and the child's signatures prove the RRsets a resolver actually requested. RFC 4033 describes this alternating DS-to-DNSKEY authentication chain.

You need two authoritative queries to inspect it. On September 27, 2026, the .com authority returned this DS for example.com:

dig +norecurse +dnssec @a.gtld-servers.net example.com DS

;; flags: qr aa; QUERY: 1, ANSWER: 2
example.com. 86400 IN DS    2371 13 2 C988EC423E3880EB...C83D245A
example.com. 86400 IN RRSIG DS 13 2 86400 20260930013256 20260923002256 41446 com. ...

The child authority published the corresponding DNSKEY set:

dig +norecurse +dnssec @hera.ns.cloudflare.com example.com DNSKEY

;; flags: qr aa; QUERY: 1, ANSWER: 5
example.com. 3600 IN DNSKEY 257 3 13 mdsswUyr3DPW132m...L53eKGQ==
example.com. 3600 IN DNSKEY 256 3 13 oJMRESz5E4gYzS/q...a2XhSA==
example.com. 3600 IN RRSIG DNSKEY 13 2 3600 20261125174647 20260925174647 2371 example.com. ...

+dnssec sets the DNSSEC OK bit so the server can include DNSSEC RRs. aa shows that these answers came from authoritative data. A query through a validating recursive resolver can also return ad, meaning that resolver says the answer data was authenticated:

dig +dnssec example.com A

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3
example.com. 300 IN A     172.66.147.243
example.com. 300 IN A     104.20.23.154
example.com. 300 IN RRSIG A 13 2 300 20260927200628 20260925180628 34505 example.com. ...

The key tag 2371 links the example DS to a DNSKEY, but a validator also checks the digest, signatures, algorithms, and validity times. Matching a number by eye is not validation.

Why a DNSSEC migration returns SERVFAIL when NS changes first#

Assume the old provider serves key A and the new provider serves key B. The parent still has DS(A) when you replace NS(old) with NS(new).

A resolver can now follow the new delegation, receive DNSKEY(B), and fail to find the key described by DS(A). The parent asserted that the child is secure, so the resolver cannot downgrade this to unsigned data. It marks the result bogus. RFC 4033 section 5 specifies that bogus data is signaled to a stub as server failure.

Removing key A from the old zone before its DS has expired creates the same mismatch even without changing nameservers. Turning DNSSEC off only in a provider dashboard also does not remove the parent DS. The registrar or registry side of the chain is the state that matters.

DNSSEC migration procedure for non-cooperating providers#

This procedure deliberately creates an insecure interval. “Insecure” has a precise DNSSEC meaning: the validating resolver has authenticated proof that no DS exists at the delegation, so it can accept unsigned child answers. That is different from “bogus,” where a DS exists but validation fails.

Enter the TTLs from your actual parent and authorities. The timeline begins when the parent publishes DS removal, not when you submit the registrar form.

RFC 6781 section 4.3.5.2 describes this insecure transition for non-cooperating DNS operators. The waiting periods are protocol state, not ceremony.

What DNSMigrator automates, and the boundary#

DNSMigrator requires apply and verification before cutover starts. It detects whether the live zone is signed. For a signed zone, its cutover steps are: remove DS, wait for DS, switch NS, observe propagation, enable DNSSEC at the destination, and publish the new DS.

Guided mode polls while you make registrar changes. Automatic mode uses a connected registrar when that adapter can manage DS and nameservers; otherwise it stops at an instruction for the dashboard action. The implementation records the old nameservers and can request a revert after an automatic switch.

The current DS wait in the cutover worker is one day. That matches the authoritative 86400-second DS TTL observed for example.com above, but it is not a universal DNS constant. Measure your domain's parent DS TTL before starting. If it is longer than one day, the maintenance plan must honor the longer value rather than treating the built-in day as sufficient. The DNSSEC transition guide and DNSSEC migration checker provide the operational checks.

After the NS switch, the worker samples public-resolver propagation and proceeds when at least 80% of the sampled resolvers report the new set. That is a progress gate, not proof that every cache has expired. Keep the old provider serving through the full delegation TTL.

Change DNS provider with DNSSEC still active#

An intentionally insecure interval is not the only possible design. With cooperating operators, multi-signer DNSSEC can cross-publish keys and signatures so both authorities validate during the re-delegation. RFC 8901 specifies multi-signer models. Cloudflare publishes a concrete active DNSSEC migration procedure that cross-imports zone-signing keys.

That path requires capabilities and coordination at both providers. Do not improvise it by copying one DNSKEY: the participating signers, DNSKEY RRsets, signatures, and parent DS set must remain coherent. DNSMigrator's standard cutover uses the non-cooperating, insecure transition described above; it does not claim to orchestrate cross-provider signing.

Diagnose a DNSSEC-only failure#

If a validating resolver returns SERVFAIL, compare a normal query with one that sets checking disabled:

dig +dnssec @1.1.1.1 example.com A
dig +dnssec +cdflag @1.1.1.1 example.com A

If the first fails and the second returns data, DNSSEC validation is a leading suspect, not a conclusion. Next query the parent DS and the currently delegated child DNSKEY directly. Also check RRSIG inception and expiration times; DNSSEC introduces absolute-time dependencies, so a bad signer clock or expired signatures can fail an otherwise correct key chain.

Change-window checklist#

• Destination records verify authoritatively before any delegation work.
• The old DS value and TTL are recorded from the parent authority.
• The parent no longer publishes the old DS before the wait begins.
• The wait is at least the measured DS TTL.
• Old and new providers keep equivalent application records during NS propagation.
• Destination DNSKEY and RRSIG records are live before the new DS is submitted.
• The new DS is confirmed at the parent and ad answers return through validating resolvers.
• The old provider remains active until delegation caches have expired.

DNSSEC does not make a provider move unsafe. It makes the ordering observable and unforgiving. Respect the parent, the child, and the caches as three separate states. Put the sequence into the interactive DNS migration checklist, use the dig command examples to query each layer directly, and keep the old DNS provider answering while NS caches expire. After cutover, the DNS migration checker provides a final live-surface check.