1. 引言 (Introduction)
"DNS Security Extensions (DNSSEC)" [RFC9364] 用于提供 DNS 数据的身份验证。DNSSEC 签名算法由多个 RFC 定义，包括 [RFC4034]、[RFC4509]、[RFC5155]、[RFC5702]、[RFC5933]、[RFC6605] 和 [RFC8080]。
为了确保互操作性，[RFC8624] 中定义了一组"强制实现" DNS 公钥 (DNSKEY) 算法。为了使算法的当前状态更容易访问和理解，并使这些建议的未来更改更容易发布，本文档将算法的规范状态从 [RFC8624] 移至 IANA DNSSEC 算法注册表。本文档还纳入了 [RFC9157] 中修订的 IANA DNSSEC 考虑事项。此外，作为对运营者的建议，它添加了部署和使用这些算法的建议。
这类似于用于"TLS Cipher Suites"注册表 [TLS-ciphersuites] 的过程，其中密码套件的规范列表在 IANA 注册表中，RFC 引用 IANA 注册表。
1.1. 文档受众 (Document Audience)
添加到 IANA"DNS Security Algorithm Numbers" [DNSKEY-IANA] 和"Digest Algorithms" [DS-IANA] 注册表的列面向 DNSSEC 运营者和实现者。
实现需要满足高安全期望，同时在各种实现之间以及与不同版本之间提供互操作性。
密码学领域不断发展。出现了新的、更强的算法，现有算法可能被发现比最初认为的安全性低。因此，算法实现要求和使用指南需要不时更新，以反映新的现实，并允许平稳过渡到更安全的算法，以及废弃被认为不再安全的算法。
实现在选择要实现的算法时需要保守，以最小化代码复杂性和攻击面。
实现者的观点可能与希望仅使用最安全算法部署和配置 DNSSEC 的运营者的观点不同。因此，本文档还添加了关于无论实现状态如何都应部署哪些算法的新建议。一般来说，预计在实现停止支持之前，应普遍减少老旧算法的部署。
1.2. 更新算法要求级别 (Updating Algorithm Requirement Levels)
当 DNSSEC 密码算法成为强制实现时，它应该已经在大多数实现中可用。本文档定义了 IANA 注册修改，以允许未来的文档指定每个算法的实现建议，因为每个 DNSSEC 密码算法的建议状态预计会随时间而变化。例如，不能保证新引入的算法将来会成为强制实现。同样，已发布的算法不断受到密码攻击，可能变得太弱，甚至完全被破解，并且将来需要废弃。
预计算法的废弃将逐步执行。这为实现提供了时间来更新其实现的算法，同时保持互操作性。除非有强有力的安全理由，否则预计算法将从 MUST 降级为 NOT RECOMMENDED 或 MAY，而不是直接从 MUST 降级为 MUST NOT。同样，尚未被提及为强制实现的算法预计首先作为 RECOMMENDED 引入，而不是 MUST。
由于使用未知 DNSKEY 算法的效果是该区域被视为不安全，因此建议已降级为 NOT RECOMMENDED 或更低的算法不应被权威名称服务器和 DNSSEC 签名者用于创建新的 DNSKEY。这确保了废弃算法的使用随着时间的推移而减少。一旦算法达到足够低的部署水平，就可以将其标记为 MUST NOT，以便递归解析器可以删除对其验证的支持。
鼓励验证递归解析器保留对所有未标记为 MUST NOT 的算法的支持。
1.3. 要求标记 (Requirements Notation)
本文档中的关键词"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，因为这更清楚地表达了对实现者的建议。