Algorithm Implementation Requirements and Usage Guidance for DNSSEC
obsoleted by
- rfc-9904 — DNSSEC Cryptographic Algorithm Recommendation Update Process
obsoletes
- rfc-6944 — Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status
updated by
- rfc-9157 — Revised IANA Considerations for DNSSEC
Extracted elements (26)
Algorithm deprecation is performed gradually through incremental updates rather than abrupt removal. An algorithm is expected to be downgraded from MUST to NOT RECOMMENDED or MAY (not MUST NOT) unless there are strong security reasons, allowing implementations time to adapt while maintaining interoperability.
ED25519 is expected to become the future RECOMMENDED default DNSKEY algorithm. EdDSA's key advantages are: no unique random number required per signature, no padding/truncation issues unlike ECDSA, and greater resilience to side-channel attacks and implementation errors.
RSASHA512 is NOT RECOMMENDED for signing despite having no significant cryptographic advantage over RSASHA256, because broader deployment would only make deprecation of older algorithms harder. Users wanting stronger algorithms should switch to elliptic curve cryptography.
Since using an unknown DNSKEY algorithm causes a zone to be treated as insecure (equivalent to unsigned), algorithms downgraded to NOT RECOMMENDED or lower should not be used by authoritative nameservers and DNSSEC signers for new DNSKEYs, allowing deprecated algorithms to gradually disappear.
The document uses the terms RECOMMENDED and NOT RECOMMENDED (rather than SHOULD and SHOULD NOT per RFC 2119) because these terms more clearly express intent to implementers, even though RFC 2119 treats them as equivalent.
It is RECOMMENDED to use the deterministic digital signature generation procedure (RFC 6979) when implementing ECDSAP256SHA256 and ECDSAP384SHA384, to avoid private key exposure from weak random number generation.
Recursive nameservers are encouraged to retain support for all algorithms not marked as MUST NOT, to maintain interoperability with zones still using older but not yet prohibited algorithms.
DSA (algorithm 3) and DSA-NSEC3-SHA1 (algorithm 6) MUST NOT be used for DNSSEC signing or validation. These algorithms are not widely deployed and are vulnerable to private key compromise when using a weak or compromised random number generator.
During a DS algorithm rollover, administrators MUST complete the DS algorithm upgrade before starting a rollover process for a new KSK; upgrading an algorithm simultaneously with a KSK rollover will cause DNSSEC validation failures.
ECC-GOST (algorithm 12) MUST NOT be used for DNSSEC signing; it MAY be supported for validation. It has been superseded by GOST R 34.10-2012, which has not been standardized for DNSSEC.
ECDSAP256SHA256 (algorithm 13) MUST be supported for both DNSSEC signing and validation. It is widely deployed and provides more cryptographic strength with shorter signatures than RSA-based algorithms.
ECDSAP256SHA256 is the RECOMMENDED DNSKEY algorithm for new DNSSEC deployments, and users of RSA-based algorithms SHOULD upgrade to ECDSAP256SHA256.
ECDSAP384SHA384 (algorithm 14) MAY be used for DNSSEC signing and is RECOMMENDED for validation. It offers 192-bit security strength versus 128-bit for ECDSAP256SHA256.
ED25519 (algorithm 15) is RECOMMENDED for both DNSSEC signing and validation. EdDSA does not require a unique random number per signature, avoids padding/truncation issues, and is more resilient to side-channel attacks.
ED448 (algorithm 16) MAY be used for DNSSEC signing and is RECOMMENDED for validation. It shares the advantages of ED25519 via the EdDSA algorithm.
For DS and CDS records, SHA-1 (digest type 1) MUST NOT be used to generate new DS and CDS records, but validators MUST implement SHA-1 validation due to its wide deployment.
RSAMD5 (algorithm 1) MUST NOT be used for DNSSEC signing and MUST NOT be used for DNSSEC validation. There is an industry-wide trend to deprecate MD5 usage.
RSASHA1 (algorithm 5) and RSASHA1-NSEC3-SHA1 (algorithm 7) are NOT RECOMMENDED for DNSSEC signing but MUST be supported for DNSSEC validation to maintain interoperability with widely deployed zones.
RSASHA256 (algorithm 8) MUST be supported for both DNSSEC signing and DNSSEC validation. It is widely used and considered strong.
RSASHA512 (algorithm 10) is NOT RECOMMENDED for DNSSEC signing but MUST be implemented for DNSSEC validation to ensure interoperability. There is no significant cryptographic strength difference between RSASHA512 and RSASHA256.
SHA-256 (DS digest type 2) MUST be supported for both DS/CDS delegation and validation. It is widely used, considered strong, and is the RECOMMENDED DS and CDS algorithm.
The NULL DS type (digest type 0, CDS only) MUST NOT be used for delegation or validation except as a special signal for DS removal at the parent as defined in RFC 8078.
DNSKEY algorithms covered by this document include RSAMD5 (1), DSA (3), RSASHA1 (5), DSA-NSEC3-SHA1 (6), RSASHA1-NSEC3-SHA1 (7), RSASHA256 (8), RSASHA512 (10), ECC-GOST (12), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14), ED25519 (15), and ED448 (16), each with distinct signing and validation requirement levels.
DS and CDS digest algorithms covered include NULL (0, CDS only), SHA-1 (1), SHA-256 (2), GOST R 34.11-94 (3), and SHA-384 (4), with separate recommendation levels for delegation use and validation.
Retiring an algorithm too quickly would cause zones signed with that algorithm to be downgraded to the equivalent of unsigned zones. Therefore, algorithm deprecation must be done very slowly and only after careful consideration and measurement of deployment levels.
The algorithms identified as MUST or RECOMMENDED are not known to be cryptographically broken at publication time, but new revisions of this document are expected periodically to reflect evolving best practices as cryptographic research advances.