DNSSEC with SHA-1 algorithms 5 and 7: why it no longer protects your zone
The short answer
RFC 9905 (November 2025) says zones must no longer be signed with RSASHA1 (5) or RSASHA1-NSEC3-SHA1 (7), and that validating resolvers must treat those signatures as unsupported. Your domain still resolves, but its answers are no longer validated: DNSSEC stops protecting you, with no error anywhere. The fix is an algorithm rollover, usually to 13 (ECDSA P-256).
The algorithm numbers, and what the RFCs say about signing with each
Find yours with dig DNSKEY example.com +short: the third number of each record is the algorithm. On the DS record at your registrar (dig DS example.com +short) it is the second number, and the third is the digest type.
| Number | Name | Use for signing |
|---|---|---|
1 | RSAMD5 | MUST NOT |
3 | DSA | MUST NOT |
5 | RSASHA1 | MUST NOT (RFC 9905; was NOT RECOMMENDED) |
6 | DSA-NSEC3-SHA1 | MUST NOT |
7 | RSASHA1-NSEC3-SHA1 | MUST NOT (RFC 9905; was NOT RECOMMENDED) |
8 | RSASHA256 | MUST |
10 | RSASHA512 | NOT RECOMMENDED |
13 | ECDSAP256SHA256 | MUST |
14 | ECDSAP384SHA384 | MAY |
15 | ED25519 | RECOMMENDED |
16 | ED448 | MAY |
SkyQon flags 1, 3, 5, 6 and 7 as weak, and a DS record with digest type 1 (SHA-1), which must not be used for delegation either; use digest type 2 (SHA-256). Sources: RFC 8624 §3.1 and §3.3, updated by RFC 9905.
What breaks, and who notices
- Validating resolvers stop checking your answers. RFC 9905 tells them to treat RSASHA1 and RSASHA1-NSEC3-SHA1 as unsupported, which makes your zone insecure rather than failed: answers are accepted, and a forged one is no longer caught. RFC 9905 §2
- No error, no outage. Nothing stops resolving, so nobody notices. A monitor that only asks "is DNSSEC on?" stays green.
- Some systems already refuse SHA-1. RFC 9905 notes that support for validating SHA-1 signatures has been removed from some systems, so your zone is unprotected for their users today.
- DANE goes with it. DANE records for your mail servers count only in a zone that validates. In a zone treated as insecure, senders ignore them. RFC 7672 §2.2
Check your DNSSEC algorithm
The free domain check reads your DS and DNSKEY records, tells you whether the chain from your registrar validates, and names the algorithm you sign with.
Free, no account. We read only public DNS and what your servers show to anyone who connects.
Fix it, step by step
See what you sign with today
Run dig DNSKEY example.com +short and dig DS example.com +short, or the free check. Note the algorithm numbers and the DS digest type.
Ask your DNS provider first
Most managed DNS providers roll the algorithm for you, on request or with one setting. If yours does, the only step left for you may be the new DS at your registrar.
Sign with both algorithms
Add new keys with the new algorithm, for example 13, and sign the zone with both the old and the new keys. Publish both sets of DNSKEY records.
Wait for caches
Wait at least the DNSKEY TTL plus the signature TTL, so every resolver has seen both sets of keys and signatures.
Replace the DS at your registrar
Add the DS for the new key with digest type 2 (SHA-256). Wait for the parent's DS TTL to pass, then remove the old DS.
Remove the old algorithm
Once the old DS has expired from caches, remove the old keys and their signatures. Then check again: the result should name the new algorithm and a chain that validates.
Common mistakes
Swapping the keys in one step
New keys only, while the parent still holds the old DS, breaks the chain. Validating resolvers then refuse to answer for your domain at all, which is an outage.
In SkyQon's result: “DNSSEC keys are published but our validating resolver did not return AD” when the chain does not validate.
Removing DNSSEC in the wrong order
Unsigning the zone while the DS is still at the registrar has the same effect: resolvers expect signatures and find none.
In SkyQon's result: “DS published at the parent but no DNSKEY at the zone apex — broken DNSSEC chain”.
Keeping a DS with digest type 1
A DS that uses the SHA-1 digest must not be used for delegation either. Replace it with digest type 2 during the rollover.
In SkyQon's result: a finding when a DS record uses digest type 1 (SHA-1), also when a SHA-256 one sits next to it. It does not change your score and sends no alert.
Moving to algorithm 10
RSASHA512 works, but RFC 8624 marks it NOT RECOMMENDED for signing, and its signatures are large.
In SkyQon's result: 8 and 10 are accepted, with a note that ECDSA P-256 or Ed25519 is preferred for new zones. Choose 13 if your provider supports it.
What SkyQon does and does not do
What it finds
Whether your zone is signed, whether the chain from your registrar validates, which algorithm numbers your DS and DNSKEY records use, and whether a DS record uses the SHA-1 digest. 1, 3, 5, 6 and 7 are flagged as weak.
What you get
The finding in the free check and on every scan of a monitored domain, with the algorithm named and the rollover steps.
What it is not
We do not change your keys or your DS records: that happens at your DNS provider and registrar. The SHA-1 digest finding does not change your score and sends no alert.
DNSSEC and SHA-1: questions people ask
Is my domain offline if it is signed with algorithm 5 or 7?
Which algorithm should I move to?
What is the difference between 5 and 7?
NSEC3 hashes names with SHA-1 as well. Is that a problem too?
How long does a rollover take?
Can I just switch DNSSEC off?
Does SkyQon's DANE check depend on this?
What does RFC 9905 change for DS records?
See which algorithm protects your zone.
The free check names your DNSSEC algorithm and tells you whether the chain validates. Add the domain to the free plan and every scan checks it again.