DNSSEC is in the middle of a long-planned cryptographic cleanup. The short version that has been circulating among domain investors is correct: ICANN is pushing registrars and DNS operators off old algorithms, toward modern ones, and most domain holders will not have to lift a finger.
The longer version matters, because DNSSEC failures do not look like “your algorithm is deprecated.” They look like the domain is down for anyone whose resolver validates signatures. Getting the roles right — registrant versus DNS operator versus registrar versus registry — is the difference between a non-event and a SERVFAIL outage.
This article explains what changed, why it changed, how to tell whether a name is affected, and what each party should actually do.
What is being cleaned up
DNSSEC authenticates DNS data with public-key signatures. Every signed zone makes two independent cryptographic choices:
- Signing algorithm — the algorithm in
DNSKEYandRRSIGrecords (RSA/SHA-1, RSA/SHA-256, ECDSA P-256, Ed25519, and so on). - DS digest — the hash algorithm used in the parent’s
DSrecord, which is the fingerprint that links the child zone to the parent. Digest type 1 is SHA-1. Digest type 2 is SHA-256.
Those are not the same thing. A zone can be signed with a modern algorithm and still have a leftover SHA-1 DS at the registry. Both are in scope.
On 20 May 2026, ICANN’s Global Domains Division sent registrars a letter based on IETF RFCs 9904, 9905, and 9906 (published November 2025). The letter says operators MUST NOT use the following for new key generation or zone signing:
| Algorithm | IANA number | Status for new signing |
|---|---|---|
RSA/MD5 (RSAMD5) | 1 | MUST NOT |
| DSA / DSA-NSEC3-SHA1 | 3 / 6 | MUST NOT |
RSA/SHA-1 (RSASHA1) | 5 | MUST NOT |
RSA/SHA-1 with NSEC3 (RSASHA1-NSEC3-SHA1) | 7 | MUST NOT |
| ECC-GOST (GOST R 34.10-2001) | 12 | MUST NOT |
| SHA-1 as a DS digest | digest type 1 | MUST NOT for new DS records |
Recommended algorithms for current use:
| Algorithm | IANA number | Role |
|---|---|---|
RSA/SHA-256 (RSASHA256) | 8 | Still recommended. Very widely deployed. |
| ECDSA P-256 with SHA-256 | 13 | Recommended. Usual modern default. Smaller keys and signatures. |
| ECDSA P-384 with SHA-384 | 14 | Allowed / recommended for validation. Stronger curve, larger signatures. |
| Ed25519 | 15 | Recommended. Growing support. |
| SHA-256 DS digest | digest type 2 | The interoperability default for DS records. |
RSA/SHA-512 (algorithm 10) is not in the “must not use” bucket, but it is not recommended for new signing. It never saw broad deployment, and there is no good reason to pick it now.
ICANN also told registrars that all gTLD registry operators are contractually bound to follow the new guidance, so registrar systems may need updates to talk to some registries. That is the enforcement hook. The cryptographic policy itself comes from the IETF; ICANN is transmitting it into the contracted gTLD channel.
Why these algorithms are leaving
SHA-1 has been a known problem in digital signatures for a long time. NIST deprecated it for signatures in 2011. In DNSSEC specifically:
- RFC 8624 (June 2019) marked algorithms 5 and 7 as
NOT RECOMMENDEDfor signing, and said SHA-1 MUST NOT be used to create new DS records. That is the 2019 start date in the popular summary. - A 2020 chosen-prefix collision attack on SHA-1 was translated into a practical attack on DNSSEC-signed records. That ended any remaining argument that “SHA-1 is fine in this protocol.”
- RFC 9905 (November 2025) went further: do not create
DNSKEYorRRSIGrecords with RSASHA1 or RSASHA1-NSEC3-SHA1. Validators MUST treat those algorithms as unsupported for new trust, and MUST treat RSASHA1 DS records as insecure if no stronger DS exists. - RFC 9906 formally deprecated ECC-GOST, which was already almost unused outside a narrow national context.
- RFC 9904 moved the living recommendations into the IANA registries so the tables can be updated without waiting for another monolithic RFC.
DSA and RSA/MD5 were already dead for practical purposes. GOST R 34.10-2001 never had meaningful global deployment. The algorithms that still show up in the wild, and therefore still need an operational migration, are almost entirely 5 and 7 (RSA/SHA-1 variants) and SHA-1 DS records.
This is not a panic deprecation. Existing SHA-1 signatures can still be validated for interoperability while operators migrate. The rule is: stop making new ones, plan the transition, do not leave a zone with only a SHA-1 DS.
Two other 2026 DNSSEC events people keep mixing up
May 2026 is easy to confuse with two other root-zone projects.
11 October 2026 is a root KSK rollover, not an algorithm change. IANA is replacing the current root Key Signing Key (KSK-2017) with KSK-2024. The algorithm stays RSA/SHA-256. Domain holders do not change zone keys for this. The people who must care are operators of validating recursive resolvers, especially anyone with a manually pinned trust anchor.
A later root algorithm rollover is planned separately. ICANN has proposed moving the root KSK from RSA/SHA-256 to ECDSA P-256, with key generation targeted around 2027 and RSA retirement years after that. That is a multi-year root project. It is not the May 2026 registrar letter.
If a domain is not a recursive resolver, October 2026 is not this cleanup.
How common is the old stuff?
Most signed zones are already on acceptable algorithms. Among signed names, RSA/SHA-256 and ECDSA P-256 dominate. One 2025 snapshot of signed domains put algorithm 8 at about 58% and algorithm 13 at about 40%, with Ed25519 still small. ECDSA’s share has been rising quickly.
The leftover SHA-1 signing population is a thin tail. SIDN’s figures for .nl are a useful example because that TLD pushed DNSSEC harder than most: as of late 2024, algorithms 3, 5, and 7 together were under 0.1% of signed .nl names — a few thousand domains, not a mass of the zone. Algorithm 8 was still common and is not deprecated. SIDN’s advice to those operators was to go to algorithm 13 when convenient.
Globally, DNSSEC itself is still a minority feature at the second level. Signing rates vary wildly by TLD (very high in some European ccTLDs, low in large gTLDs). For a typical investor portfolio of parked or lightly used names, the modal state is still “not signed.”
That distribution is why “probably nothing” is the right default for registrants, and why the work sits with DNS operators who still have old signers.
What domain holders and registrants need to do
If the domain is not DNSSEC-signed: nothing
No DS at the parent and no DNSKEY/RRSIG in the zone means there is no algorithm to retire. This change does not require anyone to turn DNSSEC on.
That covers a large share of aftermarket, parked, and “point it at a landing page” names.
Do not enable DNSSEC just because of this letter. A misconfigured signed zone is worse than an unsigned one. Unsigned data is treated as insecure. Broken DNSSEC is treated as bogus, and validating resolvers refuse to answer.
If DNSSEC was enabled with a “one-click” at a major DNS host: almost nothing
Cloudflare, Amazon Route 53, Google Cloud DNS, Azure DNS, NS1, DNSimple, and similar platforms pick the algorithm for you. Most of them have been on algorithm 13, or at least algorithm 8, for years. The holder’s job is a 30-second check, not a rollover.
Confirm:
- DNSSEC still shows as enabled and valid after any nameserver or registrar transfer.
- The DS at the registry matches the current KSK.
- The algorithm is 8, 13, 14, or 15, and the DS digest type is 2.
If those are true, stop.
If you run your own authoritative DNS, or use a small/old signer: check, then maybe roll
This is the only registrant-adjacent case that can require work, and even then the work is usually done by whoever signs the zone.
Check both layers.
1. Look at the DS at the parent
dig DS example.com +shortA typical modern answer:
2371 13 2 32996839A6D808AFE3EB4A795A0E6A7A39A76FC52FF228B22B76F6D63826F2B9Reading the fields after the name and TTL:
- Key tag —
2371in the example. - Algorithm —
13(ECDSA P-256). This is the algorithm of the KSK being hashed. - Digest type —
2(SHA-256). This is the one that must not be1. - Digest — the hash itself.
Danger signs: algorithm 1, 3, 5, 6, 7, or 12; digest type 1.
2. Look at the keys in the child zone
dig DNSKEY example.com +multiThe DNSKEY flags tell KSK from ZSK (257 is usually the KSK, 256 the ZSK). The algorithm number is in the record. You can also inspect signatures:
dig example.com +dnssecand read the algorithm field in the RRSIG.
3. Use a visual validator
DNSViz and Verisign Labs DNSSEC Analyzer show the chain from the root through the TLD to the name, including algorithm numbers and digest types. If the chain is green and the numbers are modern, you are done.
4. Check after every transfer
The failure mode that actually bites domain investors is not “I am on algorithm 5.” It is “I transferred the name, the old DS is still at the registry, and the new nameservers are unsigned or use a different KSK.” That produces a bogus chain. Always inspect DS on acquisition, registrar change, and nameserver change.
Decision table for holders
| Situation | Action |
|---|---|
| No DS, no DNSKEY | None |
| Signed by a current platform, algorithm 8/13/14/15, DS digest 2, validator green | None |
| Algorithm 8 with SHA-256 DS | Compliant. Optional later move to 13 or 15. Not urgent. |
| Algorithm 5 or 7, or DS digest type 1 | Ask the DNS operator to roll. Do not edit DS by hand unless you know the timing. |
| DS present but nameservers changed / zone unsigned | Remove the stale DS or install matching keys. This is an outage, not a deprecation project. |
| Want DNSSEC for the first time | Use a provider that signs with 13 (or 8/15) and publishes digest-type-2 DS. |
Registrants should not generate keys, paste DS records, or “just change the algorithm” in a control panel unless they understand the order of operations below. The safe holder action is: detect, then hand the rollover to the signer.
What DNS operators will be doing
“DNS operator” here means whoever signs the zone: a managed-DNS company, a registrar’s DNS service, a hosting panel, an enterprise DNS team, or a TLD registry signing its own zone.
Their work is real. The holder’s work is usually not.
1. Inventory
Operators need a list of signed zones with:
- KSK algorithm
- ZSK algorithm
- DS digest type(s) at the parent
- Whether CDS/CDNSKEY automation is in use
- Software (BIND, Knot, NSD + OpenDNSSEC, PowerDNS, Cloud signer, custom)
- Whether the zone is multi-signer (two providers, RFC 8901)
Anything on algorithms 1, 3, 5, 6, 7, or 12 goes on the migration list. Anything with only a SHA-1 DS goes on the same list even if the zone keys are already modern.
2. Pick the target algorithm
Current best default for new signing is algorithm 13 (ECDSA P-256 / SHA-256). Reasons:
- Recommended by both IETF and the ICANN letter.
- Mandatory to implement for modern validators.
- Much smaller keys and signatures than 2048-bit RSA, which reduces truncation, fragmentation, and TCP fallback.
- Already the default in a lot of production software and several large ccTLDs (
.nlrolled its own TLD zone from 8 to 13 in 2023).
Acceptable alternatives:
- Algorithm 8 if a customer or appliance cannot do ECDSA yet. Still recommended.
- Algorithm 15 (Ed25519) if the entire resolver path you care about supports it. Support is good and growing, but 13 still has the broader installed base.
- Algorithm 14 if policy demands the larger curve. Rarely needed.
Also set DS generation to digest type 2. If a parent still has digest type 1, add type 2 first, then remove type 1 after TTL and cache decay.
3. Roll the algorithm, do not flip a flag
Changing algorithms is not the same as a same-algorithm ZSK roll. Classic DNSSEC rules expect the zone to be able to validate under both the old and new algorithms during the transition. In practice that means some period of dual signing, plus a carefully ordered DS change at the parent.
A conservative sequence, aligned with RFC 6781 / RFC 7583 thinking:
- Generate the new KSK and ZSK in the target algorithm.
- Publish the new
DNSKEYrecords alongside the old ones. - Sign the zone with both algorithms (dual RRSIGs) long enough for caches to see the new keys. Wait at least as long as the longest relevant TTL (DNSKEY TTL, plus parent DS TTL, plus a margin for lame or slow secondaries).
- Publish the new DS at the parent (digest type 2 of the new KSK). Leave the old DS in place during the overlap.
- Confirm validators and public checkers accept the chain on both algorithms.
- Remove the old DS only after the new DS is visible everywhere that matters.
- Stop signing with the old algorithm, then remove the old DNSKEYs after another TTL wait.
Get the order wrong — retire the old KSK before the new DS is in the parent, or publish a new-algorithm DS before the child is actually signed with that algorithm — and validating resolvers return SERVFAIL.
If the operator uses CDS/CDNSKEY (RFC 7344 / RFC 8078) and the parent supports DS automation, the parent update can be less manual. Many gTLDs still want the DS submitted through EPP by the registrar. That is why registrars are in the ICANN letter even when they do not sign the zone themselves.
4. Change signer defaults and refuse new old keys
Going forward, operators should:
- Default new zones to algorithm 13 (or 15, if that is their standard) and DS digest 2.
- Reject or warn on algorithms 1, 3, 5, 6, 7, 12 and on digest type 1.
- Update registrar/registry EPP templates so they no longer submit SHA-1 DS.
- Re-test multi-signer setups. Two providers with disjoint algorithm sets are a known sharp edge; RFC 8901 and later multi-algorithm drafts exist because this is easy to break during a provider migration.
5. Watch validation, not just publication
After a rollover, “the records are in the zone” is not success. Success is:
dig +dnssecshows RRSIGs for the new algorithm.- A validating resolver sets the
ADbit. - DNSViz / Verisign Analyzer are clean.
- Resolvers that already had the old DNSKEY cached still validate during the overlap.
- No sudden spike in
SERVFAILfrom 1.1.1.1, 8.8.8.8, or customer resolvers.
SIDN’s TLD-level rollover is the model: the public should not notice. That only happens if timing and DS publication are boring and correct.
6. Registries and registrars have extra work
The ICANN letter is aimed at the contracted channel.
- gTLD registries are expected to follow the new algorithm guidance. Some will stop accepting DS records that use forbidden algorithms or SHA-1 digests. EPP error codes will start showing up for stale registrar integrations.
- Registrars that offer DNSSEC as a button must make sure the button produces modern keys and digest-type-2 DS, and that their registry clients still work after registries tighten validation.
- ccTLDs are not under the same ICANN contract, but they follow the same RFCs. Several already moved their own TLD zones to algorithm 13.
Registrants will experience this, if at all, as a control-panel change or as “we can’t submit that DS anymore,” not as a homework assignment.
Edge cases that are easy to miss
Algorithm 8 is not deprecated. A holder who sees “RSA” and panics into an unnecessary rollover is taking real outage risk for no compliance gain. RSA/SHA-256 is still recommended. The cleanup target is SHA-1-based algorithms and SHA-1 DS, plus the already-dead MD5/DSA/GOST-2001 set.
A modern algorithm with a SHA-1 DS is still wrong. The parent digest is an independent knob. RFC 9905 is explicit that RSASHA1 DS should be treated as insecure. Upgrade the DS first if needed.
Unsigned with a leftover DS is an emergency. That is unrelated to May 2026 and far more common after marketplace transfers. Remove the DS or restore matching signatures immediately.
NSEC3 does not make SHA-1 acceptable. Algorithm 7 is RSA/SHA-1 plus NSEC3. It is in the same MUST NOT bucket as algorithm 5.
Validating resolvers and signing operators have opposite jobs. Resolvers should keep validating old algorithms until usage is gone, so leftover zones do not fall over. Signers should stop producing them. That asymmetry is deliberate.
This does not make DNSSEC mandatory. ICANN is not requiring every second-level name to be signed. It is requiring that if you sign, you do not use broken crypto.
Post-quantum is a later project. ICANN’s OCTO work on quantum computing and DNSSEC is about a future algorithm family, not this cleanup. Do not “upgrade to PQC” in 2026; there is no deployed DNSSEC PQC algorithm to move to yet. The current job is to get off SHA-1 and onto 8/13/15.
A compact checklist
Domain holder
- [ ] See whether the name has a DS record.
- [ ] If no: stop.
- [ ] If yes: confirm algorithm is 8, 13, 14, or 15 and digest type is 2.
- [ ] Run a public validator.
- [ ] After any transfer, confirm DS still matches the current signer.
- [ ] If the algorithm is 5, 7, or digest type 1, open a ticket with the DNS operator. Do not improvise a rollover.
DNS operator
- [ ] Inventory algorithms and DS digest types across all signed zones.
- [ ] Change new-zone defaults to algorithm 13 (or 8/15) and DS digest 2.
- [ ] Dual-sign and overlap DS records before retiring old keys.
- [ ] Drop SHA-1 DS only after digest-type-2 DS is live.
- [ ] Update EPP/registry integrations for the new MUST NOT list.
- [ ] Monitor
SERVFAILand external validators through the overlap window.
The accurate summary
DNSSEC is being cleaned up. The IETF deprecated RSA/SHA-1, DSA, GOST R 34.10-2001, RSA/MD5, and SHA-1 DS digests. ICANN spent May 2026 pushing that policy into the registrar and gTLD operator channel. The preferred landing zone is ECDSA P-256 with SHA-256 DS, with RSA/SHA-256 and Ed25519 also acceptable.
For most domain holders the operational content of that sentence is zero. For the people who actually sign zones, it is a measured migration: inventory, dual-sign, publish the new DS, wait, then tear down the old keys. The cost of doing that out of order is not a policy violation. It is a domain that validating resolvers will refuse to resolve.