Fixing DNSSEC SERVFAIL Errors on Domain Migration

Published: 25 Aug, 2026

What Causes DNSSEC SERVFAIL During Migration?

A SERVFAIL (Server Failure) RCODE returned by validating recursive resolvers (such as 8.8.8.8, 1.1.1.1, or corporate recursive DNS) indicates that the resolver could not establish a valid chain of trust. When a domain is protected by DNSSEC, recursive resolvers authenticate the zone by walking the chain of trust from the root zone down to your apex domain.

When you migrate a domain to a new authoritative DNS provider (e.g., from Route 53 to Cloudflare, or from BIND to NS1) without properly coordinating the DS (Delegation Signer) records in the parent zone (TLD registry), validating resolvers will reject all responses. Non-validating resolvers may still resolve the domain, masking the problem for some users while breaking access entirely for resolvers enforcing RFC 4035.

Common Root Causes

• Orphaned DS Records: The nameservers (NS records) were updated at the registrar, but the old DS record pointing to the previous provider's KSK (Key Signing Key) remains active at the TLD registry.
• Algorithm Mismatch: The new provider signs the zone with Algorithm 13 (ECDSA P-256) while the registrar's DS record specifies Algorithm 8 (RSA/SHA-256).
• Premature Key Deletion: Removing the old DNSKEY from the child zone before the parent DS record's TTL expires.
• Clock Drift and Expired RRSIGs: Authoritative nameservers serving signatures where the signature_expiration timestamp is in the past or out of sync with recursive resolver clocks.

Diagnosing the Trust Chain Break

Use dig and delv to trace the validation path and isolate the exact point of failure.

1. Verify SERVFAIL with and without Validation

Query a validating resolver with standard flags, then query with the +cd (Checking Disabled) flag. If the query succeeds with +cd, DNSSEC validation is definitively broken:

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

2. Trace the Trust Path with delv

Execute delv to pinpoint where the cryptographic chain fails:

delv @8.8.8.8 example.com A +rtrace +multiline

If the output outputs ;; fully validated, the chain is sound. If it outputs ;; resolution failed: failure or broken trust chain, inspect the DS/DNSKEY fingerprint match.

3. Compare the Parent DS Record with the Child DNSKEY

Query the parent TLD nameservers directly for your domain's DS record:

dig @a.gtld-servers.net example.com DS +noall +answer

Query your new authoritative nameservers for the active DNSKEY records:

dig @ns1.newprovider.com example.com DNSKEY +noall +answer +multiline

Generate the expected DS hash from the active DNSKEY using dnssec-dsfromkey or calculate the SHA-256 digest manually to verify that the Key Tag and Digest match the parent record.

How to Fix It (Step-by-Step)

Method 1: Emergency Recovery (Fastest Restoration)

If production traffic is down, disable DNSSEC at the parent zone immediately:

1. Log in to your Domain Registrar management console.
2. Navigate to the DNSSEC Management section.
3. Delete all DS records associated with the domain.
4. Wait for the parent zone's DS record TTL to expire (typically 3,600 to 86,400 seconds).
5. Flush public resolver caches using their web purge interfaces (Google Public DNS and Cloudflare 1.1.1.1 cache flush tools).

Method 2: Zero-Downtime DNSSEC Migration (Pre-Publish Method)

To safely migrate an active DNSSEC zone between providers without causing outages, execute the rollover in this exact sequence: