RFC 9904

DNSSEC Cryptographic Algorithm Recommendation Update Process

📅 published November 2025, from ietf

🎀 RFC 9904 (Part 1 of 3) 🎀

DNSSEC Cryptographic Algorithm Recommendation Update Process 💖

Okay bestie, the title block is giving very official vibes. This one is from the IETF, written by W. Hardaker (USC/ISI) and W. Kumari (Google) 🧚. It's a Standards Track doc dated November 2025 with ISSN 2070-1721 🦋. It obsoletes RFC 8624 and updates RFC 9157, so it's doing a glow-up on the old algorithm list and adding new IANA stuff on top ✨.

Abstract

Okay so DNSSEC uses a bunch of cryptographic algorithms to authenticate DNS data and give proof of nonexistence 🔐. For DNS resolvers and DNS authoritative servers to actually work together, everyone needs a set of algorithm implementation requirements and usage guidelines, so there's always at least one algorithm that every implementation supports 🫶.

This document replaces and obsoletes RFC 8624 and moves the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from RFC 8624 into the IANA DNSSEC algorithm registries 📚. Why? So the list is way easier to update and reference. New registry extensions can show up in future RFCs 🌸. It also updates RFC 9157 and brings in the revised IANA DNSSEC considerations from that RFC 💅.

Not me changing the vibes, though 🙈. This document does not change the recommendation status (MUST, MAY, RECOMMENDED, etc.) of the algorithms listed in RFC 8624. That's the job of future documents 💜.

Status of This Memo

This is an Internet Standards Track document 🌈.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841 📖.

For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9904 🔗.

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved 📝.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this document 👀. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License ⚖️.

Table of Contents

1.  Introduction
  1.1.  Document Audience
  1.2.  Updating Algorithm Requirement Levels
  1.3.  Requirements Notation
2.  Adding Usage and Implementation Recommendations to the IANA
        DNSSEC Algorithm Registries
  2.1.  Column Descriptions
  2.2.  Adding and Changing Values
3.  DNS Security Algorithm Numbers Registry Column Values
4.  Digest Algorithms Registry Column Values
5.  Security Considerations
6.  Operational Considerations
7.  IANA Considerations
  7.1.  Update to the DNS Security Algorithm Numbers Registry
  7.2.  Update to the Digest Algorithms Registry
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction ✨

DNS Security Extensions, or DNSSEC, which is defined in [RFC9364], is what we use to authenticate DNS data 🔏. The DNSSEC signing algorithms come from a bunch of RFCs, including [RFC4034], [RFC4509], [RFC5155], [RFC5702], [RFC5933], [RFC6605], and [RFC8080] 📚.

For interoperability, there's a set of "mandatory-to-implement" DNS Public Key (DNSKEY) algorithms defined in [RFC8624] 🫶. To make the current status of these algorithms easier to find and understand, and to make future changes to these recommendations easier to publish, this document moves the canonical status of the algorithms from [RFC8624] into the IANA DNSSEC algorithm registries 🗂️. This document also brings in the revised IANA DNSSEC considerations from [RFC9157] 💅. As a bonus for operators, it adds recommendations for deploying and using these algorithms 🍓.

This is kind of like the "TLS Cipher Suites" registry [TLS-ciphersuites], where the canonical list of cipher suites lives in the IANA registry and RFCs just point to it 🌸.

1.1. Document Audience 🦋

The columns added to the IANA "DNS Security Algorithm Numbers" [DNSKEY-IANA] and "Digest Algorithms" [DS-IANA] registries are for DNSSEC operators and implementers 🧑‍💻.

Implementations need to meet high security expectations and also provide interoperability between different implementations and different versions 🔐.

The field of cryptography keeps evolving nonstop 🌈. New, stronger algorithms show up, and existing ones might turn out to be less secure than we thought 😭. So algorithm implementation requirements and usage guidance need updating from time to time 🔄. That keeps things in line with reality, allows a smooth transition to more secure algorithms, and handles deprecating algorithms that are no longer considered secure 👋.

Implementations need to be conservative about which algorithms they pick, so they can keep code complexity and the attack surface small 🛡️.

Operators who want to deploy and configure DNSSEC with only the safest algorithm may see things differently from implementers 👀. So this document also adds new recommendations about which algorithms should be deployed no matter what their implementation status is 💅. In general, deployment of aging algorithms should be reduced before implementations stop supporting them ⏳.

1.2. Updating Algorithm Requirement Levels 🔄

By the time a DNSSEC cryptographic algorithm is made mandatory to implement, it should already be available in most implementations ✨. This document sets up an IANA registration modification so future documents can specify implementation recommendations for each algorithm, since the recommendation status of each DNSSEC cryptographic algorithm is expected to change over time 🦋. For example, there's no guarantee that newly introduced algorithms will become mandatory to implement later 🤷‍♀️. And published algorithms keep getting poked at by cryptographic attacks. They might become too weak, or even completely broken, and will need deprecating down the line 💀.

Deprecation of an algorithm is expected to happen gradually 🐢. That gives implementations time to update their algorithms while staying interoperable 🫶. Unless there are strong security reasons, an algorithm is expected to be downgraded from MUST to NOT RECOMMENDED or MAY, instead of jumping straight from MUST to MUST NOT 🪜. Similarly, an algorithm that hasn't been mentioned as mandatory to implement is expected to first be introduced as RECOMMENDED instead of a MUST 🌱.

Using an unknown DNSKEY algorithm makes the zone get treated as insecure 😬. So it is recommended that algorithms downgraded to NOT RECOMMENDED or lower not be used by authoritative nameservers and DNSSEC signers to create new DNSKEYs 🚫. This keeps deprecated algorithms fading out over time 📉. Once an algorithm reaches a low enough level of deployment, it can be marked as MUST NOT so recursive resolvers can drop support for validating it 🗑️.

Validating recursive resolvers are encouraged to keep support for all algorithms not marked as MUST NOT 💜.

1.3. Requirements Notation 📜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎯.

[RFC2119] treats the term SHOULD as equivalent to RECOMMENDED, and SHOULD NOT as equivalent to NOT RECOMMENDED. This document uses the terms RECOMMENDED and NOT RECOMMENDED because they more clearly express the recommendations to implementers 💅.

2. Adding Usage and Implementation Recommendations to the IANA DNSSEC Algorithm Registries 🗂️

Per this document, the following columns have been added to the corresponding DNSSEC algorithm registries maintained by IANA. Here's the tea, in table form 🍵:

+================================+=================================+
| Registry                       | Column Added                    |
+================================+=================================+
| DNS Security Algorithm Numbers | Use for DNSSEC Signing          |
+--------------------------------+---------------------------------+
| DNS Security Algorithm Numbers | Use for DNSSEC Validation       |
+--------------------------------+---------------------------------+
| DNS Security Algorithm Numbers | Implement for DNSSEC Signing    |
+--------------------------------+---------------------------------+
| DNS Security Algorithm Numbers | Implement for DNSSEC Validation |
+--------------------------------+---------------------------------+
| Digest Algorithms              | Use for DNSSEC Delegation       |
+--------------------------------+---------------------------------+
| Digest Algorithms              | Use for DNSSEC Validation       |
+--------------------------------+---------------------------------+
| Digest Algorithms              | Implement for DNSSEC Delegation |
+--------------------------------+---------------------------------+
| Digest Algorithms              | Implement for DNSSEC Validation |
+--------------------------------+---------------------------------+

   Table 1: Columns Added to Existing DNSSEC Algorithm Registries

2.1. Column Descriptions 💁‍♀️

The four columns in the "DNS Security Algorithm Numbers" registry work like this 💖:

  • Use for DNSSEC Signing: shows the recommendation for using the algorithm within authoritative servers 🖊️.
  • Use for DNSSEC Validation: shows the recommendation for using the algorithm in DNSSEC validators ✅.
  • Implement for DNSSEC Signing: shows the recommendation for implementing the algorithm within DNSSEC signing software 💻.
  • Implement for DNSSEC Validation: shows the recommendation for implementing the algorithm within DNSSEC validators 🛠️.

The four columns in the "Digest Algorithms" registry work like this 🦋:

  • Use for DNSSEC Delegation: shows the recommendation for using the algorithm within authoritative servers 🏰.
  • Use for DNSSEC Validation: shows the recommendation for using the algorithm in DNSSEC validators ✅.
  • Implement for DNSSEC Delegation: shows the recommendation for implementing the algorithm within authoritative servers 🧩.
  • Implement for DNSSEC Validation: shows the recommendation for implementing the algorithm within validating resolvers 🔍.

2.2. Adding and Changing Values ✨

okay bestie, so this is the part about how people add or change stuff in the registries 💅 The IETF dropped a note onto the "DNS Security Algorithm Numbers" registry, and it's basically the rulebook:

|  Adding a new entry to the "DNS Security Algorithm Numbers"
|  registry with a recommended value of "MAY" in the "Use for DNSSEC
|  Signing", "Use for DNSSEC Validation", "Implement for DNSSEC
|  Signing", or "Implement for DNSSEC Validation" columns will be
|  subject to the Specification Required policy as defined in
|  [RFC8126] in order to promote continued evolution of DNSSEC
|  algorithms and DNSSEC agility.  New entries added through the
|  Specification Required process will have the value of "MAY" for
|  all columns.
|
|  Adding a new entry to, or changing an existing value in, the "DNS
|  Security Algorithm Numbers" registry that has any value other than
|  "MAY" in the "Use for DNSSEC Signing", "Use for DNSSEC
|  Validation", "Implement for DNSSEC Signing", or "Implement for
|  DNSSEC Validation" columns requires Standards Action.
|
|  If an item is not marked as "RECOMMENDED", it does not necessarily
|  mean that it is flawed; rather, it indicates that the item either
|  has not been through the IETF consensus process, has limited
|  applicability, or is intended only for specific use cases.

And the "Digest Algorithms" registry got its own version of the note 🌸

|  Adding a new entry to the "Digest Algorithms" registry with a
|  recommended value of "MAY" in the "Use for DNSSEC Delegation",
|  "Use for DNSSEC Validation", "Implement for DNSSEC Delegation", or
|  "Implement for DNSSEC Validation" columns SHALL follow the
|  Specification Required policy as defined in [RFC8126].
|
|  Adding a new entry to, or changing an existing value in, the
|  "Digest Algorithms" registry that has any value other than "MAY"
|  in the "Use for DNSSEC Delegation", "Use for DNSSEC Validation",
|  "Implement for DNSSEC Delegation", or "Implement for DNSSEC
|  Validation" columns requires Standards Action.
|
|  If an item is not marked as "RECOMMENDED", it does not necessarily
|  mean that it is flawed; rather, it indicates that the item either
|  has not been through the IETF consensus process, has limited
|  applicability, or is intended only for specific use cases.

Now the vibe check on which values are allowed where 👑 For the "Use for DNSSEC Signing" and "Use for DNSSEC Validation" columns, the only legit picks are the ones below:

Only values of "MAY", "RECOMMENDED", "MUST NOT", and "NOT RECOMMENDED" may be placed into the "Use for DNSSEC Signing" and "Use for DNSSEC Validation" columns.

For the "Implement for DNSSEC Signing" and "Implement for DNSSEC Validation" columns, you get one extra option:

Only values of "MAY", "RECOMMENDED", "MUST", "MUST NOT", and "NOT RECOMMENDED" may be placed into the "Implement for DNSSEC Signing" and "Implement for DNSSEC Validation" columns.

And the "MUST" value is the one that's banned from the two "Use for" columns, so don't even try 🙅‍♀️

Note that a value of "MUST" is not an allowed value for the two "Use for" columns.

The starting values in the next sections came from a couple of places. The "Implement for" columns were copied over from [RFC8624] 🧚 The "Use for" columns were set to match them, because people have basically been treating these values as applying to both use and implementation. One thing to watch: whenever the "Implement for" value is "MUST", the "Use for" value is "RECOMMENDED" instead.

Note that the value in the "Use for" column is "RECOMMENDED" when the value in the corresponding "Implement for" column is "MUST".

The IETF also called out that these two could drift apart later, since implementations usually show up before deployments do ✨

3. DNS Security Algorithm Numbers Registry Column Values 🎀

The starting values for the use and implementation recommendation columns in the "DNS Security Algorithm Numbers" registry (which lives under the "Domain Name System Security (DNSSEC) Algorithm Numbers" registry group) are all laid out in Table 2 💖

When there are multiple RECOMMENDED algorithms in the "Use for" columns, operators should choose the best algorithm according to local policy.

   +===+===============+===========+===========+===========+===========+
   |No.|Mnemonics      |Use for    |Use for    |Implement  |Implement  |
   |   |               |DNSSEC     |DNSSEC     |for DNSSEC |for DNSSEC |
   |   |               |Signing    |Validation |Signing    |Validation |
   +===+===============+===========+===========+===========+===========+
   |1  |RSAMD5         |MUST NOT   |MUST NOT   |MUST NOT   |MUST NOT   |
   +---+---------------+-----------+-----------+-----------+-----------+
   |3  |DSA            |MUST NOT   |MUST NOT   |MUST NOT   |MUST NOT   |
   +---+---------------+-----------+-----------+-----------+-----------+
   |5  |RSASHA1        |NOT        |RECOMMENDED|NOT        |MUST       |
   |   |               |RECOMMENDED|           |RECOMMENDED|           |
   +---+---------------+-----------+-----------+-----------+-----------+
   |6  |DSA-NSEC3-SHA1 |MUST NOT   |MUST NOT   |MUST NOT   |MUST NOT   |
   +---+---------------+-----------+-----------+-----------+-----------+
   |7  |RSASHA1-NSEC3- |NOT        |RECOMMENDED|NOT        |MUST       |
   |   |SHA1           |RECOMMENDED|           |RECOMMENDED|           |
   +---+---------------+-----------+-----------+-----------+-----------+
   |8  |RSASHA256      |RECOMMENDED|RECOMMENDED|MUST       |MUST       |
   +---+---------------+-----------+-----------+-----------+-----------+
   |10 |RSASHA512      |NOT        |RECOMMENDED|NOT        |MUST       |
   |   |               |RECOMMENDED|           |RECOMMENDED|           |
   +---+---------------+-----------+-----------+-----------+-----------+
   |12 |ECC-GOST       |MUST NOT   |MAY        |MUST NOT   |MAY        |
   +---+---------------+-----------+-----------+-----------+-----------+
   |13 |ECDSAP256SHA256|RECOMMENDED|RECOMMENDED|MUST       |MUST       |
   +---+---------------+-----------+-----------+-----------+-----------+
   |14 |ECDSAP384SHA384|MAY        |RECOMMENDED|MAY        |RECOMMENDED|
   +---+---------------+-----------+-----------+-----------+-----------+
   |15 |ED25519        |RECOMMENDED|RECOMMENDED|RECOMMENDED|RECOMMENDED|
   +---+---------------+-----------+-----------+-----------+-----------+
   |16 |ED448          |MAY        |RECOMMENDED|MAY        |RECOMMENDED|
   +---+---------------+-----------+-----------+-----------+-----------+
   |17 |SM2SM3         |MAY        |MAY        |MAY        |MAY        |
   +---+---------------+-----------+-----------+-----------+-----------+
   |23 |ECC-GOST12     |MAY        |MAY        |MAY        |MAY        |
   +---+---------------+-----------+-----------+-----------+-----------+
   |253|PRIVATEDNS     |MAY        |MAY        |MAY        |MAY        |
   +---+---------------+-----------+-----------+-----------+-----------+
   |254|PRIVATEOID     |MAY        |MAY        |MAY        |MAY        |
   +---+---------------+-----------+-----------+-----------+-----------+

       Table 2: Initial Values for the DNS Security Algorithm Numbers
                              Registry Columns

4. Digest Algorithms Registry Column Values 🍓

Over in the "Digest Algorithms" registry (under the "DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" registry group), the starting values are in Table 3 ✨

When there are multiple RECOMMENDED algorithms in the "Use for" columns, operators should choose the best algorithm according to local policy.

   +=====+===========+===========+===========+==========+=============+
   |Value|Description|Use for    |Use for    |Implement | Implement   |
   |     |           |DNSSEC     |DNSSEC     |for DNSSEC| for DNSSEC  |
   |     |           |Delegation |Validation |Delegation| Validation  |
   +=====+===========+===========+===========+==========+=============+
   |0    |NULL (CDS  |MUST NOT   |MUST NOT   |MUST NOT  | MUST NOT    |
   |     |only)      |           |           |          |             |
   +-----+-----------+-----------+-----------+----------+-------------+
   |1    |SHA-1      |MUST NOT   |RECOMMENDED|MUST NOT  | MUST        |
   +-----+-----------+-----------+-----------+----------+-------------+
   |2    |SHA-256    |RECOMMENDED|RECOMMENDED|MUST      | MUST        |
   +-----+-----------+-----------+-----------+----------+-------------+
   |3    |GOST R     |MUST NOT   |MAY        |MUST NOT  | MAY         |
   |     |34.11-94   |           |           |          |             |
   +-----+-----------+-----------+-----------+----------+-------------+
   |4    |SHA-384    |MAY        |RECOMMENDED|MAY       | RECOMMENDED |
   +-----+-----------+-----------+-----------+----------+-------------+
   |5    |GOST R     |MAY        |MAY        |MAY       | MAY         |
   |     |34.11-2012 |           |           |          |             |
   +-----+-----------+-----------+-----------+----------+-------------+
   |6    |SM3        |MAY        |MAY        |MAY       | MAY         |
   +-----+-----------+-----------+-----------+----------+-------------+

    Table 3: Initial Values for the Digest Algorithms Registry Columns

5. Security Considerations 🔥

okay this section is the serious one, so buckle up 😭 Crypto security depends on two things at once: how strong the algorithms are, and how strong the keys you use with them are. And even great crypto can get wrecked if the protocol around it has a sneaky non-cryptographic way to bypass the whole system. Yikes.

This document is all about picking cryptographic algorithms for DNSSEC, specifically the "mandatory-to-implement" ones. The algorithms marked MUST or RECOMMENDED to implement here aren't known to be broken right now, and the research so far suggests they'll stay pretty secure unless something big and unexpected turns up. But that's not forever 💀 Future documents are expected to come out from time to time to reflect current best practices in this area.

Retiring an algorithm too soon is a disaster 🙈 A zone signed with the retired algorithm would get downgraded to the equivalent of an unsigned zone. So algorithm deprecation must be done only after careful consideration, and ideally slowly when possible.

6. Operational Considerations 🌈

Rolling over a DNSKEY algorithm in a live zone is a complicated process 🫠 For guidance on how to do algorithm rollovers, check out [RFC6781] and [RFC7583].

DS algorithm rollover in a live zone is also complex. If you upgrade the algorithm at the same time you roll to a new Key Signing Key (KSK), DNSSEC validation failures are coming for you. So users MUST upgrade the DS algorithm first before rolling to a new KSK 👑

7. IANA Considerations 🦋

IANA updated the "DNS Security Algorithm Numbers" [DNSKEY-IANA] and "Digest Algorithms" [DS-IANA] registries according to the sections that follow ✨

7.1. Update to the DNS Security Algorithm Numbers Registry 💅

IANA updated the "DNS Security Algorithm Numbers" registry [DNSKEY-IANA] with the following columns, and filled them in with the values from Table 2 of this document:

  • "Use for DNSSEC Signing"
  • "Use for DNSSEC Validation"
  • "Implement for DNSSEC Signing"
  • "Implement for DNSSEC Validation"

IANA also finished these actions for the "DNS Security Algorithm Numbers" registry [DNSKEY-IANA]:

  • Changed the registration procedure to Standards Action or Specification Required.
  • Added a note to the registry that describes the values not marked as "RECOMMENDED" per Section 2.2.
  • Listed this document as an additional reference for the registry.

7.2. Update to the Digest Algorithms Registry

okay so IANA also gave the "Digest Algorithms" registry [DS-IANA] a glow-up 💅✨ They added four new columns and filled them in with the values from Table 3 of this document:

  • "Use for DNSSEC Delegation" 🎀
  • "Use for DNSSEC Validation" 🎀
  • "Implement for DNSSEC Delegation" 🌸
  • "Implement for DNSSEC Validation" 🌸

IANA also did a few more things to that registry 🫶

  • Changed the registration procedure to Standards Action or Specification Required. 📜
  • Added a note to the registry describing the values that are not marked as "RECOMMENDED" per Section 2.2. 🙈
  • Listed this document as an additional reference for the registry. 🦋
  • Marked values 128-252 as "Reserved". 🚫
  • Marked values 253 and 254 as "Reserved for Private Use". 🔒
  • Deleted the (now superfluous) column "Status" from the registry. 🗑️ It was giving redundant, so it had to go. 💀

8. References

8.1. Normative References

8.2. Informative References

Acknowledgments ✨

This document is based on, and extends, RFC 8624, which was written by Paul Wouters and Ondrej Sury. 🫶

The DNSOP Working Group had SO many big feelings about this document 😭 Everyone's opinions were thoughtful, and all of them helped shape it into what it is now. 🌈 Huge thanks to Paul Hoffman and Paul Wouters for their contributed text, and to Nabeel Cocker, Shumon Huque, Nicolai Leymann, S. Moonesamy, Magnus Nyström, Peter Thomassen, Stefan Ubbink, and Loganaden Velvindron for their reviews and comments. 💜

Authors' Addresses

Wes Hardaker USC/ISI Email: ietf@hardakers.net

Warren Kumari Google Email: warren@kumari.net 🧚

📦 where this page comes from