DNSSEC validation can turn an otherwise visible DNS answer into SERVFAIL when the chain of trust is broken. A stale parent DS record, missing DNSKEY, expired signature or incorrect server clock can produce this result. Diagnose the chain before changing ordinary website records.
IN THIS ARTICLE
Gather the details you will need
Record the failing name, type, resolver and time. Establish whether the domain is intended to be signed and identify who controls the parent DS and authoritative signing keys. Keep the last working delegation and DNSSEC configuration available.
01 Diagnose DNSSEC validation failures that appear as SERVFAIL
- Compare an authoritative answer with the result from a trusted validating resolver. Query DNSKEY, DS and the affected record with DNSSEC data requested.
- Use a properly configured validation tool such as delv, or your DNS provider's diagnostic report, to identify the failing trust link. Merely adding +dnssec to dig requests DNSSEC records; it does not make dig independently validate them.
- Compare the DS published in the parent with the current child signing key details. Check key tag, algorithm and digest, and review any recent nameserver or signing-provider move.
- Check signature validity periods and time synchronisation on infrastructure you administer. Verify that every authoritative server serves a consistent signed zone.
- Restore the correct key/signing state or coordinate the correct parent DS update. If an unsigned transition is necessary, plan parent DS removal and cache expiry before stopping signing.
02 Example: recognise a possible DNSSEC validation failure
Use the same validating resolver for both queries. Replace resolver.example.net with a resolver you are authorised to use and example.com with the failing signed domain. The second query requests checking-disabled diagnostic data for comparison only.
dig @resolver.example.net example.com A +dnssec
dig @resolver.example.net example.com A +dnssec +cdflag
delv @resolver.example.net example.com ARead the result: SERVFAIL on the normal query but an answer with +cdflag is a clue that validation is failing. It is not proof of the exact cause. A current delv installation can validate the chain and report more detail; check parent DS data, child DNSKEY data, signatures and the diagnostic machine's clock.
Fix the broken signed delegation or key transition through the responsible operators. Do not disable DNSSEC on every resolver or publish a guessed DS value. Retest without checking-disabled mode before marking the incident resolved.
Verify the authoritative DNS result
A trusted validating resolver should return the expected answer without validation errors. Recheck multiple names and types and monitor from an independent network after relevant caches expire.
If the problem continues
SERVFAIL also has non-DNSSEC causes, including unreachable authoritative servers. A diagnostic query that temporarily disables checking can help isolate validation, but must not become a permanent workaround on clients or resolvers.
A common question
Should I disable DNSSEC validation on customer devices to make the website load?
Repair the domain's published trust chain instead. Bypassing validation hides the symptom on one device and weakens its protection without fixing other visitors. Escalate with the actual DS, DNSKEY and signature evidence when the responsible provider must act.