跳到主要内容

RFC 9904 - DNSSEC Cryptographic Algorithm Recommendation Update Process

  • 状态: Proposed Standard
  • 发布日期: November 2025
  • Stream: IETF
  • 更新了: RFC9157
  • 废弃了: RFC8624
  • 勘误: 无勘误

摘要​

DNSSEC protocol 使用多种 cryptographic algorithms 来提供 DNS data 的认证和不存在性证明. 为确保 DNS resolvers 和 DNS authoritative servers 之间的互操作性, 有必要指定一组 algorithm implementation requirements 和 usage guidelines, 以确保至少存在一种所有实现都支持的算法. 本文档替换并废弃 RFC 8624, 并将 DNSSEC 的 algorithm implementation requirements 和 usage guidance 的规范来源从 RFC 8624 移至 IANA DNSSEC algorithm registries. 这样做是为了让要求列表更容易更新和引用. 未来 RFC 可以扩展这些 registries. 本文档还更新 RFC 9157, 并纳入该 RFC 修订后的 IANA DNSSEC 考虑事项.

本文档不会改变 RFC 8624 中所列算法的 recommendation status (MUST, MAY, RECOMMENDED 等). 这属于未来文档的工作.

本备忘录状态​

本文是 Internet Standards Track 文档.

本文是 Internet Engineering Task Force (IETF) 的产物. 它代表 IETF 社区的共识. 它已经过公开评审, 并已由 Internet Engineering Steering Group (IESG) 批准发布. 有关 Internet Standards 的更多信息见 RFC 7841 第 2 节.

有关本文档当前状态, 任何勘误以及如何提供反馈的信息, 可从 https://www.rfc-editor.org/info/rfc9904 获取.

版权声明​

Copyright (c) 2025 IETF Trust 以及被标识为文档作者的人员. 保留所有权利.

本文档受 BCP 78 以及 IETF Trust 关于 IETF 文档的法律条款 (https://trustee.ietf.org/license-info) 的约束, 以本文档发布之日生效的版本为准. 请仔细审阅这些文档, 它们描述了您就本文档所享有的权利和限制. 从本文档中提取的代码组件必须包含 Trust 法律条款第 4.e 节所述的 Revised BSD License 文本, 并且按 Revised BSD License 所述不提供任何担保.

目录​

1. 简介​

"DNS 安全扩展 (DNSSEC)" [RFC9364] 用于提供 DNS 数据的认证. DNSSEC 签名算法由多个 RFC 定义, 包括 [RFC4034], [RFC4509], [RFC5155], [RFC5702], [RFC5933], [RFC6605] 和 [RFC8080].

为确保互操作性, [RFC8624] 定义了一组强制实现 ("mandatory-to-implement") 的 DNS 公钥 (DNSKEY) 算法. 为了让算法的当前状态更易于获取和理解, 并使未来对这些建议的变更更易于发布, 本文档将算法的规范状态从 [RFC8624] 移至 IANA DNSSEC 算法注册表. 本文档还纳入了 [RFC9157] 中修订后的 IANA DNSSEC 考虑事项. 此外, 作为对运营者的建议, 本文档还增加了关于部署和使用这些算法的建议.

这类似于 "TLS Cipher Suites" 注册表 [TLS-ciphersuites] 所使用的流程: 密码套件的规范列表保存在 IANA 注册表中, 而 RFC 则引用该 IANA 注册表.

1.1 文档受众​

添加到 IANA "DNS Security Algorithm Numbers" [DNSKEY-IANA] 和 "Digest Algorithms" [DS-IANA] 注册表中的各列面向 DNSSEC 运营者和实现者.

实现需要在满足高安全期望的同时, 提供各种实现之间以及不同版本之间的互操作性.

密码学领域在持续演进. 新的更强的算法不断出现, 而现有算法可能被发现不如最初认为的那样安全. 因此, 算法实现要求和使用指南需要不时更新, 以反映新的现实, 并实现向更安全算法的平滑过渡, 以及废弃那些被认为不再安全的算法.

实现在选择所要实现的算法时需要保持保守, 以尽量降低代码复杂性和攻击面.

实现者的视角可能与希望只使用最安全算法来部署和配置 DNSSEC 的运营者不同. 因此, 本文档还增加了一些新建议, 说明无论实现状态如何都应部署哪些算法. 总体而言, 预期老旧算法的部署应普遍在实现停止支持之前先行减少.

1.2 更新算法要求级别​

当某个 DNSSEC 密码算法被定为强制实现时, 它应当已经在大多数实现中可用. 由于每个 DNSSEC 密码算法的建议状态预期都会随时间变化, 本文档定义了一种 IANA 注册表修改, 允许未来的文档为每个算法指定实现建议. 例如, 无法保证新引入的算法未来会成为强制实现的算法. 同样, 已发布的算法会持续遭受密码学攻击, 可能变得过弱, 甚至被完全攻破, 从而在未来需要被废弃.

算法的废弃预计将逐步进行. 这为实现在保持互操作性的同时更新其所实现的算法留出了时间. 除非存在强烈的安全理由, 算法预期从 MUST 降级为 NOT RECOMMENDED 或 MAY, 而不是直接从 MUST 降为 MUST NOT. 类似地, 从未被列为强制实现的算法, 预期首先以 RECOMMENDED 引入, 而不是直接定为 MUST.

由于使用未知 DNSKEY 算法的效果是区 (zone) 被视为不安全, 因此建议权威域名服务器和 DNSSEC 签名器不要使用已降级为 NOT RECOMMENDED 或更低的算法来创建新的 DNSKEY. 这确保被废弃算法的使用随时间递减. 一旦某个算法的部署水平降到足够低, 就可以将其标记为 MUST NOT, 以便递归解析器移除对其验证的支持.

鼓励验证型递归解析器保留对所有未标记为 MUST NOT 的算法的支持.

1.3 要求术语​

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 仅当它们如上所示以全大写形式出现时, 才按照 BCP 14 [RFC2119] [RFC8174] 所述进行解释.

[RFC2119] 认为 SHOULD 等同于 RECOMMENDED, SHOULD NOT 等同于 NOT RECOMMENDED. 本文档选择使用 RECOMMENDED 和 NOT RECOMMENDED 这两个术语, 因为它们更清晰地向实现者表达了建议.

2. 向 IANA DNSSEC 算法注册表添加使用与实现建议​

根据本文档, 以下各列已被添加到 IANA 维护的相应 DNSSEC 算法注册表中:

| 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 |

表 1: 向现有 DNSSEC 算法注册表添加的列

2.1 列说明​

"DNS Security Algorithm Numbers" 注册表中四列的预期用途如下:

Use for DNSSEC Signing: 表示在权威域名服务器中使用该算法的建议.

Use for DNSSEC Validation: 表示在 DNSSEC 验证器中使用该算法的建议.

Implement for DNSSEC Signing: 表示在 DNSSEC 签名软件中实现该算法的建议.

Implement for DNSSEC Validation: 表示在 DNSSEC 验证器中实现该算法的建议.

"Digest Algorithms" 注册表中四列的预期用途如下:

Use for DNSSEC Delegation: 表示在权威域名服务器中使用该算法的建议.

Use for DNSSEC Validation: 表示在 DNSSEC 验证器中使用该算法的建议.

Implement for DNSSEC Delegation: 表示在权威域名服务器中实现该算法的建议.

Implement for DNSSEC Validation: 表示在验证型解析器中实现该算法的建议.

2.2 值的添加与变更​

以下说明描述了添加和变更值的流程, 已被添加到 "DNS Security Algorithm Numbers" 注册表中:

向 "DNS Security Algorithm Numbers" 注册表添加新条目时, 若其在 "Use for DNSSEC Signing", "Use for DNSSEC Validation", "Implement for DNSSEC Signing" 或 "Implement for DNSSEC Validation" 列中的推荐值为 "MAY", 则将适用 [RFC8126] 中定义的 Specification Required 政策, 以促进 DNSSEC 算法和 DNSSEC 敏捷性的持续演进. 通过 Specification Required 流程添加的新条目在所有列中的值均为 "MAY".

向 "DNS Security Algorithm Numbers" 注册表添加新条目或变更现有值时, 若其在 "Use for DNSSEC Signing", "Use for DNSSEC Validation", "Implement for DNSSEC Signing" 或 "Implement for DNSSEC Validation" 任一列中的值不是 "MAY", 则需要 Standards Action.

某一项未被标记为 "RECOMMENDED" 并不一定意味着它有缺陷; 这只表明该项要么尚未经过 IETF 共识流程, 要么适用范围有限, 要么仅面向特定使用场景.

以下说明已被添加到 "Digest Algorithms" 注册表:

向 "Digest Algorithms" 注册表添加新条目时, 若其在 "Use for DNSSEC Delegation", "Use for DNSSEC Validation", "Implement for DNSSEC Delegation" 或 "Implement for DNSSEC Validation" 列中的推荐值为 "MAY", 则必须遵循 [RFC8126] 中定义的 Specification Required 政策.

向 "Digest Algorithms" 注册表添加新条目或变更现有值时, 若其在 "Use for DNSSEC Delegation", "Use for DNSSEC Validation", "Implement for DNSSEC Delegation" 或 "Implement for DNSSEC Validation" 任一列中的值不是 "MAY", 则需要 Standards Action.

某一项未被标记为 "RECOMMENDED" 并不一定意味着它有缺陷; 这只表明该项要么尚未经过 IETF 共识流程, 要么适用范围有限, 要么仅面向特定使用场景.

只有 "MAY", "RECOMMENDED", "MUST NOT" 和 "NOT RECOMMENDED" 这些值可以被放入 "Use for DNSSEC Signing" 和 "Use for DNSSEC Validation" 列. 只有 "MAY", "RECOMMENDED", "MUST", "MUST NOT" 和 "NOT RECOMMENDED" 这些值可以被放入 "Implement for DNSSEC Signing" 和 "Implement for DNSSEC Validation" 列. 注意, "MUST" 不是两个 "Use for" 列允许的取值.

以下各节给出已填入这些列的初始值. "Implement for" 各列的值转录自 [RFC8624]. "Use for" 各列被设置为与 "Implement for" 各列相同的值, 因为迄今为止的一般解读表明, 这些值一直被同时当作 "使用" 和 "实现" 两方面的取值. 注意, 当对应 "Implement for" 列的值为 "MUST" 时, "Use for" 列的值为 "RECOMMENDED". 我们指出, "Implement for" 与 "Use for" 的值未来可能出现分化, 因为实现通常先于部署.

3. DNS Security Algorithm Numbers 注册表列值​

"Domain Name System Security (DNSSEC) Algorithm Numbers" 注册表组下 "DNS Security Algorithm Numbers" 注册表的使用与实现建议列的初始值见表 2.

当 "Use for" 列中存在多个 RECOMMENDED 算法时, 运营者应根据本地策略选择最佳算法.

| No. | Mnemonics | Use for DNSSEC Signing | Use for DNSSEC Validation | Implement for DNSSEC Signing | Implement for DNSSEC 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 | RECOMMENDED | NOT RECOMMENDED | MUST | | 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT | MUST NOT | MUST NOT | | 7 | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | RECOMMENDED | NOT RECOMMENDED | MUST | | 8 | RSASHA256 | RECOMMENDED | RECOMMENDED | MUST | MUST | | 10 | RSASHA512 | NOT RECOMMENDED | RECOMMENDED | NOT RECOMMENDED | MUST | | 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 |

表 2: DNS Security Algorithm Numbers 注册表各列的初始值

4. Digest Algorithms 注册表列值​

"DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" 注册表组下 "Digest Algorithms" 注册表的使用与实现建议列的初始值见表 3.

当 "Use for" 列中存在多个 RECOMMENDED 算法时, 运营者应根据本地策略选择最佳算法.

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

表 3: Digest Algorithms 注册表各列的初始值

5. 安全考虑事项​

密码系统的安全性取决于所选密码算法的强度以及与这些算法配合使用的密钥的强度. 安全性还取决于系统所用协议的工程设计, 以确保不存在绕过整个系统安全的非密码学手段.

本文档关注的是为 DNSSEC 选择密码算法的问题, 特别是 "强制实现" 算法的选择. 在本文档中, 被标识为 MUST 或 RECOMMENDED 实现的算法目前在已知范围内尚未被攻破, 并且迄今为止的密码学研究使我们相信, 除非出现重大且意外的发现, 它们很可能保持足够的安全. 然而, 这未必永远成立, 预期未来会不时发布新文档, 以反映该领域的当前最佳实践.

过早退役某个算法会导致使用该算法签名的区被降级为等同于未签名的区. 因此, 算法的废弃必须只在慎重考虑之后进行, 并且在可能的情况下尽量缓慢推进.

6. 运维考虑事项​

在活跃区中进行 DNSKEY 算法轮换是一个复杂的过程. 有关如何执行算法轮换的指南, 参见 [RFC6781] 和 [RFC7583].

在活跃区中进行 DS 算法轮换同样是一个复杂的过程. 在滚动到新密钥签名密钥 (Key Signing Key, KSK) 的同时升级算法会导致 DNSSEC 验证失败, 因此用户必须先升级 DS 算法, 再滚动到新的 KSK.

7. IANA 考虑事项​

IANA 已按照下述各节更新了 "DNS Security Algorithm Numbers" [DNSKEY-IANA] 和 "Digest Algorithms" [DS-IANA] 注册表.

7.1 对 "DNS Security Algorithm Numbers" 注册表的更新​

IANA 已为 "DNS Security Algorithm Numbers" 注册表 [DNSKEY-IANA] 增加了以下各列, 并已用本文档表 2 中的值填充这些列:

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

此外, IANA 还为 "DNS Security Algorithm Numbers" 注册表 [DNSKEY-IANA] 完成了以下操作:

  • 将注册流程改为 Standards Action 或 Specification Required.
  • 在注册表中添加了一条说明, 描述按第 2.2 节未被标记为 "RECOMMENDED" 的值.
  • 将本文档列为该注册表的附加参考.

7.2 对 "Digest Algorithms" 注册表的更新​

IANA 已为 "Digest Algorithms" 注册表 [DS-IANA] 增加了以下各列, 并已用本文档表 3 中的值填充这些列:

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

此外, IANA 还为 "Digest Algorithms" 注册表 [DS-IANA] 完成了以下操作:

  • 将注册流程改为 Standards Action 或 Specification Required.
  • 在注册表中添加了一条说明, 描述按第 2.2 节未被标记为 "RECOMMENDED" 的值.
  • 将本文档列为该注册表的附加参考.
  • 将值 128-252 标记为 "Reserved".
  • 将值 253 和 254 标记为 "Reserved for Private Use".
  • 删除了注册表中现已多余的 "Status" 列.

8. 参考文献​

8.1 规范性参考文献​

[DNSKEY-IANA]
IANA, "DNS Security Algorithm Numbers",
https://www.iana.org/assignments/dns-sec-alg-numbers.

[DS-IANA]
IANA, "Digest Algorithms",
http://www.iana.org/assignments/ds-rr-types.

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
https://www.rfc-editor.org/info/rfc2119.

[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
https://www.rfc-editor.org/info/rfc8126.

[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
https://www.rfc-editor.org/info/rfc8174.

[RFC9157]
Hoffman, P., "Revised IANA Considerations for DNSSEC", RFC 9157, DOI 10.17487/RFC9157, December 2021,
https://www.rfc-editor.org/info/rfc9157.

8.2 资料性参考文献​

[RFC4034]
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005,
https://www.rfc-editor.org/info/rfc4034.

[RFC4509]
Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, DOI 10.17487/RFC4509, May 2006,
https://www.rfc-editor.org/info/rfc4509.

[RFC5155]
Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
https://www.rfc-editor.org/info/rfc5155.

[RFC5702]
Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, DOI 10.17487/RFC5702, October 2009,
https://www.rfc-editor.org/info/rfc5702.

[RFC5933]
Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July 2010,
https://www.rfc-editor.org/info/rfc5933.

[RFC6605]
Hoffman, P. and W.C.A. Wijngaards, "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI 10.17487/RFC6605, April 2012,
https://www.rfc-editor.org/info/rfc6605.

[RFC6781]
Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012,
https://www.rfc-editor.org/info/rfc6781.

[RFC7583]
Morris, S., Ihren, J., Dickinson, J., and W. Mekking, "DNSSEC Key Rollover Timing Considerations", RFC 7583, DOI 10.17487/RFC7583, October 2015,
https://www.rfc-editor.org/info/rfc7583.

[RFC8080]
Sury, O. and R. Edmonds, "Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC", RFC 8080, DOI 10.17487/RFC8080, February 2017,
https://www.rfc-editor.org/info/rfc8080.

[RFC8624]
Wouters, P. and O. Sury, "Algorithm Implementation Requirements and Usage Guidance for DNSSEC", RFC 8624, DOI 10.17487/RFC8624, June 2019,
https://www.rfc-editor.org/info/rfc8624.

[RFC9364]
Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023,
https://www.rfc-editor.org/info/rfc9364.

[TLS-ciphersuites]
IANA, "Transport Layer Security (TLS) Parameters",
https://www.iana.org/assignments/tls-parameters.

致谢​

本文档基于 RFC 8624 并对其进行了扩展, RFC 8624 由 Paul Wouters 和 Ondrej Sury 撰写.

本文档的内容经 DNSOP 工作组参与者深入讨论. 作者感谢工作组参与者所表达的众多深思熟虑的意见, 它们共同帮助塑造了本文档. 我们感谢 Paul Hoffman 和 Paul Wouters 提供的文字贡献, 同时感谢 Nabeel Cocker, Shumon Huque, Nicolai Leymann, S. Moonesamy, Magnus Nyström, Peter Thomassen, Stefan Ubbink 和 Loganaden Velvindron 的评审与意见.

作者地址​

Wes Hardaker
USC/ISI
Email: [email protected]

Warren Kumari
Google
Email: [email protected]

相关资源​