DNSSEC Validation Rejecting Valid Domains

Step 1 — Confirm DNSSEC validation is the cause

# Query with validation enabled (default)
dig A example.com @1.1.1.1
# SERVFAIL = validation rejected the response

# Query with validation disabled (CD flag)
dig A example.com @1.1.1.1 +cd
# Success with +cd but SERVFAIL without = DNSSEC validation failure

# Also try
dig A example.com +dnssec +cd @8.8.8.8

Step 2 — Walk the DNSSEC chain manually

# Check if DNSKEY records exist in the zone
dig DNSKEY example.com @8.8.8.8 +dnssec

# Check if the parent zone has a DS record for the child
dig DS example.com @8.8.8.8 +dnssec
# If DS is absent, the chain of trust is broken from the parent

# Check RRSIG validity on the A record
dig A example.com @<authoritative-ns> +dnssec | grep RRSIG
# RRSIG line shows: inception date, expiration date, key tag

Step 3 — Use an automated DNSSEC analyzer

The Verisign DNSSEC Analyzer provides a full chain-of-trust visualization:

https://dnssec-analyzer.verisignlabs.com/example.com
https://dnsviz.net/d/example.com/dnssec/

Look for: - Red/orange nodes indicating broken links in the chain - 'Expired signature' warnings (RRSIG expiry date < today) - 'DS mismatch' (DS hash at parent does not match DNSKEY in zone) - 'No DNSKEY' at the zone apex

Step 4 — Check RRSIG expiration dates

# Get all RRSIG records and show expiration
dig ANY example.com @<authoritative-ns> +dnssec | grep RRSIG

# RRSIG format: <label> <ttl> IN RRSIG <type> <alg> <labels> <origTTL> <expiry> <inception> <keyTag> <signer> <signature>
# Example expiry field: 20260301000000 = 2026-03-01 00:00:00 UTC
# If expiry < today, signatures are stale — zone signing has stopped

Step 5 — Verify DS record at registrar

# Check DS at parent zone (TLD nameserver)
dig DS example.com @a.gtld-servers.net +short     # for .com
dig DS example.com @ns1.dns.nic.org +short         # varies by TLD

# Get DNSKEY from the zone itself
dig DNSKEY example.com +short | awk '{print $1, $2, $3}' | head -5

# If DS record is absent at parent but DNSKEY exists in zone, the chain is severed
# Log into registrar control panel and add/update the DS record

Step 6 — Check for algorithm mismatch

# Get algorithm used in zone DNSKEY
dig DNSKEY example.com | grep -E "DNSKEY|algorithm"

# Older algorithms (RSA/SHA-1 = algorithm 5, 7) may be rejected by modern validators
# RFC 8624 deprecates algorithms 5, 7, and 1 — upgrade to 8 (RSA/SHA-256) or 13 (ECDSA P-256)

Fix 1 — Re-sign the zone (expired signatures)

If signatures expired because auto-signing stopped:

# BIND 9 — force immediate re-signing
rndc sign example.com
rndc loadkeys example.com

# Check that new RRSIGs have future expiry
dig DNSKEY example.com @127.0.0.1 +dnssec | grep RRSIG

# Restart or reload BIND to ensure zone is served
sudo rndc reload example.com

For cloud DNS providers (Route 53, Cloudflare, Google Cloud DNS), DNSSEC signing is fully managed — if signatures expire, contact the provider or toggle DNSSEC off and back on in the control panel to trigger a re-sign.

Fix 2 — Update the DS record at the registrar

After a key rollover, the parent DS record must be updated within the zone's TTL:

# 1. Get new DNSKEY information
dig DNSKEY example.com +short

# 2. Calculate DS record hash
dnssec-dsfromkey -f <(dig DNSKEY example.com +short | head -1) example.com

# 3. Submit the new DS record to your registrar's control panel
# Format: <keyTag> <algorithm> <digestType> <digest>
# Example: 12345 13 2 ABC123...

Fix 3 — Remove DNSSEC if immediate resolution is critical

If the zone cannot be re-signed quickly and the site is down:

# Emergency: remove DS record at registrar to disable DNSSEC validation
# After removing DS, wait for the DS TTL to expire (usually 24–48 hours)
# then the zone will resolve again on validating resolvers

Only use this as a last resort — removing DNSSEC leaves the zone unprotected until signing is properly restored.

Fix 4 — Upgrade deprecated signing algorithm

# BIND 9 — generate a new KSK with algorithm 13 (ECDSA P-256/SHA-256)
dnssec-keygen -a ECDSAP256SHA256 -f KSK -n ZONE example.com
dnssec-keygen -a ECDSAP256SHA256 -n ZONE example.com

# Perform a key rollover per RFC 6781 (double-sign period, then retire old key)
# Update DS record at registrar to include new KSK's DS hash

• Automate zone signing with a key management tool (e.g., OpenDNSSEC, BIND's auto-dnssec) and monitor RRSIG expiry — alert when any RRSIG expires within 7 days
• Set up a calendar reminder or automated check when performing key rollovers to ensure the parent DS record is updated before the old key is removed
• Use ECDSAP256SHA256 (algorithm 13) or ED25519 (algorithm 15) for all new zones — avoid deprecated RSA/SHA-1 algorithms
• Subscribe to registrar-level DNSSEC health notifications and audit DS records annually against published DNSKEY values
• Test DNSSEC after every zone change using dnsviz.net or dnssec-analyzer.verisignlabs.com before propagation completes