Signatures expire

Every RRSIG carries an inception and an expiry. Past the expiry, a validating resolver treats the answer as bogus and returns SERVFAIL — which means the domain does not resolve at all for a large share of the internet, with nothing in the zone having changed.

Reading the window

$ dig +dnssec certadns.com SOA @1.1.1.1 | grep RRSIG

certadns.com. 3600 IN RRSIG SOA 13 2 3600 (
    20260924000000   ; expiration
    20260903000000   ; inception
    29357 certadns.com. ... )

Checked 2026-09-15. A 21-day window, re-signed well before it closes.

Field	Meaning
Inception	Not valid before this. Usually backdated an hour to tolerate clock skew.
Expiration	Not valid after this. The deadline the signer must beat.
Key tag	Which DNSKEY in the set signed this. Matching it is part of validation.

The most common real DNSSEC failure

Not an attack, not a rollover: a signer that stopped running. The zone is correct, the keys are correct, the DS matches, and the signatures quietly age out.

It is a cliff, not a slope. Everything works until the expiry, then a growing share of resolvers fail as their caches refresh.
It affects validating resolvers only, so it looks like an outage affecting some users and not others — and the ones it does not affect are the ones doing less to protect themselves.
Your own monitoring may not see it if it queries a non-validating resolver or your authoritative server directly. Both return the answer happily.
Mail fails too, and if the zone carries TLSA records the failure is total rather than partial.

Monitoring it

# alert on time remaining, not on validity
dig +dnssec example.com SOA @1.1.1.1   | grep -o 'RRSIG SOA [0-9]* [0-9]* [0-9]* [0-9]*' 

# the check that matters:
#   days until the earliest RRSIG in the zone expires
#   alert below a third of the signing interval

# and separately, from a VALIDATING resolver:
dig example.com SOA @1.1.1.1 | grep -c 'flags:.* ad'
#   0 means validation is not succeeding. Alert immediately.

Query something that validates

A check against your own authoritative server tests the one component least likely to be the problem, and it cannot observe a validation failure at all — authoritative servers do not validate. Use a public validating resolver and look for the ad flag.

Knowledge check

A signed domain stops resolving for some users. The zone was not changed. Where do you look first?

RRSIG expiry — a signer that stopped running lets signatures age out, and the failure appears only at validating resolvers.
The DS record at the parent, which must have been removed.
The nameservers, which must be unreachable for those users.
A key rollover that removed the wrong key.

Correct — RRSIG expiry — a signer that stopped running lets signatures age out, and the failure appears only at validating resolvers. "Some users" is the tell: non-validating resolvers are unaffected and return the answer normally. It is the most common real DNSSEC failure and it happens with nothing in the zone having changed.

Not this — The DS record at the parent, which must have been removed. A missing DS makes the zone unsigned rather than bogus, so validating resolvers would accept it. It causes a loss of protection, not an outage.

Not this — The nameservers, which must be unreachable for those users. Worth ruling out and it would produce timeouts rather than SERVFAIL, and it would not correlate with whether the resolver validates.

Not this — A key rollover that removed the wrong key. Possible, and it requires somebody to have changed something. The signature-expiry case needs nobody to have done anything at all.

Reading the window

The most common real DNSSEC failure

Monitoring it

Try it on a real domain