[要約] RFC 7958は、ルートゾーンのDNSSEC信頼アンカーの公開に関するガイドラインです。その目的は、信頼できるDNSSECアンカーの公開プロセスを確立し、インターネットのセキュリティを向上させることです。
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）のルートゾーンは、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 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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
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].
ドメインネームシステム（DNS）は、[RFC1034]と[RFC1035]で説明されています。 DNS Security Extensions（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プロトコルが機能するには、1つ以上のトラストアンカーが必要です。
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機能です。対応するキー管理プラクティスの詳細な説明は、[https]のIANAリポジトリから取得できる[DPS]にあります。
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はその変更をWebサイト<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]で使用できる初期トラストアンカーを確立する1つの方法について説明します。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
IANA publishes trust anchors for the root zone in three formats:
IANAは、ルートゾーンのトラストアンカーを3つの形式で公開します。
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 DSレコードとDNSKEYレコードの完全な公開鍵を含むPKIX形式[RFC5280]の証明書
o Certificate Signing Requests (CSRs) in PKCS #10 format [RFC2986] that contain DS records and the full public key of DNSKEY records
o DSレコードとDNSKEYレコードの完全な公開鍵を含むPKCS＃10形式[RFC2986]の証明書署名要求（CSR）
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.
トラストアンカーの公開に使用されるドキュメントのRELAX NGコンパクトスキーマ[RELAX-NG]を図1に示します。
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 = element TrustAnchor {attribute id {xsd：string}、attribute source {xsd：string}、element Zone {xsd：string}、
keydigest+ }
keydigest +}
keydigest = element KeyDigest { attribute id { xsd:string }, attribute validFrom { xsd:dateTime }, attribute validUntil { xsd:dateTime }?,
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 }
}
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要素には、1つ以上の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属性で指定された時間範囲外の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 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レコードのハッシュの16進数表現が含まれています。
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:
KeyDigest要素に相当するDSレコードの表示形式は、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>
The DS record would be:
DSレコードは次のようになります。
. IN DS 19036 8 2
49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
Figure 2 describes two fictitious trust anchors for the root zone.
図2は、ルートゾーンの2つの架空のトラストアンカーを示しています。
<?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>
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".
OU：文字列「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：[RFC3339]で指定された形式でのキー生成の日時が後に続く文字列「ルートゾーンKSK」。たとえば、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) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
ベギン
-- EXPORTS ALL --
-すべてエクスポート-
IMPORTS
輸入
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-dns OBJECT IDENTIFIER ::= { iana 53 }
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"は、セクション2.1.2で説明されている、XMLファイルのKeyDigest要素。
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」属性を「KEYDIGEST-ID」という文字列に置き換えています。セクション2.1.2で説明されているように、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. 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]署名を最初のトラストアンカーパブリケーションの2番目の並列検証メカニズムとして提供しましたが、将来この並列メカニズムを使用しないことを示しています。）
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を信頼する場合、データの出所を保証するために、HTTPの代わりにHTTPSを使用する必要があります。
This document defines id-mod-dns-resource-record, value 70 (see Section 2.2), in the "SMI Security for PKIX Module Identifier" registry.
このドキュメントでは、「SMI Security for PKIX Module Identifier」レジストリでid-mod-dns-resource-record、値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：Certification Request Syntax Specification Version 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 Securityの紹介と要件」、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 Security Extensionsのリソースレコード」、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。、「DNSSEC委任署名者（DS）リソースレコード（RR）でのSHA-256の使用」、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 Security（DNSSEC）Hashed Authenticated Denial of Existence」、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 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、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。、「Cryptographic Message Syntax（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。、「DNSKEYのRSAを使用したSHA-2アルゴリズムとDNSSECのRRSIGリソースレコードの使用」、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 Operational Practices、Version 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.、and J. Schlyter、 "DNSSEC Practice Statement for the Root Zone KSK Operator"、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]クラーク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 Message Format」、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.
DNSのルートゾーンで使用する最初のKSKは、2010年6月16日、米国バージニア州カルペパーにあるICANNキー管理機能（KMF）でのキーセレモニーで生成されました。このキーは、2010年7月12日、米国カリフォルニア州エルセグンドーのICANN KMFで開催された2番目のキーセレモニーの間に生産に入りました。結果のトラストアンカーは2010-07-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.
多くのパイオニアがDNSSECをDNSのルートゾーンに展開する道を切り開きました。著者はここに、彼らの多大な集団的貢献を認めます。
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. 300-184 York Street London、ON N6A 1B5 Canada
Phone: +1 519 670 9327
Email: jabley@dyn.com
Jakob Schlyter Kirei AB
じゃこｂ Ｓｃｈｌｙてｒ きれい あＢ
Email: jakob@kirei.se
Guillaume Bailey Independent
ギヨームベイリーインディペンデント
Email: GuillaumeBailey@outlook.com
Paul Hoffman ICANN
ポール・ホフマンICANN
Email: paul.hoffman@icann.org