How to Diagnose DNSSEC SERVFAIL with dig
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.