Diagnosing DNSSEC Outages: From SERVFAIL to the Broken Link

The symptom that gives it away

DNSSEC outages follow resolver choice, not geography. Validating resolvers — Quad9, many ISP resolvers, most corporate setups — answer SERVFAIL for a zone whose chain fails validation. Non-validating resolvers serve the same records without complaint. The result is an outage that is real for some user populations and invisible to others, which reliably sends troubleshooting in the wrong direction: the web server is fine, the zone file looks fine, and half the world cannot reach either.

The fastest way to confirm the class of problem is to ask a validating path directly and read the verdict. The DNSSEC Validator shows the resolver status along with the chain evidence — DS, DNSKEY, and RRSIG — in one view. Three verdicts matter: secure means the chain validates; insecure means the parent has no DS record and the zone is simply unsigned, which is a configuration state, not an error; bogus means the zone claims to be signed and fails, and that is the acute case taking traffic down.

Root cause one: the expired signature

RRSIG records carry explicit validity windows. Zones re-sign automatically, and when that automation dies — a stuck cron job, a full disk, a decommissioned signer that still owned the zone — nothing visible happens at first. The outage begins days later, when the last signature expires, which is why the breakage so rarely correlates with any change anyone remembers making.

The diagnostic signature is unambiguous: RRSIG expiration timestamps in the past. The fix is operational rather than cryptographic — restart the signing pipeline, re-sign, and then put monitoring on RRSIG expiry with enough lead time to fix a broken signer before the window closes. Monitoring signature lifetimes is monitoring the signing pipeline; certificate-style expiry alerts on the zone apex catch this failure class completely.

Root cause two: the rollover that lost its overlap

The second classic is a key-signing-key change where the parent's DS record and the child's DNSKEY set stopped matching: a rollover performed without overlap, a registrar transfer that silently dropped the DS, or a new DNS provider signing with fresh keys while the old DS still sits at the parent. Validation walks DS to DNSKEY to RRSIG, and a DS that digests a key no longer in the zone breaks the walk at the first step.

Compare the DS at the parent against the currently published KSK — that is the exact link the parent anchors. During any planned rollover, the old key must remain published and signing until the new DS has fully propagated past the parent's TTL. And after any provider or registrar migration, checking the DS is the single highest-value verification step: migrations are where DS records go to die quietly.

One habit prevents most of both root causes: treat DNSSEC changes with the same ceremony as certificate changes. Staged, verified from the outside afterwards, and never on a Friday. When DANE rides on top of the zone, the stakes double — a bogus zone takes down TLSA lookups too, and with them mail delivery from validating senders; the DANE Validator shows that blast radius directly.