A DNSSEC signature is close to expiry and has not been renewed
Updated
What this check looks for
One of your signatures has less time left than a working signer ever lets it get to. If whatever normally renews it has stopped, your domain will become unresolvable for a large part of the internet when it expires.
Why it matters
Signatures are renewed automatically well before they expire, so one getting this close is itself the signal that the automation has stopped. Acting now is a five-minute job; acting after the expiry is an outage.
When the check passes, your report says: “Signatures are renewed well before they expire”.
What it costs your score
When this check fails it removes 10 points from your DNSSEC score, before the status, confidence and repeat multipliers are applied. DNSSEC carries a weight of 4 in the overall score.
It shares the dnssec.signatures family ceiling of 55 points: however many findings that family produces, together they cannot remove more than that from DNSSEC. One underlying problem showing up in several places is still one problem.
- Severity
- medium
- Default confidence
- confirmed
- Status when triggered
- warn
- Deduction
- 10 points
- Family cap
- dnssec.signatures · 55
- Category
- DNSSEC
- Module
- Dns dnssec
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Confirm automatic re-signing is running, and re-sign now if it is not.
A signature approaching expiry means the process that renews it has probably stopped.
Check when the zone was last re-signed at your DNS host.
Trigger a re-sign and confirm the expiration date moves out.
If re-signing is manual, move it to a scheduled job — this failure mode will recur otherwise.
How to confirm it worked
dig +dnssec SOA ‹domain› — check the RRSIG expiration has moved further out
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
These signatures are closer to expiry than a working signer lets them get: ‹signature list›.
The line is drawn from each signature's own evidence, not from a fixed date: a signature is reported when the time it has left is at most the largest of a tenth of its validity period (expiration minus inception), the TTL of the records it covers (its Original TTL), and one hour — and never more than seven days. RFC 6781 §4.4.2 has signers re-sign when the remaining validity falls to a refresh margin, and common signers set that margin above a tenth of the period, so a signature below it has been passed over. Once less time is left than the TTL, a validator must cut how long it caches the answer (RFC 4035 §5.3.3), and the margin for noticing a failed re-sign is gone.
The line is relative on purpose. Online signers issue signatures valid for only a day or two and replace them continuously — Cloudflare's were valid for about 50 hours when observed on 2026-10-12 — so every signature they serve has less than seven days left, and a fixed seven-day line reported every zone they sign.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.