Fix Broken DNSSEC Chain on Email or Web Domain

What's happening

DNSSEC adds cryptographic signatures to DNS responses so resolvers can verify authenticity. Defined in RFC 4033-4035, it requires a chain of trust from the root zone (.) through each level (e.g. com.) down to your domain, anchored by a DS record at the parent and matching DNSKEY records in your zone.

When the chain breaks — DS record at the registry does not match DNSKEY in your zone, key was rotated without updating DS, or a signature has expired — validating resolvers return SERVFAIL on every query for your domain. To users on networks running validating resolvers (most ISPs, public resolvers like 1.1.1.1 and 8.8.8.8 in validation mode, and corporate DNS), your domain effectively does not exist.

SERVFAIL on the email-relevant records (SPF TXT, DKIM TXT, DMARC TXT, MX) means SPF and DKIM authentication produce TempError, and DMARC reports show high temperror rates. SERVFAIL on the apex A record means the website is unreachable. The break is invisible to non-validating resolvers, so the operator's own laptop on a non-validating network may still resolve fine.

Why it matters

Mail authentication fails. SPF returns TempError on every check, DKIM lookups SERVFAIL, DMARC alignment becomes intermittent. Aggregate reports show high temperror percentages within 24 hours.

Website unreachable for 25-40% of users. Public resolvers 1.1.1.1, 8.8.8.8, and 9.9.9.9 all validate by default. Cloudflare's resolver alone serves a quarter of internet traffic. A broken chain takes those users offline.

Recovery is slower than other DNS bugs. Resolvers cache SERVFAIL responses for the negative-cache TTL (typically 300-3600 seconds), so even after the fix lands, users continue to see SERVFAIL for the cache duration.

Common causes

• DNSSEC keys (DNSKEY) were rotated but the DS record at the parent registry was not updated.
• Domain was transferred between registrars and DS records did not transfer.
• DNS provider was migrated and DNSSEC was enabled on the new provider but DS at registrar still points to old keys.
• RRSIG (signature) on a record set expired and no resigning is happening (rare with managed DNSSEC).
• DS algorithm or digest type at the registry does not match the algorithm in DNSKEY.

Detect this on your site

Run a quick scan with the DNS Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

How to fix it

1. 1

   Confirm the break with dig +dnssec

   Run dig +dnssec +cd example.com SOA. The +cd flag disables checking — the response should arrive. Then run dig +dnssec example.com SOA against a validating resolver (1.1.1.1 or 8.8.8.8). If you see status: SERVFAIL but +cd works, DNSSEC is broken.

2. 2

   Visualize the chain at dnsviz.net

   Visit dnsviz.net/d/example.com. The site walks the DNSSEC chain from the root and visually highlights breaks. Errors are color-coded: red for hard failures, orange for warnings. Read the specific error — "DS does not match any DNSKEY" or "RRSIG validity period expired".

3. 3

   Check DS at the parent registry

   Run dig +short DS example.com @parent-ns. The DS record is published at the parent zone (the registrar). Compare its digest to the DNSKEY in your zone. If they do not match, the chain is broken at the DS-DNSKEY link.

4. 4

   Update DS at the registrar

   Most registrars (Cloudflare, Namecheap, Google Domains, Route 53) have a DNSSEC settings page where you paste the DS record from your DNS provider. Pull the current DS values from your DNS provider's DNSSEC dashboard and re-publish at the registrar.

5. 5

   Wait for parent zone propagation

   DS record changes propagate through the parent zone (e.g..com TLD) within minutes to hours. Run dig +short DS example.com periodically until the new DS appears. Validating resolvers will then re-validate the chain on their next cache miss.

6. 6

   If urgent, disable DNSSEC temporarily

   If the break is causing immediate user impact and the fix is complex, remove DS at the registrar. Validating resolvers fall back to insecure responses (no SERVFAIL) within the parent's TTL. Re-enable DNSSEC after you have validated the chain end-to-end on a staging domain.

Example

# Verify chain status
dig +dnssec example.com SOA
# look for status: NOERROR vs SERVFAIL and the AD bit in flags

# Check DS at the parent
dig +short DS example.com

# Visualize the entire chain
curl -s https://dnsviz.net/d/example.com/dnssec/ | grep -i 'error\|warning'

Quick triage commands for a SERVFAIL DNSSEC chain.

Related fixes