Independent Submission J. Abley
Request for Comments: 7958 Dyn, Inc.
Category: Informational J. Schlyter
ISSN: 2070-1721 Kirei AB
G. Bailey
Independent
P. Hoffman
ICANN
August 2016
Independent Submission J. Abley
Request for Comments: 7958 Dyn, Inc.
Category: Informational J. Schlyter
ISSN: 2070-1721 Kirei AB
G. Bailey
Independent
P. Hoffman
ICANN
August 2016
DNSSEC Trust Anchor Publication for the Root Zone
根区域的DNSSEC信任锚发布
Abstract
摘要
The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC).
已使用DNS安全扩展（DNSSEC）对域名系统（DNS）的根区域进行加密签名。
In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA has used to distribute the DNSSEC trust anchors.
为了使用DNSSEC从DNS的根区域获得安全答案，客户端必须配置合适的信任锚。本文档描述了IANA用于分发DNSSEC信任锚的格式和发布机制。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7958.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7958.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. IANA DNSSEC Root Zone Trust Anchor Formats and Semantics . . 4
2.1. Hashes in XML . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. XML Syntax . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. XML Semantics . . . . . . . . . . . . . . . . . . . . 5
2.1.3. Converting from XML to DS Records . . . . . . . . . . 7
2.1.4. XML Example . . . . . . . . . . . . . . . . . . . . . 8
2.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Certificate Signing Requests . . . . . . . . . . . . . . 9
3. Root Zone Trust Anchor Retrieval . . . . . . . . . . . . . . 9
3.1. Retrieving Trust Anchors with HTTPS and HTTP . . . . . . 9
4. Accepting DNSSEC Trust Anchors . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Historical Note . . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. IANA DNSSEC Root Zone Trust Anchor Formats and Semantics . . 4
2.1. Hashes in XML . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. XML Syntax . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. XML Semantics . . . . . . . . . . . . . . . . . . . . 5
2.1.3. Converting from XML to DS Records . . . . . . . . . . 7
2.1.4. XML Example . . . . . . . . . . . . . . . . . . . . . 8
2.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Certificate Signing Requests . . . . . . . . . . . . . . 9
3. Root Zone Trust Anchor Retrieval . . . . . . . . . . . . . . 9
3.1. Retrieving Trust Anchors with HTTPS and HTTP . . . . . . 9
4. Accepting DNSSEC Trust Anchors . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Historical Note . . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
The Domain Name System (DNS) is described in [RFC1034] and [RFC1035]. DNS Security Extensions (DNSSEC) are described in [RFC4033], [RFC4034], [RFC4035], [RFC4509], [RFC5155], and [RFC5702].
[RFC1034]和[RFC1035]中描述了域名系统（DNS）。DNS安全扩展（DNSSEC）在[RFC4033]、[RFC4034]、[RFC4035]、[RFC4509]、[RFC5155]和[RFC5702]中进行了描述。
A discussion of operational practices relating to DNSSEC can be found in [RFC6781].
与DNSSEC相关的操作实践讨论见[RFC6781]。
In the DNSSEC protocol, Resource Record Sets (RRSets) are signed cryptographically. This means that a response to a query contains signatures that allow the integrity and authenticity of the RRSet to be verified. DNSSEC signatures are validated by following a chain of signatures to a "trust anchor". The reason for trusting a trust anchor is outside the DNSSEC protocol, but having one or more trust anchors is required for the DNSSEC protocol to work.
在DNSSEC协议中，资源记录集（RRSET）以加密方式签名。这意味着对查询的响应包含允许验证RRSet的完整性和真实性的签名。DNSSEC签名通过跟随签名链到“信任锚”进行验证。信任信任锚的原因在DNSSEC协议之外，但需要有一个或多个信任锚才能使DNSSEC协议工作。
The publication of trust anchors for the root zone of the DNS is an IANA function performed by ICANN. A detailed description of corresponding key management practices can be found in [DPS], which can be retrieved from the IANA Repository at <https://www.iana.org/dnssec/>.
发布DNS根区域的信任锚是ICANN执行的IANA功能。有关相应密钥管理实践的详细说明，请参见[DPS]，可从IANA存储库中的<https://www.iana.org/dnssec/>.
This document describes the formats and distribution methods of DNSSEC trust anchors that have been used by IANA for the root zone of the DNS since 2010. Other organizations might have different formats and mechanisms for distributing DNSSEC trust anchors for the root zone; however, most operators and software vendors have chosen to rely on the IANA trust anchors.
本文档描述了自2010年以来IANA用于DNS根区域的DNSSEC信任锚的格式和分发方法。其他组织可能有不同的格式和机制来为根区域分发DNSSEC信任锚；然而，大多数运营商和软件供应商选择依赖IANA信任锚。
It is important to note that at the time of this writing, IANA intends to change the formats and distribution methods in the future. If such a change happens, IANA will publish the changes on its web site at <https://www.iana.org/dnssec/files>.
值得注意的是，在撰写本文时，IANA打算在将来更改格式和分发方法。如果发生这种变化，IANA将在其网站上发布这些变化，网址为<https://www.iana.org/dnssec/files>.
The formats and distribution methods described in this document are a complement to, not a substitute for, the automated DNSSEC trust anchor update protocol described in [RFC5011]. That protocol allows for secure in-band succession of trust anchors when trust has already been established. This document describes one way to establish an initial trust anchor that can be used by [RFC5011].
本文件中描述的格式和分发方法是对[RFC5011]中描述的自动DNSSEC信任锚更新协议的补充，而不是替代。当信任已经建立时，该协议允许信任锚的安全带内连续。本文档描述了一种建立初始信任锚的方法，可供[RFC5011]使用。
The term "trust anchor" is used in many different contexts in the security community. Many of the common definitions conflict because they are specific to a specific system, such as just for DNSSEC or just for S/MIME messages.
“信任锚”一词在安全社区的许多不同上下文中使用。许多常见的定义冲突，因为它们特定于特定的系统，例如仅用于DNSSEC或仅用于S/MIME消息。
In cryptographic systems with hierarchical structure, a trust anchor is an authoritative entity for which trust is assumed and not derived. The format of the entity differs in different systems, but the basic idea, that trust is assumed and not derived, is common to all the common uses of the term "trust anchor".
在具有层次结构的密码系统中，信任锚是一个权威实体，它假定信任而不是派生信任。实体的格式在不同的系统中有所不同，但信任是假定的而不是派生的这一基本思想在“信任锚”一词的所有常用用法中都是通用的。
The root zone trust anchor formats published by IANA are defined in Section 2. [RFC4033] defines a trust anchor as "A configured DNSKEY RR or DS RR hash of a DNSKEY RR". Note that the formats defined here do not match the definition of "trust anchor" from [RFC4033]; however, a system that wants to convert the trusted material from IANA into a Delegation Signer (DS) RR can do so.
IANA发布的根区域信任锚格式在第2节中定义。[RFC4033]将信任锚定义为“已配置的DNSKEY RR或DNSKEY RR的DS RR哈希”。注意，此处定义的格式与[RFC4033]中“信任锚”的定义不匹配；但是，希望将IANA中的受信任材料转换为委托签名者（DS）RR的系统可以这样做。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
IANA publishes trust anchors for the root zone in three formats:
IANA以三种格式发布根区域的信任锚点：
o an XML document that contains the hashes of the DNSKEY records
o 包含DNSKEY记录哈希的XML文档
o certificates in PKIX format [RFC5280] that contain DS records and the full public key of DNSKEY records
o PKIX格式[RFC5280]的证书，其中包含DS记录和DNSKEY记录的完整公钥
o Certificate Signing Requests (CSRs) in PKCS #10 format [RFC2986] that contain DS records and the full public key of DNSKEY records
o PKCS#10格式[RFC2986]的证书签名请求（CSR），其中包含DS记录和DNSKEY记录的完整公钥
These formats and the semantics associated with each are described in the rest of this section.
这些格式以及与之相关的语义将在本节的其余部分中描述。
The XML document contains a set of hashes for the DNSKEY records that can be used to validate the root zone. The hashes are consistent with the defined presentation format of DS resource records from [RFC4034].
XML文档包含DNSKEY记录的一组哈希，可用于验证根区域。哈希值与[RFC4034]中定义的DS资源记录表示格式一致。
A RELAX NG Compact Schema [RELAX-NG] for the documents used to publish trust anchors is given in Figure 1.
图1给出了用于发布信任锚的文档的RELAX NG紧凑模式[RELAX-NG]。
datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"
datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"
start = element TrustAnchor { attribute id { xsd:string }, attribute source { xsd:string }, element Zone { xsd:string },
start=元素信任锚{attribute id{xsd:string}，属性源{xsd:string}，元素区域{xsd:string}，
keydigest+ }
关键字摘要+}
keydigest = element KeyDigest { attribute id { xsd:string }, attribute validFrom { xsd:dateTime }, attribute validUntil { xsd:dateTime }?,
keydigest=元素keydigest{attribute id{xsd:string}，属性validFrom{xsd:dateTime}，属性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 }
}
element KeyTag {
xsd:nonNegativeInteger { maxInclusive = "65535" } },
element Algorithm {
xsd:nonNegativeInteger { maxInclusive = "255" } },
element DigestType {
xsd:nonNegativeInteger { maxInclusive = "255" } },
element Digest { xsd:hexBinary }
}
Figure 1
图1
The TrustAnchor element is the container for all of the trust anchors in the file.
TrustAnchor元素是文件中所有信任锚的容器。
The id attribute in the TrustAnchor element is an opaque string that identifies the set of trust anchors. Its value has no particular semantics. Note that the id element in the TrustAnchor element is different than the id element in the KeyDigest element, described below.
TrustAnchor元素中的id属性是一个不透明字符串，用于标识信任锚点集。它的值没有特定的语义。请注意，TrustAnchor元素中的id元素与KeyDigest元素中的id元素不同，如下所述。
The source attribute in the TrustAnchor element gives information about where to obtain the TrustAnchor container. It is likely to be a URL and is advisory only.
TrustAnchor元素中的source属性提供有关从何处获取TrustAnchor容器的信息。它可能是一个URL，只是一个建议。
The Zone element in the TrustAnchor element states to which DNS zone this container applies. The root zone is indicated by a single period (.) character without any quotation marks.
TrustAnchor元素中的Zone元素表示此容器应用于哪个DNS区域。根区域由单个句点（.）字符表示，不带任何引号。
The TrustAnchor element contains one or more KeyDigest elements. Each KeyDigest element represents the digest of a DNSKEY record in the zone defined in the Zone element.
TrustAnchor元素包含一个或多个KeyDigest元素。每个KeyDigest元素表示zone元素中定义的分区中DNSKEY记录的摘要。
The id attribute in the KeyDigest element is an opaque string that identifies the hash. Its value is used in the file names and URI of the other trust anchor formats. This is described in Section 3.1. For example, if the value of the id attribute in the KeyDigest element is "Kjqmt7v", the URI for the CSR that is associated with this hash will be <https://data.iana.org/root-anchors/Kjqmt7v.csr>. Note that the id element in the KeyDigest element is different than the id element in the TrustAnchor element described above.
KeyDigest元素中的id属性是标识哈希的不透明字符串。它的值用于其他信任锚格式的文件名和URI中。第3.1节对此进行了说明。例如，如果KeyDigest元素中id属性的值为“Kjqmt7v”，则与此哈希关联的CSR的URI将为<https://data.iana.org/root-anchors/Kjqmt7v.csr>. 请注意，KeyDigest元素中的id元素与上述TrustAnchor元素中的id元素不同。
The validFrom and validUntil attributes in the KeyDigest element specify the range of times that the KeyDigest element can be used as a trust anchor. Note that the KeyDigest element is optional; if it is not given, the trust anchor can be used until a KeyDigest element covering the same DNSKEY record, but having a validUntil attribute, is trusted by the relying party. Relying parties SHOULD NOT use a KeyDigest outside of the time range given in the validFrom and validUntil attributes.
KeyDigest元素中的validFrom和validUntil属性指定KeyDigest元素可用作信任锚的时间范围。请注意，KeyDigest元素是可选的；如果未给出信任锚，则可以使用信任锚，直到依赖方信任覆盖相同DNSKEY记录但具有validUntil属性的KeyDigest元素。依赖方不应在validFrom和validUntil属性中给出的时间范围之外使用密钥摘要。
The KeyTag element in the KeyDigest element contains the key tag for the DNSKEY record represented in this KeyDigest.
KeyDigest元素中的KeyTag元素包含此KeyDigest中表示的DNSKEY记录的键标记。
The Algorithm element in the KeyDigest element contains the signing algorithm identifier for the DNSKEY record represented in this KeyDigest.
KeyDigest元素中的Algorithm元素包含此KeyDigest中表示的DNSKEY记录的签名算法标识符。
The DigestType element in the KeyDigest element contains the digest algorithm identifier for the DNSKEY record represented in this KeyDigest.
KeyDigest元素中的DigestType元素包含此KeyDigest中表示的DNSKEY记录的摘要算法标识符。
The Digest element in the KeyDigest element contains the hexadecimal representation of the hash for the DNSKEY record represented in this KeyDigest.
KeyDigest元素中的Digest元素包含此KeyDigest中表示的DNSKEY记录的哈希的十六进制表示形式。
The display format for the DS record that is the equivalent of a KeyDigest element can be constructed by marshaling the KeyTag, Algorithm, DigestType, and Digest elements. For example, assume that the TrustAnchor element contains:
DS记录的显示格式相当于KeyDigest元素，可以通过封送KeyTag、Algorithm、DigestType和Digest元素来构造。例如，假设TrustAnchor元素包含：
<?xml version="1.0" encoding="UTF-8"?>
<TrustAnchor
id="AD42165F-3B1A-4778-8F42-D34A1D41FD93"
source="http://data.iana.org/root-anchors/root-anchors.xml">
<Zone>.</Zone>
<KeyDigest id="Kjqmt7v" validFrom="2010-07-15T00:00:00+00:00">
<KeyTag>19036</KeyTag>
<Algorithm>8</Algorithm>
<DigestType>2</DigestType>
<Digest>
49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
</Digest>
</KeyDigest>
</TrustAnchor>
<?xml version="1.0" encoding="UTF-8"?>
<TrustAnchor
id="AD42165F-3B1A-4778-8F42-D34A1D41FD93"
source="http://data.iana.org/root-anchors/root-anchors.xml">
<Zone>.</Zone>
<KeyDigest id="Kjqmt7v" validFrom="2010-07-15T00:00:00+00:00">
<KeyTag>19036</KeyTag>
<Algorithm>8</Algorithm>
<DigestType>2</DigestType>
<Digest>
49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
</Digest>
</KeyDigest>
</TrustAnchor>
The DS record would be:
DS记录将是：
. IN DS 19036 8 2
49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
. IN DS 19036 8 2
49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
Figure 2 describes two fictitious trust anchors for the root zone.
图2描述了根区域的两个虚拟信任锚。
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
<TrustAnchor
id="AD42165F-B099-4778-8F42-D34A1D41FD93"
source="http://data.iana.org/root-anchors/root-anchors.xml">
<Zone>.</Zone>
<KeyDigest id="42"
validFrom="2010-07-01T00:00:00-00:00"
validUntil="2010-08-01T00:00:00-00:00">
<KeyTag>34291</KeyTag>
<Algorithm>5</Algorithm>
<DigestType>1</DigestType>
<Digest>c8cb3d7fe518835490af8029c23efbce6b6ef3e2</Digest>
</KeyDigest>
<KeyDigest id="53"
validFrom="2010-08-01T00:00:00-00:00">
<KeyTag>12345</KeyTag>
<Algorithm>5</Algorithm>
<DigestType>1</DigestType>
<Digest>a3cf809dbdbc835716ba22bdc370d2efa50f21c7</Digest>
</KeyDigest>
</TrustAnchor>
<TrustAnchor
id="AD42165F-B099-4778-8F42-D34A1D41FD93"
source="http://data.iana.org/root-anchors/root-anchors.xml">
<Zone>.</Zone>
<KeyDigest id="42"
validFrom="2010-07-01T00:00:00-00:00"
validUntil="2010-08-01T00:00:00-00:00">
<KeyTag>34291</KeyTag>
<Algorithm>5</Algorithm>
<DigestType>1</DigestType>
<Digest>c8cb3d7fe518835490af8029c23efbce6b6ef3e2</Digest>
</KeyDigest>
<KeyDigest id="53"
validFrom="2010-08-01T00:00:00-00:00">
<KeyTag>12345</KeyTag>
<Algorithm>5</Algorithm>
<DigestType>1</DigestType>
<Digest>a3cf809dbdbc835716ba22bdc370d2efa50f21c7</Digest>
</KeyDigest>
</TrustAnchor>
Figure 2
图2
Each public key that can be used as a trust anchor is represented as a certificate in PKIX format. Each certificate is signed by the ICANN certificate authority. The SubjectPublicKeyInfo in the certificate represents the public key of the Key Signing Key (KSK). The Subject field has the following attributes:
可以用作信任锚的每个公钥都表示为PKIX格式的证书。每个证书都由ICANN证书颁发机构签署。证书中的SubjectPublicKeyInfo表示密钥签名密钥（KSK）的公钥。“主题”字段具有以下属性：
O: the string "ICANN".
O:字符串“ICANN”。
OU: the string "IANA".
欧：字符串“IANA”。
CN: the string "Root Zone KSK" followed by the time and date of key generation in the format specified in [RFC3339]. For example, a CN might be "Root Zone KSK 2010-06-16T21:19:24+00:00".
CN：字符串“Root Zone KSK”，后跟按照[RFC3339]中指定的格式生成密钥的时间和日期。例如，CN可能是“根区域KSK 2010-06-16T21:19:24+00:00”。
resourceRecord: a string in the presentation format of the DS [RFC4034] resource record for the DNSSEC public key.
resourceRecord：DNSSEC公钥的DS[RFC4034]资源记录表示格式的字符串。
The "resourceRecord" attribute in the Subject is defined as follows:
主题中的“resourceRecord”属性定义如下：
ResourceRecord
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-dns-resource-record(70) }
ResourceRecord
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-dns-resource-record(70) }
DEFINITIONS IMPLICIT TAGS ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL --
--全部出口--
IMPORTS
进口
caseIgnoreMatch FROM SelectedAttributeTypes
{ joint-iso-itu-t ds(5) module(1) selectedAttributeTypes(5) 4 }
caseIgnoreMatch FROM SelectedAttributeTypes
{ joint-iso-itu-t ds(5) module(1) selectedAttributeTypes(5) 4 }
;
;
iana OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) private(4) enterprise(1) 1000 }
iana OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) private(4) enterprise(1) 1000 }
iana-dns OBJECT IDENTIFIER ::= { iana 53 }
iana-dns OBJECT IDENTIFIER ::= { iana 53 }
resourceRecord ATTRIBUTE ::= {
WITH SYNTAX IA5String
EQUALITY MATCHING RULE caseIgnoreMatch
ID iana-dns
}
resourceRecord ATTRIBUTE ::= {
WITH SYNTAX IA5String
EQUALITY MATCHING RULE caseIgnoreMatch
ID iana-dns
}
END
终止
Each public key that can be used as a trust anchor is represented as a CSR in PKCS #10 format. The SubjectPublicKeyInfo and Subject field are the same as for certificates (see Section 2.2 above).
每个可用作信任锚的公钥都表示为PKCS#10格式的CSR。SubjectPublicKeyInfo和Subject字段与证书相同（请参见上文第2.2节）。
Trust anchors are available for retrieval using HTTPS and HTTP.
信任锚可用于使用HTTPS和HTTP进行检索。
In this section, all URLs are given using the "https:" scheme. If HTTPS cannot be used, replace the "https:" scheme with "http:".
在本节中，所有URL都使用“https:”方案给出。如果无法使用HTTPS，请将“HTTPS:”方案替换为“http:”。
The URL for retrieving the set of hashes described in Section 2.1 is <https://data.iana.org/root-anchors/root-anchors.xml>.
用于检索第2.1节中描述的哈希集的URL为<https://data.iana.org/root-anchors/root-anchors.xml>.
The URL for retrieving the PKIX certificate described in Section 2.2 is <https://data.iana.org/root-anchors/KEYDIGEST-ID.crt>, with the string "KEYDIGEST-ID" replacing the "id" attribute from the KeyDigest element from the XML file, as described in Section 2.1.2.
第2.2节中描述的用于检索PKIX证书的URL为<https://data.iana.org/root-anchors/KEYDIGEST-ID.crt>，字符串“KEYDIGEST-ID”替换XML文件中KEYDIGEST元素的“ID”属性，如第2.1.2节所述。
The URL for retrieving the CSR described in Section 2.3 is <https://data.iana.org/root-anchors/KEYDIGEST-ID.csr>, with the string "KEYDIGEST-ID" replacing the "id" attribute from the KeyDigest element from the XML file, as described in Section 2.1.2.
第2.3节中描述的检索CSR的URL为<https://data.iana.org/root-anchors/KEYDIGEST-ID.csr>，字符串“KEYDIGEST-ID”替换XML文件中KEYDIGEST元素的“ID”属性，如第2.1.2节所述。
A validator operator can choose whether or not to accept the trust anchors described in this document using whatever policy they want. In order to help validator operators verify the content and origin of trust anchors they receive, IANA uses digital signatures that chain to an ICANN-controlled Certificate Authority (CA) over the trust anchor data.
验证器操作员可以选择是否接受本文档中描述的信任锚，使用他们想要的任何策略。为了帮助验证器操作员验证他们收到的信任锚的内容和来源，IANA使用数字签名，通过信任锚数据链接到ICANN控制的证书颁发机构（CA）。
It is important to note that the ICANN CA is not a DNSSEC trust anchor. Instead, it is an optional mechanism for verifying the content and origin of the XML and certificate trust anchors. It is also important to note that the ICANN CA cannot be used to verify the origin of the trust anchor in the CSR format.
需要注意的是，ICANN CA不是DNSSEC信任锚。相反，它是一种可选机制，用于验证XML和证书信任锚的内容和来源。还需要注意的是，ICANN CA不能用于验证CSR格式的信任锚的来源。
The content and origin of the XML file can be verified using a digital signature on the file. IANA provides a detached Cryptographic Message Syntax (CMS) [RFC5652] signature that chains to the ICANN CA with the XML file. The URL for a detached CMS signature for the XML file is <https://data.iana.org/root-anchors/root-anchors.p7s>.
可以使用文件上的数字签名来验证XML文件的内容和来源。IANA提供一个分离的加密消息语法（CMS）[RFC5652]签名，该签名通过XML文件链接到ICANN CA。XML文件的分离CMS签名的URL为<https://data.iana.org/root-anchors/root-anchors.p7s>.
(IANA also provided a detached OpenPGP [RFC4880] signature as a second parallel verification mechanism for the first trust anchor publication but has indicated that it will not use this parallel mechanism in the future.)
（IANA还提供了一个分离的OpenPGP[RFC4880]签名，作为第一个信任锚发布的第二个并行验证机制，但已表示将来不会使用此并行机制。）
Another method IANA uses to help validator operators verify the content and origin of trust anchors they receive is to use the Transport Layer Security (TLS) protocol for distributing the trust anchors. Currently, the CA used for data.iana.org is well known, that is, one that is a WebTrust-accredited CA. If a system retrieving the trust anchors trusts the CA that IANA uses for the "data.iana.org" web server, HTTPS SHOULD be used instead of HTTP in order to have assurance of data origin.
IANA用于帮助验证器操作员验证其收到的信任锚的内容和来源的另一种方法是使用传输层安全（TLS）协议分发信任锚。目前，用于data.iana.org的CA是众所周知的，即WebTrust认证的CA。如果检索信任锚的系统信任iana用于“data.iana.org”web服务器的CA，则应使用HTTPS而不是HTTP，以确保数据来源。
This document defines id-mod-dns-resource-record, value 70 (see Section 2.2), in the "SMI Security for PKIX Module Identifier" registry.
本文档在“PKIX模块标识符的SMI安全性”注册表中定义id mod dns资源记录，值为70（见第2.2节）。
This document describes how DNSSEC trust anchors for the root zone of the DNS are published. Many DNSSEC clients will only configure IANA-issued trust anchors for the DNS root to perform validation. As a consequence, reliable publication of trust anchors is important.
本文档描述了如何发布DNS根区域的DNSSEC信任锚。许多DNSSEC客户端将仅为DNS根配置IANA颁发的信任锚以执行验证。因此，信任锚的可靠发布非常重要。
This document aims to specify carefully the means by which such trust anchors are published, with the goal of making it easier for those trust anchors to be integrated into user environments.
本文档旨在详细说明发布此类信任锚的方式，目的是使这些信任锚更容易集成到用户环境中。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, <http://www.rfc-editor.org/info/rfc2986>.
[RFC2986]Nystrom，M.和B.Kaliski，“PKCS#10：认证请求语法规范版本1.7”，RFC 2986，DOI 10.17487/RFC2986，2000年11月<http://www.rfc-editor.org/info/rfc2986>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <http://www.rfc-editor.org/info/rfc3339>.
[RFC3339]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，DOI 10.17487/RFC3339，2002年7月<http://www.rfc-editor.org/info/rfc3339>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<http://www.rfc-editor.org/info/rfc4033>.
[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, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 4034，DOI 10.17487/RFC4034，2005年3月<http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，DOI 10.17487/RFC4035，2005年3月<http://www.rfc-editor.org/info/rfc4035>.
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, DOI 10.17487/RFC4509, May 2006, <http://www.rfc-editor.org/info/rfc4509>.
[RFC4509]Hardaker，W.“SHA-256在DNSSEC委托签署人（DS）资源记录（RRs）中的使用”，RFC 4509，DOI 10.17487/RFC4509，2006年5月<http://www.rfc-editor.org/info/rfc4509>.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, <http://www.rfc-editor.org/info/rfc5011>.
[RFC5011]StJohns，M.“DNS安全（DNSSEC）信任锚的自动更新”，STD 74，RFC 5011，DOI 10.17487/RFC5011，2007年9月<http://www.rfc-editor.org/info/rfc5011>.
[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, <http://www.rfc-editor.org/info/rfc5155>.
[RFC5155]Laurie，B.，Sisson，G.，Arends，R.，和D.Blacka，“DNS安全（DNSSEC）哈希认证拒绝存在”，RFC 5155，DOI 10.17487/RFC5155，2008年3月<http://www.rfc-editor.org/info/rfc5155>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 5652，DOI 10.17487/RFC5652，2009年9月<http://www.rfc-editor.org/info/rfc5652>.
[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, <http://www.rfc-editor.org/info/rfc5702>.
[RFC5702]Jansen，J.，“在DNSSEC的DNSKEY和RRSIG资源记录中使用带有RSA的SHA-2算法”，RFC 5702，DOI 10.17487/RFC5702，2009年10月<http://www.rfc-editor.org/info/rfc5702>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, <http://www.rfc-editor.org/info/rfc6781>.
[RFC6781]Kolkman，O.，Mekking，W.和R.Gieben，“DNSSEC操作规程，第2版”，RFC 6781，DOI 10.17487/RFC6781，2012年12月<http://www.rfc-editor.org/info/rfc6781>.
[DPS] Ljunggren, F., Okubo, T., Lamb, R., and J. Schlyter, "DNSSEC Practice Statement for the Root Zone KSK Operator", October 2015, <https://www.iana.org/dnssec/icann-dps.txt>.
[DPS]Ljunggren，F.，Okubo，T.，Lamb，R.，和J.Schlyter，“根区KSK运营商DNSSEC实践声明”，2015年10月<https://www.iana.org/dnssec/icann-dps.txt>.
[RELAX-NG] Clark, J., "RELAX NG Compact Syntax", Committee Specification, November 2002, <https://www.oasis-open.org/committees/relax-ng/ compact-20021121.html>.
[RELAX-NG]Clark，J.，“RELAX-NG紧凑语法”，委员会规范，2002年11月<https://www.oasis-open.org/committees/relax-ng/ compact-20021121.html>。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, <http://www.rfc-editor.org/info/rfc4880>.
[RFC4880]Callas，J.，Donnerhacke，L.，Finney，H.，Shaw，D.，和R.Thayer，“OpenPGP消息格式”，RFC 4880，DOI 10.17487/RFC4880，2007年11月<http://www.rfc-editor.org/info/rfc4880>.
The first KSK for use in the root zone of the DNS was generated at a key ceremony at an ICANN Key Management Facility (KMF) in Culpeper, Virginia, USA on 2010-06-16. This key entered production during a second key ceremony held at an ICANN KMF in El Segundo, California, USA on 2010-07-12. The resulting trust anchor was first published on 2010-07-15.
2010年6月16日，在美国弗吉尼亚州卡佩珀的ICANN密钥管理设施（KMF）举行的密钥仪式上，生成了第一个用于DNS根区域的KSK。2010年7月12日，在美国加利福尼亚州El Segundo的ICANN KMF举行的第二次钥匙仪式上，这把钥匙投入生产。由此产生的信托锚首次发表于2010年7月15日。
Acknowledgements
致谢
Many pioneers paved the way for the deployment of DNSSEC in the root zone of the DNS, and the authors hereby acknowledge their substantial collective contribution.
许多先驱者为在DNS根区域部署DNSSEC铺平了道路，作者在此承认他们的重大集体贡献。
This document incorporates suggestions made by Alfred Hoenes and Russ Housley, whose contributions are appreciated.
本文件采纳了阿尔弗雷德·霍恩斯（Alfred Hoenes）和罗斯·霍斯利（Russ Housley）提出的建议，感谢他们的贡献。
Authors' Addresses
作者地址
Joe Abley Dyn, Inc. 300-184 York Street London, ON N6A 1B5 Canada
Joe Abley Dyn，Inc.位于加拿大N6A 1B5，伦敦约克街300-184号
Phone: +1 519 670 9327
Email: jabley@dyn.com
Phone: +1 519 670 9327
Email: jabley@dyn.com
Jakob Schlyter Kirei AB
雅各布·施莱特·基雷律师事务所
Email: jakob@kirei.se
Email: jakob@kirei.se
Guillaume Bailey Independent
纪尧姆贝利独立报
Email: GuillaumeBailey@outlook.com
Email: GuillaumeBailey@outlook.com
Paul Hoffman ICANN
保罗·霍夫曼·伊坎
Email: paul.hoffman@icann.org
Email: paul.hoffman@icann.org