RFC 9718 于 2025 年 1 月发布，旨在取代 RFC 7958，规范了 IANA 为全球 DNS 根区分发 DNSSEC 信任锚的格式与发布机制。文档指出，根区已通过 DNSSEC 进行加密签名，客户端需配置正确的信任锚才能验证根区应答，而 IANA（由 ICANN 附属机构 PTI 执行）负责根区信任锚的发布。该文档是 RFC 5011 自动信任锚更新协议的补充，用于建立初始信任锚，并明确其本身并非互联网标准跟踪规范，仅供信息参考。
RFC9718：DNSSEC Trust Anchor Publication for the Root Zone，January 2025梗概
全球域名系统（Domain Name System，DNS）的根区使用DNS安全扩展（DNS Security Extensions，DNSSEC）进行加密签名。
为了使用DNSSEC从DNS根区获取安全应答，客户端必须配置合适的信任锚。本文档描述了IANA用于分发DNSSEC信任锚的格式和发布机制。
本文档取代了RFC 7958。
本备忘录的状态
本文档不是互联网标准跟踪规范；其发布仅供参考。
本文档是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已接受公众审查，并已被互联网工程指导小组（IESG）批准发布。并非IESG批准的所有文件都是任何级别互联网标准的候选文件；请参阅RFC 7841第2节。
有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc9718。
版权声明
版权所有（c）2025 IETF Trust和文档作者。版权所有。
本文件受本文件发布之日生效的BCP 78和IETF信托与IETF文件相关的法律规定（https://trustee.ietf.org/license-info）的约束。请仔细阅读这些文件，因为它们描述了您与本文件相关的权利和限制。从本文档中提取的代码组件必须包括《信托法律条款》第4.e节中所述的修订版BSD许可证文本，并且不提供修订版BSD许可证中所述的保证。
1、简介
全球域名系统（Domain Name System，DNS）在[RFC1034]和[RFC1035]中描述。DNS安全扩展（DNS Security Extensions，DNSSEC）在 [RFC9364] 中进行了描述。
在DNSSEC协议中，资源记录集（Resource Record Sets，RRset）是经过加密签名的。这意味着对查询的响应包含允许验证RRset的完整性和真实性的签名。DNSSEC签名通过遵循“信任锚”的签名链进行验证。信任信任锚的原因不在DNSSEC协议之内，但DNSSEC协议的工作需要一个或多个信任锚。
DNS根区信任锚的发布是ICANN通过其附属公共技术标识符（Public Technical Identifiers，PTI）执行的一项IANA职能。相应密钥管理实践的详细描述可以在[DPS]中找到。
本文档描述了IANA用于DNS根区的DNSSEC信任锚的格式和分发方法。其他组织可能有不同的格式和机制来为根区分配DNSSEC信任锚；然而，大多数运营商和软件供应商选择依赖IANA信任锚。
本文档中描述的格式和分发方法是对 [RFC5011] 中描述的自动DNSSEC信任锚更新协议的补充，而不是替代。当信任已经建立时，该协议允许信任锚的安全带内继承。本文档描述了一种建立初始信任锚的方法，该方法可由 [RFC5011] 中定义的机制使用。
本文档已取代 [RFC7958]。
1.1、定义
术语“信任锚”在安全社区的许多不同上下文中使用。许多通用定义会发生冲突，因为它们特定于特定系统，例如仅针对DNSSEC或仅针对S/MIME消息。
在具有层次结构的密码系统中，信任锚是一个权威实体，信任是被假定的，而不是派生的。不同系统中实体的格式有所不同，但术语“信任锚”的所有常见用法都具有一个基本思想：信任该实体的决定是在依赖该实体的系统外部做出的。
IANA发布的根区信任锚格式在第2节中定义。[RFC4033] 将信任锚定义为“DNSKEY RR的配置DNSKEY RR或DS RR哈希值”。请注意，此处定义的格式与[RFC4033]中“信任锚”的定义不匹配；然而，想要将来自IANA的可信材料转换为委托签名者（Delegation Signer，DS）RR的系统可以这样做。
本文档中的关键字“必须”、“不得”、“必需”、“应”、“不应”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选”当且仅当它们出现在所有内容中时，应按照BCP 14 [RFC2119] [RFC8174] 中的描述进行解释。
2、IANA DNSSEC根区信任锚格式和语义
IANA将根区的信任锚作为XML [W3C.REC-xml11-20060816] 文档发布，其中包含DNSKEY记录的哈希值以及DNSKEY记录中的密钥（可选）。
此格式和相关语义将在本节的其余部分中描述。
请注意，XML文档可以包含XML注释。例如，IANA可能会使用这些注释添加指向IANA网站上重要信息的指针。XML注释仅用作人类可读的注释，而不是语法的扩展。
XML文档包含一组DNSKEY记录的哈希值，可用于验证根区。哈希值与DS资源定义的表示格式一致。
XML文档还可以包含DNSKEY记录中的密钥和标志。键和标志与DNSKEY资源定义的表示格式一致。
请注意，哈希值在语法中是强制性的，但键是可选的。
2.1、XML语法
以下是用于发布信任锚的文档的RELAX NG紧凑架构 [RELAX-NG]：
datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"start = element TrustAnchor { attribute id { xsd:string }, attribute source { xsd:string }, element Zone { xsd:string }, keydigest+ }keydigest = element KeyDigest { attribute id { xsd:string }, attribute validFrom { xsd:dateTime }, attribute validUntil { xsd:dateTime }?,element KeyTag { xsd:nonNegativeInteger { maxInclusive = "65535" } }, element Algorithm { xsd:nonNegativeInteger { maxInclusive = "255" } }, element DigestType { xsd:nonNegativeInteger { maxInclusive = "255" } }, element Digest { xsd:hexBinary }, publickeyinfo? }publickeyinfo = element PublicKey { xsd:base64Binary }, element Flags { xsd:nonNegativeInteger { maxInclusive = "65535" } }
2.2、XML语义
TrustAnchor元素是文件中所有信任锚的容器。
TrustAnchor元素中的id属性是一个不透明字符串，用于标识信任锚集。它的值没有特定的语义。请注意，TrustAnchor元素中的id属性与下述KeyDigest元素中的id属性不同。
TrustAnchor元素中的source属性提供有关从何处获取TrustAnchor容器的信息。它可能是一个URL，仅供参考。
TrustAnchor元素中的Zone元素说明此容器适用于哪个DNS区域。Zone元素采用 [RFC1035] 中指定的表示格式，包括尾随点。根区由单个句点（.）字符指示，不带任何引号。
TrustAnchor元素包含一个或多个KeyDigest元素。每个KeyDigest元素代表Zone元素中定义的区域的过去、当前或潜在的未来DNSKEY记录的摘要。KeyDigest元素中元素的值在 [RFC4034] 中定义。 [RFC9157] 中描述了DNSSEC相关值的IANA注册机构。
KeyDigest元素中的id属性是标识哈希的不透明字符串。请注意，KeyDigest元素中的id属性与上述TrustAnchor元素中的id属性不同。
KeyDigest元素中的validFrom和validUntil属性指定KeyDigest元素可用作信任锚的时间范围。
KeyDigest元素中的KeyTag元素包含此KeyDigest中表示的DNSKEY记录的密钥标签。
KeyDigest元素中的Algorithm元素包含此KeyDigest中表示的DNSKEY记录的DNSSEC签名算法标识符。
KeyDigest元素中的DigestType元素包含此KeyDigest中表示的DNSKEY记录的DNSSEC摘要算法标识符。
KeyDigest元素中的Digest元素包含此KeyDigest中表示的DNSKEY记录的哈希值的十六进制表示形式。
KeyDigest元素中的publickeyinfo命名模式包含两个强制元素：此KeyDigest中表示的DNSKEY记录的公钥的base64表示形式以及此KeyDigest中表示的DNSKEY记录的标志。publickeyinfo命名模式是可选的，并且是本规范中的新内容。当IANA具有尚未在DNS根中发布的信任锚并用于计算与摘要元素的比较时，它会很有用。
2.3、XML示例
以下是信任锚文件的示例。仅针对过去没有validFrom时间的信任锚给出完整的公钥。
<TrustAnchorid="E9724F53-1851-4F86-85E5-F1392102940B"source="http://data.iana.org/root-anchors/root-anchors.xml"> <Zone>.</Zone> <KeyDigestid="Kjqmt7v"validFrom="2010-07-15T00:00:00+00:00"validUntil="2019-01-11T00:00:00+00:00"> <!-- This key is no longer valid, since validUntil is in the past --> <KeyTag>19036</KeyTag> <Algorithm>8</Algorithm> <DigestType>2</DigestType> <Digest> 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 </Digest> </KeyDigest> <KeyDigestid="Klajeyz"validFrom="2017-02-02T00:00:00+00:00"> <KeyTag>20326</KeyTag> <Algorithm>8</Algorithm> <DigestType>2</DigestType> <Digest> E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D </Digest> <PublicKey> AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4Rg WOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQ uCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj /EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Ap xz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXG Xws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= </PublicKey> <Flags>257</Flags> </KeyDigest> <!-- The following is called "KSK-2024" as a shorthand name --> <KeyDigestid="Kmyv6jo"validFrom="2024-07-18T00:00:00+00:00"> <KeyTag>38696</KeyTag> <Algorithm>8</Algorithm> <DigestType>2</DigestType> <Digest> 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16 </Digest> </KeyDigest> </TrustAnchor>从该示例导出的DS RRset为：
. IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D. IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
请注意，此DS记录集只有两条记录。潜在的第三条记录（包括密钥标签19036的一条记录）根据validUntil属性的值已经无效，因此不是信任锚集的一部分。
从该示例派生的DNSKEY RRset是：
. IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU=请注意，此DNSKEY记录集只有一条记录。潜在的第二条记录（基于密钥标签19036的一条记录）根据validUntil属性的值已经无效，因此不是信任锚集的一部分。另一个潜在的第二条记录（基于密钥标签38696）不包含可选的publickeyinfo命名模式；因此，无法计算其DNSKEY记录。
3、根区信任锚检索
3.1、使用HTTPS和HTTP检索信任锚
信任锚可用于使用HTTPS和HTTP进行检索。
在本节中，所有URL均使用“https:”方案给出。如果无法使用HTTPS，请将“https:”方案替换为“http:”。
用于检索第2节中描述的XML文档中的哈希集的URL是 <https://data.iana.org/root-anchors/rootanchors.xml>。
3.2、接受DNSSEC信任锚
验证器运营方可以选择是否使用他们想要的任何策略接受本文档中描述的信任锚。为了帮助验证器运营方验证他们收到的信任锚的内容和来源，IANA使用通过信任锚数据链接到ICANN控制的证书颁发机构（Certificate Authority，CA）的数字签名。
值得注意的是，ICANN CA不是DNSSEC信任锚。相反，它是一种可选机制，用于验证XML和证书信任锚的内容和来源。
XML文档的内容和来源可以使用文件上的数字签名进行验证。IANA提供了一个独立的加密消息语法（Cryptographic Message Syntax，CMS） [RFC5652] 签名，该签名通过XML文档链接到ICANN CA。这对于以受信任的带外方式收到ICANN CA公钥副本的验证器运营方来说非常有用。XML文档的分离式CMS签名的URL为 <https://data.iana.org/root-anchors/rootanchors.p7s>。
IANA用于帮助验证器运营方验证他们收到的信任锚的内容和来源的另一种方法是使用传输层安全（Transport Layer Security，TLS）协议来分发信任锚。目前，“data.iana.org”使用的CA是众所周知的，即WebTrust认可的CA。如果检索信任锚的系统信任IANA用于“data.iana.org”Web服务器的CA，则应使用HTTPS而不是HTTP，以确保数据来源。
3.3、分发信任模型的变化
IANA过去将信任锚作为自签名的Pretty Good Privacy（PGP）消息和自颁发的证书签名请求进行分发； [RFC7958] 中对此进行了描述。本文档删除了这些方法，因为它们依赖于将身份验证密钥的带外信任与DNSSEC根密钥的带外信任混合在一起的信任模型。但请注意，信任锚内容的加密保证现在来自Web PKI或ICANN CA，如第3.2节中所述。这种加密保证得到了信任锚用户进行的非正式比较的支持，例如软件供应商比较他们正在使用的信任锚文件。
4、安全考虑
本文档描述了如何发布DNS根区的DNSSEC信任锚。许多DNSSEC客户端只会为DNS根配置IANA颁发的信任锚来执行验证。因此，可靠地发布信任锚非常重要。
本文档旨在仔细指定此类信任锚的发布方式，目的是使这些信任锚更容易集成到用户环境中。所描述的某些方法（例如通过Web进行访问，无论是否验证文件签名）具有不同的安全属性；信任锚文件的用户在选择是否加载信任锚集合时需要考虑这些。
4.1、信赖方的安全考虑
本文档的正文没有指定信赖方的任何特定行为。具体来说，它没有说明信赖方应如何对待整个信任锚文件。然而，信任锚文件的某些内容需要信赖方特别注意。
4.1.1、validUntil
请注意，KeyDigest元素的validUntil属性是可选的。如果信赖方使用的信任锚的KeyDigest元素不具有validUntil属性，则它可以更改为具有KeyDigest元素且具有validUntil属性的信任锚，只要该信任锚的validUntil属性是未来的，并且KeyDigest的KeyTag、Algorithm、DigestType和Digest元素与先前信任锚中的相同。
信赖方不应在validFrom和validUntil属性中指定的时间范围之外使用KeyDigest。
4.1.2、Digest和publickeyinfo的比较
KeyDigest元素可以包含Digest和publickeyinfo命名模式。如果Digest元素不是由publickeyinfo命名模式表示的DNSKEY记录的正确DS记录，则信赖方不得使用该KeyDigest作为信任锚。想要进行此类比较的信赖方需要使用 [RFC4034] 第5.1.4节中指定的算法来编排成为DS记录的DNSKEY记录的元素。
信赖方需要谨慎实施信任锚匹配。由KeyDigest元素表示的单个信任锚可能会在信任锚文件的两个版本之间更改其Digest和KeyTag值，例如，当密钥被撤销或标志值由于某些其他原因而更改时。未能考虑到此属性的信赖方将面临使用一组不正确的信任锚的风险。
4.1.3、处理信任锚文件的不同输出
需要可选的publickeyinfo命名模式来创建信任锚的信赖方将比仅需要摘要元素的信赖方存储更少的信任锚。因此，处理相同信任锚文件的两个系统最终可能会得到一组不同的信任锚。
5、IANA考虑因素
每次IANA生成新的信任锚时，它必须使用本文档中描述的格式发布该信任锚。
由于运营原因（例如在多个设施中拥有新创建的密钥），IANA可能会延迟发布新的信任锚。
当之前发布的信任锚不再适合使用时，IANA必须通过为该信任锚设置validUntil日期来相应更新信任锚文件。添加的validUntil属性可以是过去或将来的日期，具体取决于IANA的操作选择。
有关如何管理DNS根区加密密钥的IANA政策和程序（也称为“DNSSEC实践声明”或“DPS”）的更多信息，请访问 <https://www.iana.org/dnssec/procedures>。
[RFC7958] 定义了id-mod-dns-resource-record，值70，已添加到“SMI Security for PKIX Module Identifier”注册表中。本文档不使用该标识符。
6、参考文献
6.1、规范性参考文献
[] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.[] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.[] 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>.[] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.[] 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>.[] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, <https://www.rfc-editor.org/info/rfc5011>.[] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.[] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman, "DNSSEC Trust Anchor Publication for the Root Zone", RFC 7958, DOI 10.17487/RFC7958, August 2016, <https://www.rfc-editor.org/info/rfc7958>.[] 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>.[] Hoffman, P., "Revised IANA Considerations for DNSSEC", RFC 9157, DOI 10.17487/RFC9157, December 2021, <https://www.rfc-editor.org/info/rfc9157>.[] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023, <https://www.rfc-editor.org/info/rfc9364>.[] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., Yergeau, F., and J. Cowan, "Extensible Markup Language (XML) 1.1 (Second Edition)", W3C Recommendation RECxml11-20060816, 16 August 2006, <https://www.w3.org/TR/2006/REC-xml11-20060816>.
6.2、信息性参考文献
[] Root Zone KSK Operator Policy Management Authority, "DNSSEC Practice Statement for the Root Zone KSK Operator", <https://www.iana.org/dnssec/procedures>.[] Clark, J., "RELAX NG Compact Syntax", OASIS Committee Specification, November 2002, <https://www.oasisopen.org/committees/relax-ng/compact-20021121.html>.
附录A、对RFC 7958的变更
本文档包括以下更改：
* 根据勘误ID 5932 <https://www.rfc-editor.org/errata/eid5932> 进行了重大技术更改。此更改位于第2.2节第七段。
* 添加了可选的publickeyinfo命名模式，其中包含两个必需元素：PublicKey和Flags。
* 删除了证书和证书签名机制。
* 删除了分离的OpenPGP签名机制。
* 更新了对DNSSEC实践声明 [DPS] 的引用。
* 明确指出XML文档中可能包含XML注释。
* 阐明了分离式CMS签名的使用。
* 更新了IANA注意事项部分以表明对IANA的要求。
* 简化了使用validFrom和validUntil属性的描述。
* 添加了新的安全注意事项。
* 进行了一些编辑修改。
附录B、历史记录
第一个用于DNS根区的密钥签名密钥（Key Signing Key，KSK）于2010年6月16日在美国弗吉尼亚州库尔佩珀的ICANN密钥管理设施（Key Management Facility，KMF）举行的密钥仪式上生成。该密钥于2010年7月12日在美国加利福尼亚州埃尔塞贡多的ICANN KMF举行的第二次密钥仪式上投入生产。由此产生的信任锚于2010年7月15日首次发布。
用于DNS根区的第二个KSK于2016年10月27日在美国弗吉尼亚州库尔佩珀举行的ICANN KMF第27号关键仪式上生成。该密钥于2017年2月2日在美国加利福尼亚州埃尔塞贡多的ICANN KMF举行的第28号密钥仪式上投入生产。由此产生的信任锚于2018年11月11日首次发布。
有关关键仪式的更多信息，包括以前仪式的完整记录和未来仪式的计划，可以在 <https://www.iana.org/dnssec/ceremonies> 上找到。
致谢
许多先驱者为在DNS根区部署DNSSEC铺平了道路，作者特此承认他们的巨大集体贡献。
RFC 7958纳入了Alfred Hoenes和Russ Housley提出的建议，我们对他们的贡献表示赞赏。
***推荐阅读***
原文始发于微信公众号（金失三石）：根区的DNSSEC信任锚出版物
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论