DNSSEC Cryptographic Algorithm Recommendation Update Process
obsoletes
- rfc-8624 — Algorithm Implementation Requirements and Usage Guidance for DNSSEC
updates
- rfc-9157 — Revised IANA Considerations for DNSSEC
Extracted elements (17)
Algorithm deprecation is expected to be performed gradually: an algorithm should be downgraded from MUST to NOT RECOMMENDED or MAY before being marked MUST NOT, unless there are strong security reasons for an immediate change. Similarly, new algorithms should be introduced as RECOMMENDED before being elevated to MUST.
Only values of 'MAY', 'RECOMMENDED', 'MUST NOT', and 'NOT RECOMMENDED' may be placed in the 'Use for' columns; 'MUST' is explicitly not allowed there. The 'Implement for' columns additionally allow 'MUST'. This distinction separates deployment guidance from implementation requirements.
The document separates 'Use for' (operator/deployment guidance) columns from 'Implement for' (software implementation guidance) columns because implementations generally precede deployments; these two recommendation levels may diverge in the future as algorithms are phased out.
The 'Use for' column values were initially set equal to the 'Implement for' column values (transcribed from RFC 8624), since historical interpretation treated them as covering both use and implementation. Where 'Implement for' is 'MUST', 'Use for' is set to 'RECOMMENDED', as 'MUST' is not permitted in 'Use for' columns.
This document moves the canonical source of DNSSEC algorithm implementation requirements and usage guidance from RFC 8624 to the IANA DNSSEC algorithm registries, modeled after the TLS Cipher Suites registry approach. This allows the list of requirements to be updated and referenced without requiring a new RFC for each change.
Since the effect of using an unknown DNSKEY algorithm is that the zone is treated as insecure (not as invalid), the gradual deprecation approach ensures resolvers continue to validate zones using older algorithms until deployment of those algorithms is sufficiently low to mark them MUST NOT.
When multiple RECOMMENDED algorithms exist in the 'Use for' columns of either registry, operators should choose the best algorithm according to local policy, allowing flexibility without mandating a single signing or delegation algorithm.
Adding a new entry to, or changing an existing value in, the 'DNS Security Algorithm Numbers' registry with any value other than 'MAY' in any recommendation column requires Standards Action.
Adding a new entry to the 'Digest Algorithms' registry with 'MAY' in any recommendation column SHALL follow the Specification Required policy. Adding or changing entries with values other than 'MAY' requires Standards Action.
Adding a new entry to the 'DNS Security Algorithm Numbers' registry with a recommended value of 'MAY' in any of the four recommendation columns is subject to Specification Required policy. New entries added through Specification Required will have 'MAY' for all columns.
Algorithms downgraded to NOT RECOMMENDED or lower SHOULD NOT be used by authoritative nameservers and DNSSEC signers to create new DNSKEYs, since using an unknown DNSKEY algorithm causes a zone to be treated as insecure.
During a DS algorithm rollover, users MUST upgrade the DS algorithm first before rolling to a new Key Signing Key (KSK); upgrading the algorithm simultaneously with a KSK roll will lead to DNSSEC validation failures.
Validating recursive resolvers are encouraged to retain support for all algorithms not marked as MUST NOT, to support gradual deprecation and interoperability during algorithm transitions.
The initial 'Digest Algorithms' registry values (Table 3) set SHA-256 (2) as RECOMMENDED/MUST for delegation and validation. SHA-1 (1) is MUST NOT for delegation but MUST for validation implementation and RECOMMENDED for validation use. NULL (0) and GOST R 34.11-94 (3) are MUST NOT for delegation.
The initial 'DNS Security Algorithm Numbers' registry values (Table 2) set RSASHA256 (8) and ECDSAP256SHA256 (13) as RECOMMENDED/MUST for both signing and validation. RSAMD5 (1), DSA (3), and DSA-NSEC3-SHA1 (6) are MUST NOT across all columns. ED25519 (15) is RECOMMENDED for all four columns.
Four new columns were added to the IANA 'Digest Algorithms' registry: 'Use for DNSSEC Delegation', 'Use for DNSSEC Validation', 'Implement for DNSSEC Delegation', and 'Implement for DNSSEC Validation'. These capture recommendation levels for DS digest algorithm use and implementation.
Algorithms identified as MUST or RECOMMENDED to implement are not known to be broken at the current time, but future documents will be issued to reflect changing best practices. Retiring an algorithm too soon would downgrade signed zones to the equivalent of unsigned zones, so deprecation must be done carefully and slowly.