When DNSSEC breaks, validating resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 and most ISPs) answer SERVFAIL and your domain disappears for their users. Resolvers that do not validate still answer, so it can look like "it works for me".
First, confirm it is DNSSEC
dig example.com A @1.1.1.1 # status: SERVFAIL dig example.com A @1.1.1.1 +cd # status: NOERROR → validation is the problem
If the answer comes back with +cd (checking disabled), DNS works and only validation fails. delv example.com A usually prints the reason.
The usual causes
- Expired signatures. The signer stopped re-signing, or a secondary stopped getting zone transfers and serves old RRSIGs. Check the expiration date in
dig +dnssec example.com A. - DS points at a key that is not there. After a key rollover, or after moving to a new DNS host that made new keys. Compare
dig DS example.com +shortwithdig DNSKEY example.com +multi: the key tag in the DS must match a KSK. See DS record. - Signing turned off, DS left in place. Remove the DS first, wait for its TTL, then stop signing. See enable and disable.
- Secondaries out of step. One nameserver serves signed data and another serves unsigned data, or older keys. Ask each nameserver directly:
dig +dnssec example.com A @ns2.example.net. - Unsupported or deprecated algorithm. SHA-1 based algorithms (5, 7) fail on some systems. See algorithms.
- High NSEC3 iterations. Resolvers may treat the zone as insecure or fail (RFC 9276). See NSEC3.
- Wrong clock on a validating resolver: signatures look expired or not yet valid.
Tools
diganddelvfrom BIND.- DNSViz (dnsviz.net) draws the whole chain and marks the broken link.
- Verisign Labs DNSSEC Debugger.
- Our checker for a quick status, and its email alerts if the status changes.