Internet Engineering Task Force (IETF) J. Abley
Request for Comments: 9718 Cloudflare
Obsoletes: 7958 J. Schlyter
Category: Informational Kirei AB
ISSN: 2070-1721 G. Bailey
Independent
P. Hoffman
ICANN
January 2025
The root zone of the global Domain Name System (DNS) is cryptographically signed using DNS Security Extensions (DNSSEC).
グローバルドメインネームシステム（DNS）のルートゾーンは、DNSセキュリティ拡張（DNSSEC）を使用して暗号的に署名されています。
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 uses to distribute the DNSSEC trust anchors.
DNSSECを使用してDNSのルートゾーンから安全な回答を得るために、クライアントは適切なトラストアンカーを設定する必要があります。このドキュメントでは、IANAがDNSSECトラストアンカーを配布するために使用する形式と公開メカニズムについて説明します。
This document obsoletes RFC 7958.
このドキュメントはRFC 7958を廃止します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程の仕様書ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントはInternet Engineering Task Force (IETF)の成果物です。これはIETFコミュニティの合意を表しています。公開レビューを受け、Internet Engineering Steering Group (IESG)による公開が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のいずれかのレベルの候補になるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9718.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9718 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 IETF Trustおよびドキュメントの著者として特定された人物。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 of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントには、このドキュメントに関するお客様の権利と制限が記載されていますので、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、トラスト法的規定のセクション4.eで説明されている改訂BSDライセンステキストが含まれている必要があり、改訂BSDライセンスで説明されているように保証なしで提供されます。
1. Introduction
1.1. Definitions
2. IANA DNSSEC Root Zone Trust Anchor Format and Semantics
2.1. XML Syntax
2.2. XML Semantics
2.3. XML Example
3. Root Zone Trust Anchor Retrieval
3.1. Retrieving Trust Anchors with HTTPS and HTTP
3.2. Accepting DNSSEC Trust Anchors
3.3. Changes in the Trust Model for Distribution
4. Security Considerations
4.1. Security Considerations for Relying Parties
4.1.1. validUntil
4.1.2. Comparison of Digest and publickeyinfo
4.1.3. Different Outputs from Processing the Trust Anchor File
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Appendix A. Changes from RFC 7958
Appendix B. Historical Note
Acknowledgements
Authors' Addresses
The global Domain Name System (DNS) is described in [RFC1034] and [RFC1035]. DNS Security Extensions (DNSSEC) are described in [RFC9364].
グローバルドメイン名システム（DNS）は、[RFC1034]および[RFC1035]で説明されています。DNSセキュリティ拡張機能（DNSSEC）は[RFC9364]で説明されています。
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プロトコルが機能するには1つ以上のトラストアンカーが必要です。
The publication of trust anchors for the root zone of the DNS is an IANA function performed by ICANN, through its affiliate Public Technical Identifiers (PTI). A detailed description of corresponding key management practices can be found in [DPS].
DNSのルートゾーンのトラストアンカーの公開は、ICANNがその関連会社であるPublic Technical Identifiers（PTI）を通じて実行するIANAの機能です。対応する鍵管理慣行の詳細な説明は、[DPS]に記載されています。
This document describes the formats and distribution methods of DNSSEC trust anchors that are used by IANA for the root zone of the DNS. 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.
このドキュメントでは、IANAがDNSのルートゾーンに使用するDNSSECトラストアンカーの形式と配布方法について説明します。他の組織には、ルートゾーンのDNSSECトラストアンカーを配布するための異なる形式とメカニズムがある場合がありますが、ほとんどのオペレーターとソフトウェアベンダーは、IANAのトラストアンカーに依存することを選択しています。
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 the mechanism defined in [RFC5011].
このドキュメントで説明されている形式と配布方法は、[RFC5011]で説明されている自動化されたDNSSECトラストアンカー更新プロトコルを補完するものであり、代替するものではありません。そのプロトコルは、信頼が既に確立されている場合に、トラストアンカーの安全なインバンド更新を可能にします。このドキュメントでは、[RFC5011]で定義されているメカニズムで使用できる初期トラストアンカーを確立する1つの方法について説明します。
This document obsoletes [RFC7958].
このドキュメントは[RFC7958]を廃止します。
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 all common uses of the term "trust anchor" share the basic idea that the decision to trust this entity is made outside of the system that relies on it.
階層構造を持つ暗号システムでは、トラストアンカーは信頼が仮定され、導出されない権威あるエンティティです。エンティティの形式はシステムによって異なりますが、「トラストアンカー」という用語のすべての一般的な使用法は、このエンティティを信頼するという決定が、それに依存するシステムの外部で行われるという基本的な考え方を共有しています。
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からの信頼できる資料をDelegation Signer (DS) RRに変換したいシステムは、そうすることができます。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、BCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
IANA publishes trust anchors for the root zone as an XML [W3C.REC-xml11-20060816] document that contains the hashes of the DNSKEY records and optionally the keys from the DNSKEY records.
IANAは、DNSKEYレコードのハッシュと、オプションでDNSKEYレコードのキーを含むXML [W3C.REC-xml11-20060816]ドキュメントとして、ルートゾーンのトラストアンカーを公開しています。
This format and the associated semantics are described in the rest of this section.
この形式と関連するセマンティクスについては、本セクションの残りの部分で説明します。
Note that the XML document can have XML comments. For example, IANA might use these comments to add pointers to important information on the IANA website. XML comments are only used as human-readable commentary, not extensions to the grammar.
XMLドキュメントにはXMLコメントを含めることができることに注意してください。たとえば、IANAはこれらのコメントを使用して、IANA Webサイトの重要な情報へのポインタを追加する場合があります。XMLコメントは、文法の拡張ではなく、人間が読める解説としてのみ使用されます。
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 a DS resource.
XMLドキュメントには、ルートゾーンの検証に使用できるDNSKEYレコードのハッシュのセットが含まれています。ハッシュは、DSリソースの定義されたプレゼンテーション形式と一致しています。
The XML document can also contain the keys and flags from the DNSKEY records. The keys and flags are consistent with the defined presentation format of a DNSKEY resource.
XMLドキュメントには、DNSKEYレコードのキーとフラグを含めることもできます。キーとフラグは、DNSKEYリソースの定義されたプレゼンテーション形式と一致しています。
Note that the hashes are mandatory in the syntax, but the keys are optional.
ハッシュは構文上必須ですが、キーはオプションであることに注意してください。
Below is the RELAX NG Compact Schema [RELAX-NG] for the documents used to publish trust anchors:
以下は、トラストアンカーを公開するために使用されるドキュメントのRELAX NG Compact Schema [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" } }
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 attribute in the TrustAnchor element is different than the id attribute 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 Zone element is in presentation format as specified in [RFC1035], including the trailing dot. The root zone is indicated by a single period (.) character without any quotation marks.
TrustAnchor要素内のZone要素は、このコンテナがどのDNSゾーンに適用されるかを示します。Zone要素は、[RFC1035]で指定されているプレゼンテーション形式であり、末尾のドットを含みます。ルートゾーンは、引用符なしの単一のピリオド（.）文字で示されます。
The TrustAnchor element contains one or more KeyDigest elements. Each KeyDigest element represents the digest of a past, current, or potential future DNSKEY record of the zone defined in the Zone element. The values for the elements in the KeyDigest element are defined in [RFC4034]. The IANA registries for DNSSEC-related values are described in [RFC9157].
TrustAnchor要素には、1つ以上のKeyDigest要素が含まれています。各KeyDigest要素は、Zone要素で定義されたゾーンの過去、現在、または潜在的な将来のDNSKEYレコードのダイジェストを表します。KeyDigest要素内の要素の値は[RFC4034]で定義されています。DNSSEC関連の値のIANAレジストリは[RFC9157]で説明されています。
The id attribute in the KeyDigest element is an opaque string that identifies the hash. Note that the id attribute in the KeyDigest element is different than the id attribute in the TrustAnchor element described above.
KeyDigest要素のid属性は、ハッシュを識別する不透明な文字列です。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.
KeyDigest要素のvalidFromおよびvalidUntil属性は、KeyDigest要素をトラストアンカーとして使用できる期間の範囲を指定します。
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 DNSSEC signing algorithm identifier for the DNSKEY record represented in this KeyDigest.
KeyDigest要素内のAlgorithm要素には、このKeyDigestで表されるDNSKEYレコードのDNSSEC署名アルゴリズム識別子が含まれています。
The DigestType element in the KeyDigest element contains the DNSSEC digest algorithm identifier for the DNSKEY record represented in this KeyDigest.
KeyDigest要素内のDigestType要素には、このKeyDigestで表されるDNSKEYレコードのDNSSECダイジェストアルゴリズム識別子が含まれています。
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レコードのハッシュの16進表現が含まれています。
The publickeyinfo named pattern in the KeyDigest element contains two mandatory elements: the base64 representation of the public key for the DNSKEY record represented in this KeyDigest and the flags of the DNSKEY record represented in this KeyDigest. The publickeyinfo named pattern is optional and is new in this specification. It can be useful when IANA has a trust anchor that has not yet been published in the DNS root and for calculating a comparison to the Digest element.
KeyDigest要素内のpublickeyinfoという名前のパターンには、2つの必須要素が含まれています。このKeyDigestで表されるDNSKEYレコードの公開鍵のbase64表現と、このKeyDigestで表されるDNSKEYレコードのフラグです。publickeyinfoという名前のパターンはオプションであり、この仕様で新しく追加されたものです。これは、IANAがDNSルートでまだ公開されていないトラストアンカーを持っている場合や、Digest要素との比較を計算する場合に役立ちます。
The following is an example of what the trust anchor file might look like. The full public key is only given for a trust anchor that does not have a validFrom time in the past.
以下は、トラストアンカーファイルがどのように見えるかの例です。完全な公開鍵は、過去のvalidFrom時刻を持たないトラストアンカーに対してのみ提供されます。
<?xml version="1.0" encoding="UTF-8"?>
<TrustAnchor id="E9724F53-1851-4F86-85E5-F1392102940B"
source="http://data.iana.org/root-anchors/root-anchors.xml">
<Zone>.</Zone>
<KeyDigest id="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>
<KeyDigest id="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 -->
<KeyDigest id="Kmyv6jo" validFrom="2024-07-18T00:00:00+00:00">
<KeyTag>38696</KeyTag>
<Algorithm>8</Algorithm>
<DigestType>2</DigestType>
<Digest>
683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
</Digest>
</KeyDigest>
</TrustAnchor>
The DS RRset derived from this example is:
この例から派生したDS RRSetは次のとおりです。
. IN DS 20326 8 2
E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
. IN DS 38696 8 2
683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
Note that this DS record set only has two records. A potential third record, one that includes the key tag 19036, is already invalid based on the validUntil attribute's value and is thus not part of the trust anchor set.
このDSレコードセットには2つのレコードしかないことに注意してください。キータグ19036を含む潜在的な3番目のレコードは、validUntil属性の値に基づいてすでに無効であるため、トラストアンカーセットの一部ではありません。
The DNSKEY RRset derived from this example is:
この例から派生したDNSKEY RRsetは次のとおりです。
. IN DNSKEY 257 3 8
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=
Note that this DNSKEY record set only has one record. A potential second record, one based on the key tag 19036, is already invalid based on the validUntil attribute's value and is thus not part of the trust anchor set. Another potential second record, one based on the key tag 38696, does not contain the optional publickeyinfo named pattern; therefore, the DNSKEY record for it cannot be calculated.
このDNSKEYレコードセットには1つのレコードしかないことに注意してください。キータグ19036に基づく潜在的な2番目のレコードは、validUntil属性の値に基づいてすでに無効であるため、トラストアンカーセットの一部ではありません。キータグ38696に基づく別の潜在的な2番目のレコードには、オプションのpublickeyinfoという名前のパターンが含まれていません。したがって、そのDNSKEYレコードは計算できません。
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 in the XML document described in Section 2 is <https://data.iana.org/root-anchors/root-anchors.xml>.
セクション2で説明されているXMLドキュメント内のハッシュのセットを取得するためのURLは <https://data.iana.org/root-anchors/root-anchors.xml> です。
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.
ICANN CAはDNSSECトラストアンカーではないことに注意することが重要です。代わりに、XMLおよび証明書トラストアンカーの内容と起源を検証するためのオプションのメカニズムです。
The content and origin of the XML document 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 document. This can be useful for validator operators who have received a copy of the ICANN CA's public key in a trusted out-of-band fashion. The URL for a detached CMS signature for the XML document is <https://data.iana.org/root-anchors/root-anchors.p7s>.
XMLドキュメントの内容と起源は、ファイル上のデジタル署名を使用して検証できます。IANAは、XMLドキュメントとともにICANN CAに連鎖する分離された暗号メッセージ構文（CMS）[RFC5652]署名を提供します。これは、ICANN CAの公開鍵のコピーを信頼できる帯域外の方法で受け取ったバリデータオペレーターにとって役立ちます。XMLドキュメントの分離されたCMS署名のURLは <https://data.iana.org/root-anchors/root-anchors.p7s> です。
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が使用する別の方法は、トラストアンカーの配布にTransport Layer Security（TLS）プロトコルを使用することです。現在、「data.iana.org」に使用されているCAはよく知られているもの、つまりWebTrust認定CAです。トラストアンカーを取得するシステムが、IANAが「data.iana.org」Webサーバーに使用しているCAを信頼する場合、データの起源を保証するためにHTTPの代わりにHTTPSを使用する必要があります（SHOULD）。
IANA used to distribute trust anchors as a self-signed Pretty Good Privacy (PGP) message and as a self-issued certificate signing request; this was described in [RFC7958]. This document removes those methods because they rely on a trust model that mixes out-of-band trust of authentication keys with out-of-band trust of the DNSSEC root keys. Note, however, that cryptographic assurance for the contents of the trust anchor now comes from the Web PKI or the ICANN CA as described in Section 3.2. This cryptographic assurance is bolstered by informal comparisons made by users of the trust anchors, such as software vendors comparing the trust anchor files they are using.
IANAは以前、自己署名されたPretty Good Privacy（PGP）メッセージとして、また自己発行された証明書署名要求としてトラストアンカーを配布していました。これは[RFC7958]で説明されていました。このドキュメントでは、認証キーの帯域外の信頼とDNSSECルートキーの帯域外の信頼を混在させる信頼モデルに依存しているため、これらの方法を削除します。ただし、トラストアンカーの内容に対する暗号化保証は、セクション3.2で説明されているように、Web PKIまたはICANN CAから得られるようになったことに注意してください。この暗号化保証は、使用しているトラストアンカーファイルを比較するソフトウェアベンダーなど、トラストアンカーのユーザーによる非公式な比較によって強化されています。
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クライアントは、検証を実行するために、IANAが発行したDNSルートのトラストアンカーのみを設定します。その結果、トラストアンカーの信頼できる公開が重要になります。
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. Some of the methods described (such as accessing over the Web with or without verifying the signature on the file) have different security properties; users of the trust anchor file need to consider these when choosing whether to load the set of trust anchors.
このドキュメントは、そのようなトラストアンカーが公開される手段を慎重に指定し、それらのトラストアンカーをユーザー環境に統合しやすくすることを目的としています。説明されている方法の一部（ファイルの署名を検証するかどうかにかかわらずWeb経由でアクセスするなど）には、異なるセキュリティプロパティがあります。トラストアンカーファイルのユーザーは、トラストアンカーのセットをロードするかどうかを選択する際にこれらを考慮する必要があります。
The body of this document does not specify any particular behavior for relying parties. Specifically, it does not say how a relying party should treat the trust anchor file as a whole. However, some of the contents of the trust anchor file require particular attention for relying parties.
このドキュメントの本文では、リライングパーティに対する特定の動作を指定していません。具体的には、リライングパーティがトラストアンカーファイル全体をどのように扱うべきかについては述べていません。ただし、トラストアンカーファイルの内容の一部には、リライングパーティにとって特別な注意が必要です。
Note that the validUntil attribute of the KeyDigest element is optional. If the relying party is using a trust anchor that has a KeyDigest element that does not have a validUntil attribute, it can change to a trust anchor with a KeyDigest element that does have a validUntil attribute, as long as that trust anchor's validUntil attribute is in the future and the KeyTag, Algorithm, DigestType, and Digest elements of the KeyDigest are the same as those in the previous trust anchor.
KeyDigest要素のvalidUntil属性はオプションであることに注意してください。リライングパーティがvalidUntil属性を持たないKeyDigest要素を持つトラストアンカーを使用している場合、そのトラストアンカーのvalidUntil属性が未来であり、KeyDigestのKeyTag、Algorithm、DigestType、およびDigest要素が以前のトラストアンカーのものと同じである限り、validUntil属性を持つKeyDigest要素を持つトラストアンカーに変更できます。
Relying parties SHOULD NOT use a KeyDigest outside of the time range given in the validFrom and validUntil attributes.
リライングパーティは、validFromおよびvalidUntil属性で指定された時間範囲外でKeyDigestを使用すべきではありません（SHOULD NOT）。
A KeyDigest element can contain both a Digest and a publickeyinfo named pattern. If the Digest element would not be a proper DS record for a DNSKEY record represented by the publickeyinfo named pattern, relying parties MUST NOT use that KeyDigest as a trust anchor. A relying party that wants to make such a comparison needs to marshal the elements of the DNSKEY record that became the DS record using the algorithm specified in Section 5.1.4 of [RFC4034].
KeyDigest要素には、Digestとpublickeyinfoという名前のパターンの両方を含めることができます。Digest要素がpublickeyinfoという名前のパターンで表されるDNSKEYレコードに対する適切なDSレコードにならない場合、リライングパーティはそのKeyDigestをトラストアンカーとして使用してはなりません（MUST NOT）。このような比較を行いたいリライングパーティは、[RFC4034]のセクション5.1.4で指定されたアルゴリズムを使用して、DSレコードとなるDNSKEYレコードの要素をマーシャリングする必要があります。
Relying parties need to implement trust anchor matching carefully. A single trust anchor represented by a KeyDigest element can potentially change its Digest and KeyTag values between two versions of the trust anchor file, for example, when the key is revoked or the flag value changes for some other reason. Relying parties that fail to take this property into account are at risk of using an incorrect set of trust anchors.
リライングパーティは、トラストアンカーのマッチングを慎重に実装する必要があります。KeyDigest要素で表される単一のトラストアンカーは、たとえばキーが取り消されたり、その他の理由でフラグ値が変更されたりした場合に、トラストアンカーファイルの2つのバージョン間でDigestとKeyTagの値を変更する可能性があります。この特性を考慮しないリライングパーティは、誤ったトラストアンカーのセットを使用するリスクがあります。
Relying parties that require the optional publickeyinfo named pattern to create trust anchors will store fewer trust anchors than those that only require a Digest element. Thus, two systems processing the same trust anchor file can end up with a different set of trust anchors.
トラストアンカーを作成するためにオプションのpublickeyinfoという名前のパターンを必要とするリライングパーティは、Digest要素のみを必要とするリライングパーティよりも少ないトラストアンカーを保存します。したがって、同じトラストアンカーファイルを処理する2つのシステムが、異なるトラストアンカーのセットを持つことになる可能性があります。
Each time IANA produces a new trust anchor, it MUST publish that trust anchor using the format described in this document.
IANAが新しいトラストアンカーを作成するたびに、このドキュメントで説明されている形式を使用してそのトラストアンカーを公開しなければなりません（MUST）。
IANA MAY delay the publication of a new trust anchor for operational reasons, such as having a newly created key in multiple facilities.
IANAは、複数の施設に新しく作成されたキーがあるなど、運用上の理由で新しいトラストアンカーの公開を遅らせることができます（MAY）。
When a trust anchor that was previously published is no longer suitable for use, IANA MUST update the trust anchor file accordingly by setting a validUntil date for that trust anchor. The validUntil attribute that is added MAY be a date in the past or in the future, depending on IANA's operational choices.
以前に公開されたトラストアンカーが使用に適さなくなった場合、IANAはそのトラストアンカーにvalidUntil日付を設定することにより、それに応じてトラストアンカーファイルを更新しなければなりません（MUST）。追加されるvalidUntil属性は、IANAの運用上の選択に応じて、過去または将来の日付になる場合があります（MAY）。
More information about IANA's policies and procedures for how the cryptographic keys for the DNS root zone are managed (also known as "DNSSEC Practice Statements" or "DPSs") can be found at <https://www.iana.org/dnssec/procedures>.
DNSルートゾーンの暗号鍵がどのように管理されるかに関するIANAのポリシーと手順（「DNSSEC実践ステートメント」または「DPS」とも呼ばれます）の詳細については、<https://www.iana.org/dnssec/procedures> を参照してください。
[RFC7958] defined id-mod-dns-resource-record, value 70, which was added to the "SMI Security for PKIX Module Identifier" registry. This document does not use that identifier.
[RFC7958]は id-mod-dns-resource-record（値70）を定義し、これは「SMI Security for PKIX Module Identifier」レジストリに追加されました。このドキュメントでは、その識別子を使用しません。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://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,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC5011] 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>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC7958] 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>.
[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>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>.
[W3C.REC-xml11-20060816]
Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E.,
Yergeau, F., and J. Cowan, "Extensible Markup Language
(XML) 1.1 (Second Edition)", W3C Recommendation REC-
xml11-20060816, 16 August 2006,
<https://www.w3.org/TR/2006/REC-xml11-20060816>.
[DPS] Root Zone KSK Operator Policy Management Authority,
"DNSSEC Practice Statement for the Root Zone KSK
Operator", <https://www.iana.org/dnssec/procedures>.
[RELAX-NG] Clark, J., "RELAX NG Compact Syntax", OASIS Committee
Specification, November 2002, <https://www.oasis-
open.org/committees/relax-ng/compact-20021121.html>.
This document includes the following changes:
このドキュメントには、次の変更が含まれています。
* Made a significant technical change per Erratum ID 5932 <https://www.rfc-editor.org/errata/eid5932>. This change is in the seventh paragraph of Section 2.2.
* Erratum ID 5932 <https://www.rfc-editor.org/errata/eid5932> に基づき、重要な技術的変更を行いました。この変更は、セクション2.2の第7段落にあります。
* Added the optional publickeyinfo named pattern with two mandatory elements, PublicKey and Flags.
* 2つの必須要素、PublicKeyとFlagsを使用して、オプションのPublicKeyInfoという名前のパターンを追加しました。
* Removed the certificates and certificate signing mechanisms.
* 証明書と証明書の署名メカニズムを削除しました。
* Removed the detached OpenPGP signature mechanism.
* 分離したOpenPGP署名メカニズムを削除しました。
* Updated the reference to the DNSSEC Practice Statement [DPS].
* DNSSEC実践ステートメント[DPS]への参照を更新しました。
* Stated explicitly that the XML documents might have XML comments in them.
* XMLドキュメントにはXMLコメントが含まれている可能性があると明示的に述べました。
* Clarified the use of the detached CMS signature.
* 分離したCMS署名の使用を明確にしました。
* Updated the IANA Considerations section to indicate requirements on IANA.
* IANAの要件を示すために、IANAの考慮事項セクションを更新しました。
* Simplified the description of using the validFrom and validUntil attributes.
* validFromおよびvalidUntil属性の使用に関する説明を簡素化しました。
* Added new security considerations.
* 新しいセキュリティに関する考慮事項を追加しました。
* Made some editorial changes.
* 編集上の変更を加えました。
The first Key Signing Key (KSK) for use in the root zone of the DNS was generated at a key ceremony at the 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.
DNSのルートゾーンで使用するための最初の鍵署名鍵（KSK）は、2010年6月16日に米国バージニア州カルペパーにあるICANN鍵管理施設（KMF）でのキーセレモニーで生成されました。この鍵は、2010年7月12日に米国カリフォルニア州エルセグンドのICANN KMFで開催された2回目のキーセレモニーで運用に入りました。結果として得られたトラストアンカーは、2010年7月15日に最初に公開されました。
The second KSK for use in the root zone of the DNS was generated at key ceremony #27 at the ICANN KMF in Culpeper, Virginia, USA on 2016-10-27. This key entered production during key ceremony #28 held at the ICANN KMF in El Segundo, California, USA on 2017-02-02. The resulting trust anchor was first published on 2018-11-11.
DNSのルートゾーンで使用する2番目のKSKは、2016年10月27日に米国バージニア州カルペパーのICANN KMFで行われたキーセレモニー#27で生成されました。このキーは、2017年2月2日に米国カリフォルニア州エルセグンドのICANN KMFで開催されたキーセレモニー#28で運用に入りました。結果として得られたトラストアンカーは、2018年11月11日に最初に公開されました。
More information about the key ceremonies, including full records of previous ceremonies and plans for future ceremonies, can be found at <https://www.iana.org/dnssec/ceremonies>.
以前のセレモニーの完全な記録や将来のセレモニーの計画など、キーセレモニーの詳細については、<https://www.iana.org/dnssec/ceremonies> をご覧ください。
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の展開への道を開きました。著者はここに彼らの多大な集団的貢献を認めます。
RFC 7958 incorporated suggestions made by Alfred Hoenes and Russ Housley, whose contributions are appreciated.
RFC 7958には、Alfred HoenesとRuss Housleyによる提案が組み込まれており、彼らの貢献に感謝します。
Joe Abley
Cloudflare
Amsterdam
Netherlands
Email: jabley@cloudflare.com
Jakob Schlyter
Kirei AB
Email: jakob@kirei.se
Guillaume Bailey
Independent
Email: guillaumebailey@outlook.com
Paul Hoffman
ICANN
Email: paul.hoffman@icann.org