DNSSEC SERVFAIL After a Nameserver Change: Diagnose the Trust Chain

Your new DNS provider shows the right address, but some users still can't resolve the domain. A validating resolver returns SERVFAIL, while another query appears to work. After a nameserver migration, that pattern can indicate a broken DNSSEC trust chain rather than ordinary propagation delay.

DNSSEC adds authenticity checks to DNS answers. If the parent zone still points at old signing information while the new provider serves different keys, a resolver can reject an otherwise sensible-looking answer. Waiting alone won't repair an inconsistent chain.

Confirm what is failing

Record the affected hostname, resolver, record type, and time. Distinguish SERVFAIL from NXDOMAIN, a timeout, or an unexpected address. They describe different observations and shouldn't be collapsed into “DNS is broken.”

Cloudflare's DNSSEC troubleshooting documentation describes stale registrar-side DS records as one possible cause after authoritative nameservers change. It also documents comparing normal validation with a query that disables checking. Use that comparison as evidence for further investigation, not as permission to ignore validation permanently.

Start with the public records you own. DNS Lookup can inspect its supported record types, including NS records, but it is not a complete DNSSEC validator. It won't by itself establish whether DS, DNSKEY, and signatures form a valid chain.

Compare validation behaviour carefully

From an authorised diagnostic environment, query a resolver with and without the checking-disabled flag. For a domain you control, an illustrative pair is:

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

If the first fails and the second returns an answer, DNSSEC validation deserves attention. The checking-disabled result isn't proof that the answer is trustworthy. You have deliberately removed a protection to compare behaviour, much as a diagnostic test may bypass a check without recommending that bypass in production.

Repeat against another appropriate resolver and record the results. Different caches can temporarily show different states. Don't use one successful response to conclude that every validating client has recovered.

Inspect both sides of the delegation

The parent zone publishes delegation information, including a DS record when DNSSEC is linked for the child. The child zone serves DNSKEY material and signed records. A valid relationship depends on more than the address shown in the child provider's dashboard.

Check the registrar's DNSSEC settings and the new provider's DNSSEC status. Confirm the intended key information through official provider interfaces. An old DS record, missing signing configuration, expired signatures, or an incomplete migration can each require a different repair.

Don't copy a random DS value from an example. Key identifiers, algorithms, digest types, and digests must come from the actual signed zone and the provider's instructions. Treat the registrar change as security-sensitive, with an appropriate reviewer and an audit record.

Follow the provider's migration sequence

DNSSEC migration procedures vary by provider and supported features. Some workflows coordinate signing changes; others require a carefully timed transition in the parent delegation. Read the official instructions for both the outgoing and incoming providers before making further changes.

Avoid turning off signing in the child while a parent DS still tells validators to expect it. That mismatch can keep resolution broken. Likewise, don't publish a new DS before the corresponding signed zone is ready to serve consistent data.

Write down the current state before editing anything: nameservers, parent DS information, child signing status, and relevant TTLs. A clean record makes it easier to restore or explain the change. For sanitised before-and-after notes, Text Diff can highlight what changed without pretending to validate the cryptographic relationship.

Rule out neighbouring problems

Check delegation consistency and authoritative availability too. A server timeout can produce failures unrelated to DNSSEC. Confirm that all listed nameservers serve the intended zone and that the domain hasn't expired or been placed on hold.

If only one authoritative server differs, the repair may involve provider-side synchronisation rather than the registrar. If the parent delegation points at the wrong servers, changing an A record in the new dashboard won't fix the path resolvers use to find the zone.

Keep TLS issues separate. Once DNS resolves correctly, an HTTPS connection can still fail for another reason. See Cloudflare origin TLS troubleshooting if the remaining symptom is a proxy-to-origin handshake failure.

Verify recovery with validation enabled

After the approved change and relevant caching period, repeat the validating queries. Check several relevant record types and more than one resolver. Confirm that the expected answers are returned without the checking-disabled flag.

Record the final trust-chain state and close the migration only when it is verified. A browser loading on your machine can reflect a local cache or a different resolver; it isn't enough evidence for a broad recovery claim.

Add DNSSEC state to future migration checklists. Assign responsibility for registrar-side changes, not just provider-side records. Teams often split those accounts across people, which is exactly how one half of the chain can be overlooked.

Conclusion

A DNSSEC failure is a trust-chain problem, not merely an address problem. Compare validation behaviour, inspect parent and child state, and follow an approved migration sequence. Verify the repair with validation enabled so the final result restores both availability and authenticity checks.