How to Diagnose DNSSEC SERVFAIL with dig
By DNSRadar
SERVFAIL after a DNS change is often treated as propagation, but DNSSEC failures do not fix themselves by waiting. If validating resolvers reject the zone, users behind those resolvers can fail while other networks appear normal.
Start by comparing validating resolvers
Public resolvers may differ because some validate DNSSEC and others expose different cached states. Compare the same name across independent resolvers before changing the zone again.
dig @1.1.1.1 example.com A +dnssec
dig @8.8.8.8 example.com A +dnssec
dig @9.9.9.9 example.com A +dnssecCheck the parent DS record
A stale DS record at the registrar is a common cause. If DNSSEC was disabled or the DNS provider changed, the parent may still publish a DS that points to keys no longer served by the child zone.
dig example.com DS +short
dig +trace example.com DSQuery authoritative nameservers directly
- Confirm every authoritative server answers for the zone.
- Compare SOA serials so you know whether all servers serve the same version.
- Check DNSKEY records if DS exists at the parent.
- Look for SERVFAIL only on recursive resolvers, not on direct authoritative queries.
Common DNSSEC mistakes
Changing DNS provider without removing DS
The parent still tells validating resolvers to expect old DNSSEC keys.
Publishing mismatched DNSKEY and DS
The chain of trust breaks even when ordinary records look correct.
Assuming non-validating success proves the zone is fine
Non-validating paths can hide DNSSEC problems.
Making repeated changes during cache expiry
More changes can make the failure pattern harder to read.
Interpret +dnssec and +cdflag without treating them as a fix
The +dnssec option requests DNSSEC data; it does not turn dig into a validating resolver. A validating recursive resolver can set AD when it considers the answer authenticated. An absent AD flag alone is not proof of failure: the zone might be unsigned or the query path might not provide validation.
Compare the normal response with +cdflag at the same resolver. If SERVFAIL becomes an answer with checking disabled, suspect validation and inspect DS at the parent, DNSKEY at the child, signatures and rollover timing. This is evidence to investigate, not a reason to disable validation for your users.
If both requests fail, authoritative reachability, delegation or other errors may be responsible. Record status, flags, the resolver IP and any extended DNS errors. Confirm which operator controls the parent DS before coordinating a change. Never remove DS or rotate signing keys solely because a propagation checker reports SERVFAIL.
dig @1.1.1.1 example.com A +dnssec
dig @1.1.1.1 example.com A +dnssec +cdflag
dig example.com DS +dnssec
dig @ns1.example.net example.com DNSKEY +dnssecSources and editorial approach
Technical documentation by DNSRadar. Examples using example.com and documentation addresses are illustrative; adapt commands to your zone and compare authoritative answers before changing production.
How we measure and the tool's limitations · Report a correction