The zone is signed with a deprecated algorithm
What this check looks for
Your zone is signed using cryptography that is no longer considered safe. Validators are being encouraged to stop accepting it, and some already treat it as no protection at all.
Why it matters
A signature nobody trusts provides no protection while still carrying every operational risk of DNSSEC. As validators drop support, the domain either loses its protection quietly or stops resolving, depending on how each one handles it.
When the check passes, your report says: “The zone is signed with a current, recommended algorithm”.
What it costs your score
When this check fails it removes 12 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.keys family ceiling of 20 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
- 12 points
- Family cap
- dnssec.keys · 20
- Category
- DNSSEC
- Module
- Dns dnssec
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Roll to algorithm 13 (ECDSA P-256) at your DNS host.
A signature made with a deprecated algorithm is protection that validators are withdrawing.
Check whether your DNS host offers an algorithm rollover as a managed operation — if it does, use it; doing it by hand is where outages come from.
An algorithm rollover requires the new algorithm's keys and signatures to be published alongside the old ones, then a new DS at the registrar, then removal of the old — in that order.
Do not remove the old DS until the new one is visible at the registry and resolvers are validating with it.
Confirm with a validating resolver at every step.
How to confirm it worked
dig +short DNSKEY ‹domain› — expect algorithm 13
delv ‹domain› A — expect "fully validated"
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
‹algorithm list›. Which algorithms may still be used for signing is recorded in IANA's DNS Security Algorithm Numbers registry, which is where RFC 9904 moved the recommendation when it obsoleted RFC 8624 — the table is now registry columns that age with the algorithms rather than prose fixed in an RFC.
The common case here is SHA-1: algorithms 5 (RSASHA1) and 7 (RSASHA1-NSEC3-SHA1) are **MUST NOT** for signing under RFC 9905, because chosen-prefix collisions against SHA-1 are practical. Note the asymmetry, because it is deliberate and it is not a contradiction: validators are still required to *support* those algorithms, so an old signature keeps validating while no new one may be made. ECC-GOST (algorithm 12) is deprecated outright by RFC 9906.
The modern choice is algorithm 13 (ECDSA P-256), which is universally supported and produces much smaller signatures than RSA.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.
Other dns dnssec checks
- Validating resolvers refuse to resolve the domain
- Signatures were read but not cryptographically verified
- The registry's DS record does not match any key in the zone
- The zone is signed but the registry has no DS record
- A DNSSEC key is shorter than the recommended size
- The zone's record names can be enumerated
- NSEC3 is configured with extra hash iterations
- NSEC3 opt-out weakens proof for unsigned subdomains
- DNSSEC could not be checked
- A DNSSEC signature has expired
- A DNSSEC signature expires within seven days
- The zone publishes keys but no signatures