[要約] RFC 5155は、DNSセキュリティ（DNSSEC）のハッシュ認証済み存在拒否に関する規格であり、DNSSECにおける拒否の存在を保証するための手法を提供しています。このRFCの目的は、DNSSECのセキュリティを向上させ、偽の情報や攻撃から保護することです。
Network Working Group B. Laurie
Request for Comments: 5155 G. Sisson
Category: Standards Track R. Arends
Nominet
D. Blacka
VeriSign, Inc.
March 2008
DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
DNSセキュリティ（DNSSEC）は、認証された存在の拒否をハッシュする
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones.
ドメイン名システムセキュリティ（DNSSEC）拡張機能は、認証された存在拒否のためにNSECリソースレコード（RR）を導入しました。このドキュメントでは、代替リソースレコードNSEC3を紹介します。これは、同様に認証された存在の拒否を提供します。ただし、ゾーン列挙に対する措置も提供し、委任中心のゾーンの段階的な拡大を許可します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 6
3. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 7
3.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 8
3.1.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 8
3.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 8
3.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.6. Hash Length . . . . . . . . . . . . . . . . . . . . . 9
3.1.7. Next Hashed Owner Name . . . . . . . . . . . . . . . . 9
3.1.8. Type Bit Maps . . . . . . . . . . . . . . . . . . . . 9
3.2. NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 9
3.2.1. Type Bit Maps Encoding . . . . . . . . . . . . . . . . 10
3.3. Presentation Format . . . . . . . . . . . . . . . . . . . 11
4. The NSEC3PARAM Resource Record . . . . . . . . . . . . . . . . 12
4.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 12
4.1.2. Flag Fields . . . . . . . . . . . . . . . . . . . . . 12
4.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 13
4.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 13
4.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. NSEC3PARAM RDATA Wire Format . . . . . . . . . . . . . . . 13
4.3. Presentation Format . . . . . . . . . . . . . . . . . . . 14
5. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 14
6. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Authoritative Server Considerations . . . . . . . . . . . . . 16
7.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 17
7.2.1. Closest Encloser Proof . . . . . . . . . . . . . . . . 18
7.2.2. Name Error Responses . . . . . . . . . . . . . . . . . 19
7.2.3. No Data Responses, QTYPE is not DS . . . . . . . . . . 19
7.2.4. No Data Responses, QTYPE is DS . . . . . . . . . . . . 19
7.2.5. Wildcard No Data Responses . . . . . . . . . . . . . . 19
7.2.6. Wildcard Answer Responses . . . . . . . . . . . . . . 20
7.2.7. Referrals to Unsigned Subzones . . . . . . . . . . . . 20
7.2.8. Responding to Queries for NSEC3 Owner Names . . . . . 20
7.2.9. Server Response to a Run-Time Collision . . . . . . . 21
7.3. Secondary Servers . . . . . . . . . . . . . . . . . . . . 21
7.4. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 21
7.5. Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 21
8. Validator Considerations . . . . . . . . . . . . . . . . . . . 23
8.1. Responses with Unknown Hash Types . . . . . . . . . . . . 23
8.2. Verifying NSEC3 RRs . . . . . . . . . . . . . . . . . . . 23
8.3. Closest Encloser Proof . . . . . . . . . . . . . . . . . . 23
8.4. Validating Name Error Responses . . . . . . . . . . . . . 24
8.5. Validating No Data Responses, QTYPE is not DS . . . . . . 24
8.6. Validating No Data Responses, QTYPE is DS . . . . . . . . 24
8.7. Validating Wildcard No Data Responses . . . . . . . . . . 25
8.8. Validating Wildcard Answer Responses . . . . . . . . . . . 25
8.9. Validating Referrals to Unsigned Subzones . . . . . . . . 25
9. Resolver Considerations . . . . . . . . . . . . . . . . . . . 26
9.1. NSEC3 Resource Record Caching . . . . . . . . . . . . . . 26
9.2. Use of the AD Bit . . . . . . . . . . . . . . . . . . . . 26
10. Special Considerations . . . . . . . . . . . . . . . . . . . . 26
10.1. Domain Name Length Restrictions . . . . . . . . . . . . . 26
10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 27
10.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 27
10.4. Transitioning a Signed Zone from NSEC to NSEC3 . . . . . . 28
10.5. Transitioning a Signed Zone from NSEC3 to NSEC . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
12. Security Considerations . . . . . . . . . . . . . . . . . . . 30
12.1. Hashing Considerations . . . . . . . . . . . . . . . . . . 30
12.1.1. Dictionary Attacks . . . . . . . . . . . . . . . . . . 30
12.1.2. Collisions . . . . . . . . . . . . . . . . . . . . . . 31
12.1.3. Transitioning to a New Hash Algorithm . . . . . . . . 31
12.1.4. Using High Iteration Values . . . . . . . . . . . . . 31
12.2. Opt-Out Considerations . . . . . . . . . . . . . . . . . . 32
12.3. Other Considerations . . . . . . . . . . . . . . . . . . . 33
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
13.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 35
Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 40
B.1. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 40
B.2. No Data Error . . . . . . . . . . . . . . . . . . . . . . 42
B.2.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 43
B.3. Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 44
B.4. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 45
B.5. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 46
B.6. DS Child Zone No Data Error . . . . . . . . . . . . . . . 48
Appendix C. Special Considerations . . . . . . . . . . . . . . . 48
C.1. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 49
C.2. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 49
C.2.1. Avoiding Hash Collisions During Generation . . . . . . 50
C.2.2. Second Preimage Requirement Analysis . . . . . . . . . 50
The DNS Security Extensions included the NSEC RR to provide authenticated denial of existence. Though the NSEC RR meets the requirements for authenticated denial of existence, it introduces a side-effect in that the contents of a zone can be enumerated. This property introduces undesired policy issues.
DNSセキュリティエクステンションには、認証された存在拒否を提供するNSEC RRが含まれていました。NSEC RRは、認証された存在の拒否の要件を満たしていますが、ゾーンの内容を列挙できるという点で副作用が導入されます。このプロパティは、望ましくない政策の問題を導入します。
The enumeration is enabled by the set of NSEC records that exists inside a signed zone. An NSEC record lists two names that are ordered canonically, in order to show that nothing exists between the two names. The complete set of NSEC records lists all the names in a zone. It is trivial to enumerate the content of a zone by querying for names that do not exist.
列挙は、署名されたゾーン内に存在するNSECレコードのセットによって有効になります。NSECレコードには、2つの名前の間に何も存在しないことを示すために、標準的に注文された2つの名前がリストされています。NSECレコードの完全なセットには、ゾーン内のすべての名前がリストされています。存在しない名前をクエリすることにより、ゾーンのコンテンツを列挙することは些細なことです。
An enumerated zone can be used, for example, as a source of probable e-mail addresses for spam, or as a key for multiple WHOIS queries to reveal registrant data that many registries may have legal obligations to protect. Many registries therefore prohibit the copying of their zone data; however, the use of NSEC RRs renders these policies unenforceable.
たとえば、スパムの可能性のある電子メールアドレスのソースとして、または多くのレジストリが保護する法的義務がある可能性のある登録者データを明らかにするための複数のWHOISクエリの鍵として、列挙されたゾーンを使用できます。したがって、多くのレジストリは、ゾーンデータのコピーを禁止しています。ただし、NSEC RRSを使用すると、これらのポリシーは執行不能になります。
A second problem is that the cost to cryptographically secure delegations to unsigned zones is high, relative to the perceived security benefit, in two cases: large, delegation-centric zones, and zones where insecure delegations will be updated rapidly. In these cases, the costs of maintaining the NSEC RR chain may be extremely high and use of the "Opt-Out" convention may be more appropriate (for these unsecured zones).
2番目の問題は、2つのケースで、認知されたセキュリティゾーンと比較して、署名されていないゾーンに暗号化された代表団のコストが高くなることです。これらの場合、NSEC RRチェーンを維持するコストは非常に高く、「オプトアウト」規則の使用がより適切である可能性があります（これらの無担保ゾーンの場合）。
This document presents the NSEC3 Resource Record which can be used as an alternative to NSEC to mitigate these issues.
このドキュメントでは、これらの問題を軽減するためにNSECの代替として使用できるNSEC3リソースレコードを提示します。
Earlier work to address these issues include [DNSEXT-NO], [RFC4956], and [DNSEXT-NSEC2v2].
これらの問題に対処するための以前の研究には、[dnsext-no]、[rfc4956]、および[dnsext-nsec2v2]が含まれます。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The reader is assumed to be familiar with the basic DNS and DNSSEC concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], [RFC4035], and subsequent RFCs that update them: [RFC2136], [RFC2181], and [RFC2308].
読者は、[RFC1034]、[RFC1035]、[RFC4033]、[RFC4034]、[RFC4035]、およびその後のRFCで説明されている基本的なDNSおよびDNSSECの概念に精通していると想定されています。、および[RFC2308]。
The following terminology is used throughout this document:
このドキュメント全体で次の用語が使用されています。
Zone enumeration: the practice of discovering the full content of a zone via successive queries. Zone enumeration was non-trivial prior to the introduction of DNSSEC.
ゾーンの列挙：連続したクエリを介してゾーンの完全な内容を発見する実践。ゾーンの列挙は、DNSSECの導入前に自明ではありませんでした。
Original owner name: the owner name corresponding to a hashed owner name.
元の所有者名：ハッシュされた所有者名に対応する所有者名。
Hashed owner name: the owner name created after applying the hash function to an owner name.
ハッシュオーナー名：ハッシュ関数を所有者名に適用した後に作成された所有者名。
Hash order: the order in which hashed owner names are arranged according to their numerical value, treating the leftmost (lowest numbered) octet as the most significant octet. Note that this order is the same as the canonical DNS name order specified in [RFC4034], when the hashed owner names are in base32, encoded with an Extended Hex Alphabet [RFC4648].
ハッシュオーダー：ハッシュされた所有者名が数値値に従って配置され、左端（最も低い数字の）オクテットを最も重要なオクテットとして扱う順序。この順序は、ハッシュされた所有者名が拡張された16進アルファベット[RFC4648]でエンコードされたBase32である場合、[RFC4034]で指定された標準的なDNS名順序と同じであることに注意してください。
Empty non-terminal: a domain name that owns no resource records, but has one or more subdomains that do.
空の非ターミナル：リソースレコードを所有していないが、1つ以上のサブドメインがあるドメイン名。
Delegation: an NS RRSet with a name different from the current zone apex (non-zone-apex), signifying a delegation to a child zone.
委任：現在のゾーン頂点（ゾーン以外のAPEX）とは異なる名前のNS RRSET。子供ゾーンへの委任を意味します。
Secure delegation: a name containing a delegation (NS RRSet) and a signed DS RRSet, signifying a delegation to a signed child zone.
安全な委任：代表団（NS RRSet）と署名されたDS RRSetを含む名前。
Insecure delegation: a name containing a delegation (NS RRSet), but lacking a DS RRSet, signifying a delegation to an unsigned child zone.
不安定な代表団：代表団（NS RRSet）を含む名前ですが、DS RRSetがなく、署名されていない子供ゾーンへの代表団を意味します。
Opt-Out NSEC3 resource record: an NSEC3 resource record that has the Opt-Out flag set to 1.
オプトアウトNSEC3リソースレコード：オプトアウトフラグを1に設定したNSEC3リソースレコード。
Opt-Out zone: a zone with at least one Opt-Out NSEC3 RR.
オプトアウトゾーン：少なくとも1つのオプトアウトNSEC3 RRを持つゾーン。
Closest encloser: the longest existing ancestor of a name. See also Section 3.3.1 of [RFC4592].
最も近い囲い：名前の最も長い既存の祖先。[RFC4592]のセクション3.3.1も参照してください。
Closest provable encloser: the longest ancestor of a name that can be proven to exist. Note that this is only different from the closest encloser in an Opt-Out zone.
最も近い証明可能な囲い：存在することが証明できる名前の最も長い祖先。これは、オプトアウトゾーンで最も近いエンクロージャーとのみ異なることに注意してください。
Next closer name: the name one label longer than the closest provable encloser of a name.
次の近くの名前：名前の最も近い証明可能なエンクローザーよりも長い名前のラベル。
Base32: the "Base 32 Encoding with Extended Hex Alphabet" as specified in [RFC4648]. Note that trailing padding characters ("=") are not used in the NSEC3 specification.
base32：[RFC4648]で指定されているように、「拡張ヘックスアルファベットを使用したベース32エンコード」。後続のパディング文字（ "="）は、NSEC3仕様では使用されていないことに注意してください。
To cover: An NSEC3 RR is said to "cover" a name if the hash of the name or "next closer" name falls between the owner name and the next hashed owner name of the NSEC3. In other words, if it proves the nonexistence of the name, either directly or by proving the nonexistence of an ancestor of the name.
カバーするために：NSEC3 RRは、名前のハッシュまたは「次の近い」名前が所有者名とNSEC3の次のハッシュオーナー名の間に名前が付いている場合、名前を「カバー」すると言われています。言い換えれば、直接または名前の祖先の存在を証明することにより、名前の存在を証明している場合。
To match: An NSEC3 RR is said to "match" a name if the owner name of the NSEC3 RR is the same as the hashed owner name of that name.
一致する：NSEC3 RRは、NSEC3 RRの所有者名がその名前のハッシュされた所有者名と同じである場合、名前を「一致させる」と言われています。
This specification describes a protocol change that is not generally backwards compatible with [RFC4033], [RFC4034], and [RFC4035]. In particular, security-aware resolvers that are unaware of this specification (NSEC3-unaware resolvers) may fail to validate the responses introduced by this document.
この仕様では、[RFC4033]、[RFC4034]、および[RFC4035]と一般に逆方向に互換性がないプロトコルの変化について説明します。特に、この仕様（NSEC3-Unaware Resolvers）を認識していないセキュリティ認識リゾルバーは、このドキュメントによって導入された応答を検証できない場合があります。
In order to aid deployment, this specification uses a signaling technique to prevent NSEC3-unaware resolvers from attempting to validate responses from NSEC3-signed zones.
展開を支援するために、この仕様では、シグナリング手法を使用して、NSEC3に不名誉なリゾルバーがNSEC3署名ゾーンからの応答を検証しようとしないようにします。
This specification allocates two new DNSKEY algorithm identifiers for this purpose. Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm 3, DSA. Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5, RSASHA1. These are not new algorithms, they are additional identifiers for the existing algorithms.
この仕様には、この目的のために2つの新しいDNSKEYアルゴリズム識別子が割り当てられます。アルゴリズム6、DSA-NSEC3-SHA1は、アルゴリズム3、DSAのエイリアスです。アルゴリズム7、rsasha1-nsec3-sha1は、アルゴリズム5、rsasha1のエイリアスです。これらは新しいアルゴリズムではなく、既存のアルゴリズムの追加の識別子です。
Zones signed according to this specification MUST only use these algorithm identifiers for their DNSKEY RRs. Because these new identifiers will be unknown algorithms to existing, NSEC3-unaware resolvers, those resolvers will then treat responses from the NSEC3 signed zone as insecure, as detailed in Section 5.2 of [RFC4035].
この仕様に従って署名されたゾーンは、DNSKEY RRSのこれらのアルゴリズム識別子のみを使用する必要があります。これらの新しい識別子は、既存のNSEC3-UNAWAREリゾルバーの未知のアルゴリズムになるため、これらのリゾルバーは、[RFC4035]のセクション5.2で詳述されているように、NSEC3署名ゾーンからの応答を不安定として扱います。
These algorithm identifiers are used with the NSEC3 hash algorithm SHA1. Using other NSEC3 hash algorithms requires allocation of a new alias (see Section 12.1.3).
これらのアルゴリズム識別子は、NSEC3ハッシュアルゴリズムSHA1で使用されます。他のNSEC3ハッシュアルゴリズムを使用するには、新しいエイリアスの割り当てが必要です（セクション12.1.3を参照）。
Security aware resolvers that are aware of this specification MUST recognize the new algorithm identifiers and treat them as equivalent to the algorithms that they alias.
この仕様を認識しているセキュリティ認識リゾルバーは、新しいアルゴリズム識別子を認識し、それらをエイリアスするアルゴリズムと同等として扱う必要があります。
A methodology for transitioning from a DNSSEC signed zone to a zone signed using NSEC3 is discussed in Section 10.4.
DNSSEC署名ゾーンからNSEC3を使用して署名されたゾーンに移行する方法については、セクション10.4で説明します。
The NSEC3 Resource Record (RR) provides authenticated denial of existence for DNS Resource Record Sets.
NSEC3リソースレコード（RR）は、DNSリソースレコードセットの認証された存在拒否を提供します。
The NSEC3 RR lists RR types present at the original owner name of the NSEC3 RR. It includes the next hashed owner name in the hash order of the zone. The complete set of NSEC3 RRs in a zone indicates which RRSets exist for the original owner name of the RR and form a chain of hashed owner names in the zone. This information is used to provide authenticated denial of existence for DNS data. To provide protection against zone enumeration, the owner names used in the NSEC3 RR are cryptographic hashes of the original owner name prepended as a single label to the name of the zone. The NSEC3 RR indicates which hash function is used to construct the hash, which salt is used, and how many iterations of the hash function are performed over the original owner name. The hashing technique is described fully in Section 5.
NSEC3 RRは、NSEC3 RRの元の所有者名に存在するRRタイプをリストします。ゾーンのハッシュオーダーに次のハッシュされた所有者名が含まれています。ゾーン内のNSEC3 RRSの完全なセットは、RRの元の所有者名にどのRRSetが存在するかを示し、ゾーン内のハッシュオーナー名のチェーンを形成します。この情報は、DNSデータの認証された存在拒否を提供するために使用されます。ゾーンの列挙に対する保護を提供するために、NSEC3 RRで使用される所有者名は、ゾーンの名前の単一のラベルとして準備された元の所有者名の暗号化ハッシュです。NSEC3 RRは、どのハッシュ関数を使用してハッシュを構築するために使用され、どの塩が使用されるか、元の所有者名でハッシュ関数の反復が実行されるかを示します。ハッシュ技術については、セクション5で完全に説明しています。
Hashed owner names of unsigned delegations may be excluded from the chain. An NSEC3 RR whose span covers the hash of an owner name or "next closer" name of an unsigned delegation is referred to as an Opt-Out NSEC3 RR and is indicated by the presence of a flag.
The owner name for the NSEC3 RR is the base32 encoding of the hashed owner name prepended as a single label to the name of the zone.
NSEC3 RRの所有者名は、ゾーンの名前の単一のラベルとして準備されたハッシュされた所有者名のbase32エンコードです。
The type value for the NSEC3 RR is 50.
NSEC3 RRのタイプ値は50です。
The NSEC3 RR RDATA format is class independent and is described below.
NSEC3 RR RDATA形式はクラスに依存しないもので、以下に説明します。
The class MUST be the same as the class of the original owner name.
クラスは、元の所有者名のクラスと同じでなければなりません。
The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching [RFC2308].
NSEC3 RRは、SOA最小TTLフィールドと同じTTL値を持つ必要があります。これは、ネガティブキャッシュの精神にあります[RFC2308]。
The Hash Algorithm field identifies the cryptographic hash algorithm used to construct the hash-value.
ハッシュアルゴリズムフィールドは、ハッシュ値を構築するために使用される暗号化ハッシュアルゴリズムを識別します。
The values for this field are defined in the NSEC3 hash algorithm registry defined in Section 11.
このフィールドの値は、セクション11で定義されているNSEC3ハッシュアルゴリズムレジストリで定義されています。
The Flags field contains 8 one-bit flags that can be used to indicate different processing. All undefined flags must be zero. The only flag defined by this specification is the Opt-Out flag.
フラグフィールドには、異なる処理を示すために使用できる8つの1ビットフラグが含まれています。未定義のすべてのフラグはゼロでなければなりません。この仕様で定義される唯一のフラグは、オプトアウトフラグです。
If the Opt-Out flag is set, the NSEC3 record covers zero or more unsigned delegations.
オプトアウトフラグが設定されている場合、NSEC3レコードはゼロ以上の署名の代表団をカバーします。
If the Opt-Out flag is clear, the NSEC3 record covers zero unsigned delegations.
オプトアウトフラグがクリアな場合、NSEC3レコードはゼロの署名されていない代表団をカバーします。
The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned delegations. It is the least significant bit in the Flags field. See Section 6 for details about the use of this flag.
オプトアウトフラグは、このNSEC3 RRが署名されていない代表団をカバーする可能性があるかどうかを示します。フラグフィールドでは最も重要なビットです。このフラグの使用の詳細については、セクション6を参照してください。
The Iterations field defines the number of additional times the hash function has been performed. More iterations result in greater resiliency of the hash value against dictionary attacks, but at a higher computational cost for both the server and resolver. See Section 5 for details of the use of this field, and Section 10.3 for limitations on the value.
イテレーションフィールドは、ハッシュ関数が実行された追加回数を定義します。より多くの反復により、辞書攻撃に対するハッシュ値の弾力性が高まりますが、サーバーとリゾルバーの両方で計算コストが高くなります。このフィールドの使用の詳細については、値の制限についてはセクション10.3を参照してください。
The Salt Length field defines the length of the Salt field in octets, ranging in value from 0 to 255.
塩の長さのフィールドは、オクテットの塩場の長さを定義し、値は0から255の範囲です。
The Salt field is appended to the original owner name before hashing in order to defend against pre-calculated dictionary attacks. See Section 5 for details on how the salt is used.
塩フィールドは、事前に計算された辞書攻撃から防御するために、ハッシュする前に元の所有者名に追加されます。塩の使用方法の詳細については、セクション5を参照してください。
The Hash Length field defines the length of the Next Hashed Owner Name field, ranging in value from 1 to 255 octets.
ハッシュの長さフィールドは、値が1〜255オクテットの範囲で、次のハッシュオーナー名フィールドの長さを定義します。
The Next Hashed Owner Name field contains the next hashed owner name in hash order. This value is in binary format. Given the ordered set of all hashed owner names, the Next Hashed Owner Name field contains the hash of an owner name that immediately follows the owner name of the given NSEC3 RR. The value of the Next Hashed Owner Name field in the last NSEC3 RR in the zone is the same as the hashed owner name of the first NSEC3 RR in the zone in hash order. Note that, unlike the owner name of the NSEC3 RR, the value of this field does not contain the appended zone name.
次のハッシュされた所有者名フィールドには、次のハッシュオーナー名がハッシュ順に含まれています。この値はバイナリ形式です。すべてのハッシュされた所有者名の順序付けられたセットを考えると、次のハッシュされた所有者名フィールドには、指定されたNSEC3 RRの所有者名がすぐに続く所有者名のハッシュが含まれています。ゾーン内の最後のNSEC3 RRの次のハッシュオーナー名フィールドの値は、ハッシュ順にゾーンの最初のNSEC3 RRのハッシュオーナー名と同じです。NSEC3 RRの所有者名とは異なり、このフィールドの値には追加されたゾーン名が含まれていないことに注意してください。
The Type Bit Maps field identifies the RRSet types that exist at the original owner name of the NSEC3 RR.
タイプビットマップフィールドは、NSEC3 RRの元の所有者名に存在するRRSetタイプを識別します。
The RDATA of the NSEC3 RR is as shown below:
NSEC3 RRのrdataは以下に示すように、
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash Alg. | Flags | Iterations |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt Length | Salt /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash Length | Next Hashed Owner Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Maps /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hash Algorithm is a single octet.
ハッシュアルゴリズムは単一のオクテットです。
Flags field is a single octet, the Opt-Out flag is the least significant bit, as shown below:
Flagsフィールドは単一のオクテットであり、オプトアウトフラグは以下に示すように、最も重要なビットです。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |O|
+-+-+-+-+-+-+-+-+
Iterations is represented as a 16-bit unsigned integer, with the most
significant bit first.
Salt Length is represented as an unsigned octet. Salt Length represents the length of the Salt field in octets. If the value is zero, the following Salt field is omitted.
塩の長さは、署名されていないオクテットとして表されます。塩の長さは、オクテットの塩磁場の長さを表します。値がゼロの場合、次の塩フィールドは省略されています。
Salt, if present, is encoded as a sequence of binary octets. The length of this field is determined by the preceding Salt Length field.
塩は、存在する場合、バイナリオクテットのシーケンスとしてエンコードされます。このフィールドの長さは、前の塩の長さフィールドによって決定されます。
Hash Length is represented as an unsigned octet. Hash Length represents the length of the Next Hashed Owner Name field in octets.
ハッシュの長さは、署名されていないオクテットとして表されます。ハッシュの長さは、オクテットの次のハッシュオーナー名フィールドの長さを表します。
The next hashed owner name is not base32 encoded, unlike the owner name of the NSEC3 RR. It is the unmodified binary hash value. It does not include the name of the containing zone. The length of this field is determined by the preceding Hash Length field.
NSEC3 RRの所有者名とは異なり、次のハッシュオーナー名はbase32エンコードされていません。これは、変更されていないバイナリハッシュ値です。コンテンディングゾーンの名前は含まれていません。このフィールドの長さは、前のハッシュ長いフィールドによって決定されます。
The encoding of the Type Bit Maps field is the same as that used by the NSEC RR, described in [RFC4034]. It is explained and clarified here for clarity.
[RFC4034]で説明されているNSEC RRが使用したタイプビットマップフィールドのエンコードは同じです。明確にするためにここで説明され、明確にされています。
The RR type space is split into 256 window blocks, each representing the low-order 8 bits of the 16-bit RR type space. Each block that has at least one active RR type is encoded using a single octet window number (from 0 to 255), a single octet bitmap length (from 1 to 32) indicating the number of octets used for the bitmap of the window block, and up to 32 octets (256 bits) of bitmap.
RRタイプスペースは256のウィンドウブロックに分割され、それぞれが16ビットRRタイプスペースの低次8ビットを表します。少なくとも1つのアクティブなRRタイプを持つ各ブロックは、単一のオクテットウィンドウ数（0〜255）、単一のオクテットビットマップ長（1から32）を使用してエンコードされ、ウィンドウブロックのビットマップに使用されるオクテットの数を示します。最大32オクテット（256ビット）のビットマップ。
Blocks are present in the NSEC3 RR RDATA in increasing numerical order.
NSEC3 RR RDATAには、数値順序が増加してブロックが存在します。
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
where "|" denotes concatenation.
ここで「|」連結を示します。
Each bitmap encodes the low-order 8 bits of RR types within the window block, in network bit order. The first bit is bit 0. For window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS), and so forth. For window block 1, bit 1 corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to 1, it indicates that an RRSet of that type is present for the original owner name of the NSEC3 RR. If a bit is set to 0, it indicates that no RRSet of that type is present for the original owner name of the NSEC3 RR.
各ビットマップは、ネットワークビットの順序で、ウィンドウブロック内の低次の8ビットのRRタイプをエンコードします。最初のビットはビット0です。ウィンドウブロック0の場合、ビット1はRRタイプ1（a）に対応し、ビット2はRRタイプ2（NS）などに対応します。ウィンドウブロック1の場合、ビット1はRRタイプ257、ビット2からRRタイプ258に対応します。ビットが1に設定されている場合、NSEC3 RRの元の所有者名にそのタイプのRRセットが存在することを示します。ビットが0に設定されている場合、NSEC3 RRの元の所有者名にそのタイプのRRSetが存在しないことを示します。
Since bit 0 in window block 0 refers to the non-existing RR type 0, it MUST be set to 0. After verification, the validator MUST ignore the value of bit 0 in window block 0.
ウィンドウブロック0のビット0は、存在しないRRタイプ0を指すため、0に設定する必要があります。
Bits representing Meta-TYPEs or QTYPEs as specified in Section 3.1 of [RFC2929] or within the range reserved for assignment only to QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in zone data. If encountered, they must be ignored upon reading.
[RFC2929]のセクション3.1で指定されているメタタイプまたはQTypesを表すビットまたはQTYPESおよびメタタイプへのみ割り当て用に予約されている範囲内で、ゾーンデータに表示されないため、0に設定する必要があります。遭遇した場合、読むときに無視する必要があります。
Blocks with no types present MUST NOT be included. Trailing zero octets in the bitmap MUST be omitted. The length of the bitmap of each block is determined by the type code with the largest numerical value, within that block, among the set of RR types present at the original owner name of the NSEC3 RR. Trailing octets not specified MUST be interpreted as zero octets.
存在するタイプのないブロックを含める必要はありません。ビットマップのトレーリングゼロオクテットを省略する必要があります。各ブロックのビットマップの長さは、NSEC3 RRの元の所有者名に存在するRRタイプのセットの中で、そのブロック内の最大数値のタイプコードによって決定されます。指定されていない後続のオクテットは、ゼロオクテットと解釈する必要があります。
The presentation format of the RDATA portion is as follows:
RDATA部分のプレゼンテーション形式は次のとおりです。
o The Hash Algorithm field is represented as an unsigned decimal integer. The value has a maximum of 255.
o ハッシュアルゴリズムフィールドは、署名されていない小数整数として表されます。値には最大255です。
o The Flags field is represented as an unsigned decimal integer. The value has a maximum of 255.
o フラグフィールドは、署名されていない小数整数として表されます。値には最大255です。
o The Iterations field is represented as an unsigned decimal integer. The value is between 0 and 65535, inclusive.
o イテレーションフィールドは、署名されていない小数整数として表されます。値は0〜65535、包括的です。
o The Salt Length field is not represented.
o 塩の長さのフィールドは表されません。
o The Salt field is represented as a sequence of case-insensitive hexadecimal digits. Whitespace is not allowed within the sequence. The Salt field is represented as "-" (without the quotes) when the Salt Length field has a value of 0.
o 塩フィールドは、症例感受性の六方桁のシーケンスとして表されます。シーケンス内では、Whitespaceは許可されていません。塩フィールドは、塩の長さのフィールドの値が0の場合、「 - 」（引用符なし）として表されます。
o The Hash Length field is not represented.
o ハッシュの長さフィールドは表されません。
o The Next Hashed Owner Name field is represented as an unpadded sequence of case-insensitive base32 digits, without whitespace.
o 次のハッシュされた所有者名フィールドは、空白のないケースに依存しないベース32桁の未貼り付けのシーケンスとして表されます。
o The Type Bit Maps field is represented as a sequence of RR type mnemonics. When the mnemonic is not known, the TYPE representation as described in Section 5 of [RFC3597] MUST be used.
o タイプビットマップフィールドは、RRタイプのニーモニックのシーケンスとして表されます。ニーモニックが知られていない場合、[RFC3597]のセクション5で説明されているタイプ表現を使用する必要があります。
The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm, flags, iterations, and salt) needed by authoritative servers to calculate hashed owner names. The presence of an NSEC3PARAM RR at a zone apex indicates that the specified parameters may be used by authoritative servers to choose an appropriate set of NSEC3 RRs for negative responses. The NSEC3PARAM RR is not used by validators or resolvers.
NSEC3PARAM RRには、権威あるサーバーが所有者名を計算するために必要なNSEC3パラメーター（ハッシュアルゴリズム、フラグ、反復、および塩）が含まれています。ゾーンアペックスでのNSEC3PARAM RRの存在は、指定されたパラメーターが権威あるサーバーが使用して、負の応答のために適切なNSEC3 RRSのセットを選択できることを示しています。NSEC3PARAM RRは、バリデーターまたはリゾルバーによって使用されません。
If an NSEC3PARAM RR is present at the apex of a zone with a Flags field value of zero, then there MUST be an NSEC3 RR using the same hash algorithm, iterations, and salt parameters present at every hashed owner name in the zone. That is, the zone MUST contain a complete set of NSEC3 RRs with the same hash algorithm, iterations, and salt parameters.
NSEC3PARAM RRがゼロのフラグフィールド値を持つゾーンの頂点に存在する場合、ゾーン内のすべてのハッシュされた所有者名に同じハッシュアルゴリズム、反復、および塩パラメーターを使用してNSEC3 RRが必要です。つまり、ゾーンには、同じハッシュアルゴリズム、反復、および塩パラメーターを備えたNSEC3 RRの完全なセットを含める必要があります。
The owner name for the NSEC3PARAM RR is the name of the zone apex.
NSEC3PARAM RRの所有者名は、ゾーンアペックスの名前です。
The type value for the NSEC3PARAM RR is 51.
NSEC3PARAM RRのタイプ値は51です。
The NSEC3PARAM RR RDATA format is class independent and is described below.
NSEC3PARAM RR RDATA形式はクラスに依存しないもので、以下に説明します。
The class MUST be the same as the NSEC3 RRs to which this RR refers.
クラスは、このRRが参照するNSEC3 RRと同じでなければなりません。
The RDATA for this RR mirrors the first four fields in the NSEC3 RR.
このRRのRDATAは、NSEC3 RRの最初の4つのフィールドを反映しています。
The Hash Algorithm field identifies the cryptographic hash algorithm used to construct the hash-value.
ハッシュアルゴリズムフィールドは、ハッシュ値を構築するために使用される暗号化ハッシュアルゴリズムを識別します。
The acceptable values are the same as the corresponding field in the NSEC3 RR.
許容値は、NSEC3 RRの対応するフィールドと同じです。
The Opt-Out flag is not used and is set to zero.
オプトアウトフラグは使用されず、ゼロに設定されています。
All other flags are reserved for future use, and must be zero.
他のすべてのフラグは将来の使用のために予約されており、ゼロでなければなりません。
NSEC3PARAM RRs with a Flags field value other than zero MUST be ignored.
ゼロ以外のフラグフィールド値を持つNSEC3PARAM RRSは無視する必要があります。
The Iterations field defines the number of additional times the hash is performed.
イテレーションフィールドは、ハッシュが実行される追加の回数を定義します。
Its acceptable values are the same as the corresponding field in the NSEC3 RR.
その許容値は、NSEC3 RRの対応するフィールドと同じです。
The Salt Length field defines the length of the salt in octets, ranging in value from 0 to 255.
塩の長さのフィールドは、塩の長さをオクテットの長さを定義し、値は0から255の範囲です。
The Salt field is appended to the original owner name before hashing.
塩フィールドは、ハッシュ前に元の所有者名に追加されます。
The RDATA of the NSEC3PARAM RR is as shown below:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash Alg. | Flags | Iterations |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt Length | Salt /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hash Algorithm is a single octet.
ハッシュアルゴリズムは単一のオクテットです。
Flags field is a single octet.
フラグフィールドは単一のオクテットです。
Iterations is represented as a 16-bit unsigned integer, with the most significant bit first.
イテレーションは16ビットの符号なし整数として表され、最初に最も重要なビットがあります。
Salt Length is represented as an unsigned octet. Salt Length represents the length of the following Salt field in octets. If the value is zero, the Salt field is omitted.
塩の長さは、署名されていないオクテットとして表されます。塩の長さは、オクテットの次の塩場の長さを表します。値がゼロの場合、塩フィールドは省略されます。
Salt, if present, is encoded as a sequence of binary octets. The length of this field is determined by the preceding Salt Length field.
塩は、存在する場合、バイナリオクテットのシーケンスとしてエンコードされます。このフィールドの長さは、前の塩の長さフィールドによって決定されます。
The presentation format of the RDATA portion is as follows:
RDATA部分のプレゼンテーション形式は次のとおりです。
o The Hash Algorithm field is represented as an unsigned decimal integer. The value has a maximum of 255.
o ハッシュアルゴリズムフィールドは、署名されていない小数整数として表されます。値には最大255です。
o The Flags field is represented as an unsigned decimal integer. The value has a maximum value of 255.
o フラグフィールドは、署名されていない小数整数として表されます。値の最大値は255です。
o The Iterations field is represented as an unsigned decimal integer. The value is between 0 and 65535, inclusive.
o イテレーションフィールドは、署名されていない小数整数として表されます。値は0〜65535、包括的です。
o The Salt Length field is not represented.
o 塩の長さのフィールドは表されません。
o The Salt field is represented as a sequence of case-insensitive hexadecimal digits. Whitespace is not allowed within the sequence. This field is represented as "-" (without the quotes) when the Salt Length field is zero.
o 塩フィールドは、症例感受性の六方桁のシーケンスとして表されます。シーケンス内では、Whitespaceは許可されていません。このフィールドは、塩の長さのフィールドがゼロの場合、「 - 」（引用符なし）として表されます。
The hash calculation uses three of the NSEC3 RDATA fields: Hash Algorithm, Salt, and Iterations.
ハッシュ計算では、3つのNSEC3 RDATAフィールドの使用を使用します：ハッシュアルゴリズム、塩、および反復。
Define H(x) to be the hash of x using the Hash Algorithm selected by the NSEC3 RR, k to be the number of Iterations, and || to indicate concatenation. Then define:
NSEC3 RRによって選択されたハッシュアルゴリズムを使用して、xのハッシュであるとH（x）を定義し、kは反復数になり、||連結を示すため。次に定義します：
IH(salt, x, 0) = H(x || salt), and
IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0
Then the calculated hash of an owner name is
次に、所有者名の計算されたハッシュはです
IH(salt, owner name, iterations),
IH（塩、所有者名、反復）、
where the owner name is in the canonical form, defined as:
所有者名が標準形式である場合、次のように定義されています。
The wire format of the owner name where:
所有者名のワイヤー形式場所：
1. The owner name is fully expanded (no DNS name compression) and fully qualified;
1. 所有者名は完全に拡張されています（DNS名の圧縮なし）、完全に資格があります。
2. All uppercase US-ASCII letters are replaced by the corresponding lowercase US-ASCII letters;
2. すべての大文字のUS-ASCII文字は、対応する小文字のUS-ASCII文字に置き換えられます。
3. If the owner name is a wildcard name, the owner name is in its original unexpanded form, including the "*" label (no wildcard substitution);
3. 所有者名がワイルドカード名の場合、所有者名は「*」ラベル（ワイルドカード代替なし）を含む元の未装備のフォームにあります。
This form is as defined in Section 6.2 of [RFC4034].
この形式は、[RFC4034]のセクション6.2で定義されています。
The method to calculate the Hash is based on [RFC2898].
ハッシュを計算する方法は[RFC2898]に基づいています。
In this specification, as in [RFC4033], [RFC4034] and [RFC4035], NS RRSets at delegation points are not signed and may be accompanied by a DS RRSet. With the Opt-Out bit clear, the security status of the child zone is determined by the presence or absence of this DS RRSet, cryptographically proven by the signed NSEC3 RR at the hashed owner name of the delegation. Setting the Opt-Out flag modifies this by allowing insecure delegations to exist within the signed zone without a corresponding NSEC3 RR at the hashed owner name of the delegation.
この仕様では、[RFC4033]、[RFC4034]、[RFC4035]のように、委任ポイントでのNS RRSetsは署名されておらず、DS RRSETを伴う場合があります。オプトアウトが少し明確になると、チャイルドゾーンのセキュリティステータスは、このDS RRSetの有無によって決定されます。オプトアウトフラグを設定すると、代表団のハッシュされた所有者名で対応するNSEC3 RRなしで、署名ゾーン内に安全でない代表団が存在できるようにすることにより、これを修正します。
An Opt-Out NSEC3 RR is said to cover a delegation if the hash of the owner name or "next closer" name of the delegation is between the owner name of the NSEC3 RR and the next hashed owner name.
オプトアウトNSEC3 RRは、所有者名のハッシュまたは代表団の「次の近い」名前がNSEC3 RRの所有者名と次のハッシュオーナー名の間にある場合、代表団をカバーすると言われています。
An Opt-Out NSEC3 RR does not assert the existence or non-existence of the insecure delegations that it may cover. This allows for the addition or removal of these delegations without recalculating or re-signing RRs in the NSEC3 RR chain. However, Opt-Out NSEC3 RRs do assert the (non)existence of other, authoritative RRSets.
オプトアウトNSEC3 RRは、それがカバーする可能性のある不安定な代表団の存在または存在を主張しません。これにより、NSEC3 RRチェーンでRRを再計算または再署名することなく、これらの代表団の追加または除去が可能になります。ただし、オプトアウトNSEC3 RRSは、他の権威あるRRSetの（非）存在を主張します。
An Opt-Out NSEC3 RR MAY have the same original owner name as an insecure delegation. In this case, the delegation is proven insecure by the lack of a DS bit in the type map and the signed NSEC3 RR does assert the existence of the delegation.
オプトアウトNSEC3 RRは、不安定な代表団と同じ元の所有者名を持つ場合があります。この場合、委任はタイプマップにDSビットがないことで不安定であることが証明されており、署名されたNSEC3 RRは代表団の存在を主張します。
Zones using Opt-Out MAY contain a mixture of Opt-Out NSEC3 RRs and non-Opt-Out NSEC3 RRs. If an NSEC3 RR is not Opt-Out, there MUST NOT be any hashed owner names of insecure delegations (nor any other RRs) between it and the name indicated by the next hashed owner name in the NSEC3 RDATA. If it is Opt-Out, it MUST only cover hashed owner names or hashed "next closer" names of insecure delegations.
オプトアウトを使用したゾーンには、オプトアウトNSEC3 RRSと非OPTアウトNSEC3 RRの混合物が含まれている場合があります。NSEC3 RRがオプトアウトでない場合、NSEC3 RDATAの次のハッシュオーナー名で示されている名前と名前の間に、不安定な代表団（または他のRR）のハッシュオーナー名がないはずです。オプトアウトの場合、ハッシュされた所有者の名前のみをカバーするか、不安定な代表団の「次の近い」名前をハッシュするだけです。
The effects of the Opt-Out flag on signing, serving, and validating responses are covered in following sections.
署名、提供、および検証の応答に対するオプトアウトフラグの効果は、次のセクションで説明されています。
Zones using NSEC3 must satisfy the following properties:
NSEC3を使用したゾーンは、次のプロパティを満たす必要があります。
o Each owner name within the zone that owns authoritative RRSets MUST have a corresponding NSEC3 RR. Owner names that correspond to unsigned delegations MAY have a corresponding NSEC3 RR. However, if there is not a corresponding NSEC3 RR, there MUST be an Opt-Out NSEC3 RR that covers the "next closer" name to the delegation. Other non-authoritative RRs are not represented by NSEC3 RRs.
o 権威あるRRSetsを所有するゾーン内の各所有者名には、対応するNSEC3 RRが必要です。署名されていない代表団に対応する所有者名は、対応するNSEC3 RRを持っている場合があります。ただし、対応するNSEC3 RRがない場合は、代表団の「次の近い」名前をカバーするオプトアウトNSEC3 RRが必要です。他の非認証RRは、NSEC3 RRSで表されません。
o Each empty non-terminal MUST have a corresponding NSEC3 RR, unless the empty non-terminal is only derived from an insecure delegation covered by an Opt-Out NSEC3 RR.
o 空の非ターミナルがオプトアウトNSEC3 RRで覆われている不安定な代表団からのみ導出されない限り、各空の非末端は対応するNSEC3 RRを持つ必要があります。
o The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL value field in the zone SOA RR.
o NSEC3 RRのTTL値は、ゾーンSOA RRの最小TTL値フィールドと同じである必要があります。
o The Type Bit Maps field of every NSEC3 RR in a signed zone MUST indicate the presence of all types present at the original owner name, except for the types solely contributed by an NSEC3 RR itself. Note that this means that the NSEC3 type itself will never be present in the Type Bit Maps.
o 署名されたゾーン内のすべてのNSEC3 RRのタイプビットマップフィールドは、NSEC3 RR自体によってのみ寄与されるタイプを除き、元の所有者名に存在するすべてのタイプの存在を示す必要があります。これは、NSEC3タイプ自体がタイプビットマップに決して存在しないことを意味することに注意してください。
The following steps describe a method of proper construction of NSEC3 RRs. This is not the only such possible method.
次の手順は、NSEC3 RRSの適切な構築方法を説明しています。これがそのような可能な方法だけではありません。
1. Select the hash algorithm and the values for salt and iterations.
1. ハッシュアルゴリズムと塩と反復の値を選択します。
2. For each unique original owner name in the zone add an NSEC3 RR.
2. ゾーン内のユニークなオリジナルの所有者名ごとに、NSEC3 RRを追加します。
* If Opt-Out is being used, owner names of unsigned delegations MAY be excluded.
* オプトアウトが使用されている場合、署名されていない代表団の所有者名は除外される場合があります。
* The owner name of the NSEC3 RR is the hash of the original owner name, prepended as a single label to the zone name.
* NSEC3 RRの所有者名は、元の所有者名のハッシュであり、ゾーン名の単一のラベルとして準備されています。
* The Next Hashed Owner Name field is left blank for the moment.
* 次のハッシュされた所有者名フィールドは、今のところ空白のままです。
* If Opt-Out is being used, set the Opt-Out bit to one.
* オプトアウトが使用されている場合は、オプトアウトビットを1に設定します。
* For collision detection purposes, optionally keep track of the original owner name with the NSEC3 RR.
* 衝突検出のために、オプションでNSEC3 RRを使用して元の所有者名を追跡します。
* Additionally, for collision detection purposes, optionally create an additional NSEC3 RR corresponding to the original owner name with the asterisk label prepended (i.e., as if a wildcard existed as a child of this owner name) and keep track of this original owner name. Mark this NSEC3 RR as temporary.
* さらに、衝突検出のために、オプションでは、アスタリスクラベルの前に元の所有者名に対応する追加のNSEC3 RRを作成します（つまり、この所有者名の子としてワイルドカードが存在するかのように）、この元の所有者名を追跡します。このNSEC3 RRを一時的なものとしてマークします。
3. For each RRSet at the original owner name, set the corresponding bit in the Type Bit Maps field.
3. 元の所有者名の各rrsetについて、タイプビットマップフィールドに対応するビットを設定します。
4. If the difference in number of labels between the apex and the original owner name is greater than 1, additional NSEC3 RRs need to be added for every empty non-terminal between the apex and the original owner name. This process may generate NSEC3 RRs with duplicate hashed owner names. Optionally, for collision detection, track the original owner names of these NSEC3 RRs and create temporary NSEC3 RRs for wildcard collisions in a similar fashion to step 1.
4. 頂点と元の所有者名の間のラベルの数の差が1を超える場合、Apexと元の所有者名の間のすべての空の非ターミナルに対して追加のNSEC3 RRを追加する必要があります。このプロセスは、重複したハッシュオーナー名でNSEC3 RRSを生成する場合があります。オプションでは、衝突検出のために、これらのNSEC3 RRの元の所有者名を追跡し、ステップ1と同様の方法でワイルドカード衝突用の一時的なNSEC3 RRを作成します。
5. Sort the set of NSEC3 RRs into hash order.
5. NSEC3 RRSのセットをハッシュオーダーに並べ替えます。
6. Combine NSEC3 RRs with identical hashed owner names by replacing them with a single NSEC3 RR with the Type Bit Maps field consisting of the union of the types represented by the set of NSEC3 RRs. If the original owner name was tracked, then collisions may be detected when combining, as all of the matching NSEC3 RRs should have the same original owner name. Discard any possible temporary NSEC3 RRs.
6. NSEC3 RRSを同一のハッシュオーナー名と組み合わせて、NSEC3 RRSのセットで表されるタイプの結合で構成されるタイプビットマップフィールドに単一のNSEC3 RRに置き換えます。元の所有者名が追跡された場合、結合するときに衝突が検出される可能性があります。すべての一致するNSEC3 RRSには、同じ元の所有者名が必要なためです。可能な一時的なNSEC3 RRSを破棄します。
7. In each NSEC3 RR, insert the next hashed owner name by using the value of the next NSEC3 RR in hash order. The next hashed owner name of the last NSEC3 RR in the zone contains the value of the hashed owner name of the first NSEC3 RR in the hash order.
7. 各NSEC3 RRで、次のNSEC3 RRの値をハッシュ順に使用して、次のハッシュオーナー名を挿入します。ゾーン内の最後のNSEC3 RRの次のハッシュオーナー名には、ハッシュ順に最初のNSEC3 RRのハッシュされた所有者名の値が含まれています。
8. Finally, add an NSEC3PARAM RR with the same Hash Algorithm, Iterations, and Salt fields to the zone apex.
8. 最後に、同じハッシュアルゴリズム、反復、塩フィールドをゾーンアペックスにnsec3param RRを追加します。
If a hash collision is detected, then a new salt has to be chosen, and the signing process restarted.
ハッシュ衝突が検出された場合、新しい塩を選択する必要があり、署名プロセスが再起動しました。
This specification modifies DNSSEC-enabled DNS responses generated by authoritative servers. In particular, it replaces the use of NSEC RRs in such responses with NSEC3 RRs.
この仕様は、権威あるサーバーによって生成されたDNSSEC対応DNS応答を変更します。特に、このような応答でのNSEC RRの使用をNSEC3 RRSに置き換えます。
In the following response cases, the NSEC RRs dictated by DNSSEC [RFC4035] are replaced with NSEC3 RRs that prove the same facts. Responses that would not contain NSEC RRs are unchanged by this specification.
以下の応答の場合、DNSSEC [RFC4035]によって決定されたNSEC RRSは、同じ事実を証明するNSEC3 RRSに置き換えられます。NSEC RRを含まない応答は、この仕様では変更されません。
When returning responses containing multiple NSEC3 RRs, all of the NSEC3 RRs MUST use the same hash algorithm, iteration, and salt values. The Flags field value MUST be either zero or one.
複数のNSEC3 RRSを含む応答を返す場合、すべてのNSEC3 RRSは同じハッシュアルゴリズム、反復、および塩値を使用する必要があります。フラグのフィールド値はゼロまたは1つでなければなりません。
For many NSEC3 responses a proof of the closest encloser is required. This is a proof that some ancestor of the QNAME is the closest encloser of QNAME.
多くのNSEC3応答には、最も近いエンクロージャーの証明が必要です。これは、QNameの祖先がQNameの最も近い囲いであることの証拠です。
This proof consists of (up to) two different NSEC3 RRs:
この証明は、2つの異なるNSEC3 RRSで構成されています。
o An NSEC3 RR that matches the closest (provable) encloser.
o 最も近い（推測可能な）エンクロージャーに一致するNSEC3 RR。
o An NSEC3 RR that covers the "next closer" name to the closest encloser.
o 最も近いエンクロージャーに「次に近い」名前をカバーするNSEC3 RR。
The first NSEC3 RR essentially proposes a possible closest encloser, and proves that the particular encloser does, in fact, exist. The second NSEC3 RR proves that the possible closest encloser is the closest, and proves that the QNAME (and any ancestors between QNAME and the closest encloser) does not exist.
最初のNSEC3 RRは、本質的に最も近いエンクローザーを提案し、特定の封鎖者が実際に存在することを証明しています。2番目のNSEC3 RRは、可能性のある最も近いエンクローザーが最も近いことを証明し、QName（およびQNameと最も近いエンクローザーの間の祖先）が存在しないことを証明しています。
These NSEC3 RRs are collectively referred to as the "closest encloser proof" in the subsequent descriptions.
これらのNSEC3 RRSは、後続の説明で「最も近い封鎖者の証明」と総称されます。
For example, the closest encloser proof for the nonexistent "alpha.beta.gamma.example." owner name might prove that "gamma.example." is the closest encloser. This response would contain the NSEC3 RR that matches "gamma.example.", and would also contain the NSEC3 RR that covers "beta.gamma.example." (which is the "next closer" name).
たとえば、存在しない「alpha.beta.gamma.example」の最も近い囲いの証明。所有者の名前は、「gamma.example」であることを証明するかもしれません。最も近い封筒です。この応答には、「gamma.example」と一致するNSEC3 RRが含まれ、「beta.gamma.example」をカバーするNSEC3 RRも含まれます。（これは「次の近い」名前です）。
It is possible, when using Opt-Out (Section 6), to not be able to prove the actual closest encloser because it is, or is part of an insecure delegation covered by an Opt-Out span. In this case, instead of proving the actual closest encloser, the closest provable encloser is used. That is, the closest enclosing authoritative name is used instead. In this case, the set of NSEC3 RRs used for this proof is referred to as the "closest provable encloser proof".
オプトアウト（セクション6）を使用する場合、オプトアウトスパンでカバーされている不安定な代表団の一部であるため、実際に最も近いエンコーザーを証明できないことが可能です。この場合、実際に最も近い囲いを証明する代わりに、最も近い証明可能なエンクローザーが使用されます。つまり、代わりに最も近い囲まれた権威ある名前が使用されます。この場合、この証明に使用されるNSEC3 RRSのセットは、「最も近い証明可能なエンクロージャー証明」と呼ばれます。
To prove the nonexistence of QNAME, a closest encloser proof and an NSEC3 RR covering the (nonexistent) wildcard RR at the closest encloser MUST be included in the response. This collection of (up to) three NSEC3 RRs proves both that QNAME does not exist and that a wildcard that could have matched QNAME also does not exist.
QNameの存在を証明するには、最も近い囲いの証明と、最も近い囲いの（存在しない）ワイルドカードRRをカバーするNSEC3 RRを応答に含める必要があります。この（最大）3つのNSEC3 RRSのこのコレクションは、QNameが存在しないことと、QNameと一致していた可能性のあるワイルドカードも存在しないことを証明しています。
For example, if "gamma.example." is the closest provable encloser to QNAME, then an NSEC3 RR covering "*.gamma.example." is included in the authority section of the response.
たとえば、「gamma.example」の場合。QNameに最も近い証明可能なエンクローザーであり、次に「*.gamma.example。」をカバーするNSEC3 RRです。応答の当局セクションに含まれています。
The server MUST include the NSEC3 RR that matches QNAME. This NSEC3 RR MUST NOT have the bits corresponding to either the QTYPE or CNAME set in its Type Bit Maps field.
サーバーには、QNameに一致するNSEC3 RRを含める必要があります。このNSEC3 RRには、タイプビットマップフィールドに設定されたQTYPEまたはCNAMEセットのいずれかに対応するビットが必要です。
If there is an NSEC3 RR that matches QNAME, the server MUST return it in the response. The bits corresponding with DS and CNAME MUST NOT be set in the Type Bit Maps field of this NSEC3 RR.
QNameに一致するNSEC3 RRがある場合、サーバーは応答でそれを返す必要があります。DSおよびCNAMEに対応するビットは、このNSEC3 RRのタイプビットマップフィールドに設定してはなりません。
If no NSEC3 RR matches QNAME, the server MUST return a closest provable encloser proof for QNAME. The NSEC3 RR that covers the "next closer" name MUST have the Opt-Out bit set (note that this is true by definition -- if the Opt-Out bit is not set, something has gone wrong).
NSEC3 RRがQNAMEと一致しない場合、サーバーはQNAMEの最も近い証明可能なエンクローザープルーフを返す必要があります。「次の近い」名前をカバーするNSEC3 RRには、オプトアウトビットが設定されている必要があります（定義上、オプトアウトビットが設定されていない場合、何かが間違っていることに注意してください）。
If a server is authoritative for both sides of a zone cut at QNAME, the server MUST return the proof from the parent side of the zone cut.
サーバーがQNAMEのゾーンカットの両側に対して権威ある場合、サーバーはゾーンカットの親側から証明を返す必要があります。
If there is a wildcard match for QNAME, but QTYPE is not present at that name, the response MUST include a closest encloser proof for QNAME and MUST include the NSEC3 RR that matches the wildcard. This combination proves both that QNAME itself does not exist and that a wildcard that matches QNAME does exist. Note that the closest encloser to QNAME MUST be the immediate ancestor of the wildcard RR (if this is not the case, then something has gone wrong).
QNAMEにワイルドカードマッチがあるが、QTYPEがその名前に存在しない場合、応答にはQNAMEの最も近いエンクローザープルーフを含める必要があり、ワイルドカードに一致するNSEC3 RRを含める必要があります。この組み合わせは、QName自体が存在しないことと、QNameに一致するワイルドカードが存在することを証明しています。QNameに最も近い封鎖者は、WildCard RRの直接の祖先でなければならないことに注意してください（そうでない場合は、何かが間違っています）。
If there is a wildcard match for QNAME and QTYPE, then, in addition to the expanded wildcard RRSet returned in the answer section of the response, proof that the wildcard match was valid must be returned.
QNameとQTypeにワイルドカードマッチがある場合、応答の回答セクションで拡張されたワイルドカードRRSetに加えて、ワイルドカードの一致が有効であることの証明を返す必要があります。
This proof is accomplished by proving that both QNAME does not exist and that the closest encloser of the QNAME and the immediate ancestor of the wildcard are the same (i.e., the correct wildcard matched).
この証明は、両方のQNAMEが存在しないこと、およびQNameの最も近い囲い人とワイルドカードの直接の祖先が同じであることを証明することによって達成されます（つまり、正しいワイルドカードが一致しています）。
To this end, the NSEC3 RR that covers the "next closer" name of the immediate ancestor of the wildcard MUST be returned. It is not necessary to return an NSEC3 RR that matches the closest encloser, as the existence of this closest encloser is proven by the presence of the expanded wildcard in the response.
この目的のために、ワイルドカードの直接の祖先の「次の近い」名前をカバーするNSEC3 RRを返す必要があります。この最も近い封鎖者の存在は、応答に拡張されたワイルドカードの存在によって証明されているため、最も近い封鎖者に一致するNSEC3 RRを返す必要はありません。
If there is an NSEC3 RR that matches the delegation name, then that NSEC3 RR MUST be included in the response. The DS bit in the type bit maps of the NSEC3 RR MUST NOT be set.
委任名と一致するNSEC3 RRがある場合、そのNSEC3 RRを応答に含める必要があります。NSEC3 RRのタイプビットマップのDSビットを設定してはなりません。
If the zone is Opt-Out, then there may not be an NSEC3 RR corresponding to the delegation. In this case, the closest provable encloser proof MUST be included in the response. The included NSEC3 RR that covers the "next closer" name for the delegation MUST have the Opt-Out flag set to one. (Note that this will be the case unless something has gone wrong).
ゾーンがオプトアウトの場合、委任に対応するNSEC3 RRがない場合があります。この場合、最も近い証明可能な囲いの証明を応答に含める必要があります。代表団の「次の近い」名前をカバーする付属のNSEC3 RRは、オプトアウトフラグを1に設定する必要があります。（何かが間違っていない限り、これは事実になることに注意してください）。
The owner names of NSEC3 RRs are not represented in the NSEC3 RR chain like other owner names. As a result, each NSEC3 owner name is covered by another NSEC3 RR, effectively negating the existence of the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR can be proven by its RRSIG RRSet.
NSEC3 RRの所有者名は、他の所有者名のようにNSEC3 RRチェーンでは表されません。その結果、各NSEC3の所有者名は別のNSEC3 RRによってカバーされ、NSEC3 RRの存在を効果的に無効にします。NSEC3 RRの存在はRRSIG RRSetによって証明できるため、これはパラドックスです。
If the following conditions are all true:
次の条件がすべて真実の場合：
o the QNAME equals the owner name of an existing NSEC3 RR, and
o QNameは、既存のNSEC3 RRの所有者名に等しくなり、
o no RR types exist at the QNAME, nor at any descendant of QNAME,
o QNameやQNameの子孫にもRRタイプはありません。
then the response MUST be constructed as a Name Error response (Section 7.2.2). Or, in other words, the authoritative name server will act as if the owner name of the NSEC3 RR did not exist.
次に、応答を名前エラー応答として構築する必要があります（セクション7.2.2）。または、言い換えれば、権威ある名前サーバーは、NSEC3 RRの所有者名が存在しなかったかのように動作します。
Note that NSEC3 RRs are returned as a result of an AXFR or IXFR query.
NSEC3 RRSは、AXFRまたはIXFRクエリの結果として返されることに注意してください。
If the hash of a non-existing QNAME collides with the owner name of an existing NSEC3 RR, then the server will be unable to return a response that proves that QNAME does not exist. In this case, the server MUST return a response with an RCODE of 2 (server failure).
存在しないQNameのハッシュが既存のNSEC3 RRの所有者名と衝突する場合、サーバーはQNameが存在しないことを証明する応答を返すことができません。この場合、サーバーは2のRcode（サーバー障害）で応答を返す必要があります。
Note that with the hash algorithm specified in this document, SHA-1, such collisions are highly unlikely.
このドキュメントで指定されたハッシュアルゴリズムでは、SHA-1では、このような衝突は非常にありそうもないことに注意してください。
Secondary servers (and perhaps other entities) need to reliably determine which NSEC3 parameters (i.e., hash, salt, and iterations) are present at every hashed owner name, in order to be able to choose an appropriate set of NSEC3 RRs for negative responses. This is indicated by an NSEC3PARAM RR present at the zone apex.
セカンダリサーバー（およびおそらく他のエンティティ）は、負の応答のために適切なNSEC3 RRSのセットを選択できるように、すべてのハッシュされた所有者名にどのNSEC3パラメーター（つまり、ハッシュ、塩、および反復）が存在するかを確実に決定する必要があります。これは、ゾーンアペックスに存在するNSEC3PARAM RRによって示されます。
If there are multiple NSEC3PARAM RRs present, there are multiple valid NSEC3 chains present. The server must choose one of them, but may use any criteria to do so.
複数のNSEC3PARAM RRSが存在する場合、複数の有効なNSEC3チェーンが存在します。サーバーはそれらのいずれかを選択する必要がありますが、任意の基準を使用してそうすることができます。
Zones that are signed according to this specification, but are using an unrecognized NSEC3 hash algorithm value, cannot be effectively served. Such zones SHOULD be rejected when loading. Servers SHOULD respond with RCODE=2 (server failure) responses when handling queries that would fall under such zones.
この仕様に従って署名されているが、認識されていないNSEC3ハッシュアルゴリズム値を使用しているゾーンは、効果的に提供できません。このようなゾーンは、ロード時に拒否される必要があります。サーバーは、そのようなゾーンに該当するクエリを処理する際に、rcode = 2（サーバー障害）応答で応答する必要があります。
A zone signed using NSEC3 may accept dynamic updates [RFC2136]. However, NSEC3 introduces some special considerations for dynamic updates.
NSEC3を使用して署名されたゾーンは、動的更新[RFC2136]を受け入れる場合があります。ただし、NSEC3は動的更新に関する特別な考慮事項をいくつか紹介しています。
Adding and removing names in a zone MUST account for the creation or removal of empty non-terminals.
ゾーンに名前を追加および削除する必要があるのは、空の非ターミナルの作成または削除を説明する必要があります。
o When removing a name with a corresponding NSEC3 RR, any NSEC3 RRs corresponding to empty non-terminals created by that name MUST be removed. Note that more than one name may be asserting the existence of a particular empty non-terminal.
o 対応するNSEC3 RRで名前を削除する場合、その名前で作成された空の非ターミナルに対応するNSEC3 RRSは削除する必要があります。複数の名前が特定の空の非ターミナルの存在を主張している可能性があることに注意してください。
o When adding a name that requires adding an NSEC3 RR, NSEC3 RRs MUST also be added for any empty non-terminals that are created. That is, if there is not an existing NSEC3 RR matching an empty non-terminal, it must be created and added.
o NSEC3 RRを追加する必要がある名前を追加する場合、NSEC3 RRSも作成された空の非ターミナルに追加する必要があります。つまり、空の非ターミナルに一致する既存のNSEC3 RRがない場合は、作成して追加する必要があります。
The presence of Opt-Out in a zone means that some additions or delegations of names will not require changes to the NSEC3 RRs in a zone.
ゾーンにオプトアウトが存在することは、名前のいくつかの追加または代表団がゾーン内のNSEC3 RRの変更を必要としないことを意味します。
o When removing a delegation RRSet, if that delegation does not have a matching NSEC3 RR, then it was opted out. In this case, nothing further needs to be done.
o 代表団RRSetを削除するとき、その代表団に一致するNSEC3 RRがない場合、それはオプトアウトされました。この場合、それ以上は何もする必要はありません。
o When adding a delegation RRSet, if the "next closer" name of the delegation is covered by an existing Opt-Out NSEC3 RR, then the delegation MAY be added without modifying the NSEC3 RRs in the zone.
o 代表団RRSTを追加すると、委任の「次の近い」名前が既存のオプトアウトNSEC3 RRによってカバーされている場合、ゾーン内のNSEC3 RRSを変更せずに代表団を追加できます。
The presence of Opt-Out in a zone means that when adding or removing NSEC3 RRs, the value of the Opt-Out flag that should be set in new or modified NSEC3 RRs is ambiguous. Servers SHOULD follow this set of basic rules to resolve the ambiguity.
ゾーンにオプトアウトが存在することは、NSEC3 RRSを追加または削除する場合、新規または変更されたNSEC3 RRSに設定するオプトアウトフラグの値が曖昧であることを意味します。サーバーは、この一連の基本的なルールに従って、あいまいさを解決する必要があります。
The central concept to these rules is that the state of the Opt-Out flag of the covering NSEC3 RR is preserved.
これらのルールの中心的な概念は、カバーNSEC3 RRのオプトアウトフラグの状態が保存されていることです。
o When removing an NSEC3 RR, the value of the Opt-Out flag for the previous NSEC3 RR (the one whose next hashed owner name is modified) should not be changed.
o NSEC3 RRを削除する場合、以前のNSEC3 RR（次のハッシュオーナー名が変更されたもの）のオプトアウトフラグの値を変更しないでください。
o When adding an NSEC3 RR, the value of the Opt-Out flag is set to the value of the Opt-Out flag of the NSEC3 RR that previously covered the owner name of the NSEC3 RR. That is, the now previous NSEC3 RR.
o NSEC3 RRを追加すると、オプトアウトフラグの値は、以前にNSEC3 RRの所有者名をカバーしていたNSEC3 RRのオプトアウトフラグの値に設定されます。つまり、現在のNSEC3 RRです。
If the zone in question is consistent with its use of the Opt-Out flag (that is, all NSEC3 RRs in the zone have the same value for the flag) then these rules will retain that consistency. If the zone is not consistent in the use of the flag (i.e., a partially Opt-Out zone), then these rules will not retain the same pattern of use of the Opt-Out flag.
問題のゾーンがオプトアウトフラグ（つまり、ゾーン内のすべてのNSEC3 RRがフラグと同じ値を持っている）の使用と一致している場合、これらのルールはその一貫性を保持します。ゾーンがフラグの使用（部分的にオプトアウトゾーン）の使用に一貫していない場合、これらのルールはオプトアウトフラグの同じパターンを保持しません。
For zones that partially use the Opt-Out flag, if there is a logical pattern for that use, the pattern could be maintained by using a local policy on the server.
オプトアウトフラグを部分的に使用するゾーンの場合、その使用に論理的なパターンがある場合、サーバー上のローカルポリシーを使用してパターンを維持できます。
A validator MUST ignore NSEC3 RRs with unknown hash types. The practical result of this is that responses containing only such NSEC3 RRs will generally be considered bogus.
バリデーターは、未知のハッシュタイプを持つNSEC3 RRを無視する必要があります。これの実際的な結果は、そのようなNSEC3 RRのみを含む応答が一般に偽物と見なされることです。
A validator MUST ignore NSEC3 RRs with a Flag fields value other than zero or one.
バリデーターは、ゼロまたは1以外のフラグフィールド値を持つNSEC3 RRSを無視する必要があります。
A validator MAY treat a response as bogus if the response contains NSEC3 RRs that contain different values for hash algorithm, iterations, or salt from each other for that zone.
そのゾーンのハッシュアルゴリズム、反復、または塩の異なる値を含むNSEC3 RRSを含む応答がNSEC3 RRSを含む場合、バリデーターは、応答を偽物として扱うことができます。
In order to verify a closest encloser proof, the validator MUST find the longest name, X, such that
最も近い囲いの証明を確認するために、バリデーターは最長の名前xを見つけなければなりません。
o X is an ancestor of QNAME that is matched by an NSEC3 RR present in the response. This is a candidate for the closest encloser, and
o Xは、応答に存在するNSEC3 RRと一致するQNameの祖先です。これは最も近い封筒の候補者であり、
o The name one label longer than X (but still an ancestor of -- or equal to -- QNAME) is covered by an NSEC3 RR present in the response.
o Xより長い名前の1つのラベル（ただし、それでも-QNAMEの祖先であるか、QNAMEに等しい）は、応答に存在するNSEC3 RRでカバーされています。
One possible algorithm for verifying this proof is as follows:
この証明を検証するための可能なアルゴリズムの1つは、次のとおりです。
1. Set SNAME=QNAME. Clear the flag.
1. sname = qnameを設定します。旗をきれいにします。
2. Check whether SNAME exists:
2. スナムが存在するかどうかを確認してください：
* If there is no NSEC3 RR in the response that matches SNAME (i.e., an NSEC3 RR whose owner name is the same as the hash of SNAME, prepended as a single label to the zone name), clear the flag.
* Snameに一致する応答にNSEC3 RRがない場合（つまり、所有者名がSnameのハッシュと同じ、ゾーン名に単一のラベルとして準備されたSnameのハッシュと同じNSEC3 RR）、フラグをクリアします。
* If there is an NSEC3 RR in the response that covers SNAME, set the flag.
* Snameをカバーする応答にNSEC3 RRがある場合は、フラグを設定します。
* If there is a matching NSEC3 RR in the response and the flag was set, then the proof is complete, and SNAME is the closest encloser.
* 応答に一致するNSEC3 RRがあり、フラグが設定されている場合、証明は完了し、Snameは最も近い封筒です。
* If there is a matching NSEC3 RR in the response, but the flag is not set, then the response is bogus.
* 応答に一致するNSEC3 RRがあるが、フラグが設定されていない場合、応答は偽物です。
3. Truncate SNAME by one label from the left, go to step 2.
3. 左から1つのラベルでスナムを切り捨て、ステップ2に進みます。
Once the closest encloser has been discovered, the validator MUST check that the NSEC3 RR that has the closest encloser as the original owner name is from the proper zone. The DNAME type bit must not be set and the NS type bit may only be set if the SOA type bit is set. If this is not the case, it would be an indication that an attacker is using them to falsely deny the existence of RRs for which the server is not authoritative.
最も近いエンクローザーが発見されたら、バリデーターは、元の所有者名が適切なゾーンからのものであるため、最も近い囲いecloserを持つNSEC3 RRを確認する必要があります。DNAMEタイプビットを設定する必要はなく、SOAタイプビットが設定されている場合にのみ、NSタイプビットを設定できます。そうでない場合、攻撃者がそれらを使用して、サーバーが信頼できるものではないRRの存在を誤って否定していることを示しています。
In the following descriptions, the phrase "a closest (provable) encloser proof for X" means that the algorithm above (or an equivalent algorithm) proves that X does not exist by proving that an ancestor of X is its closest encloser.
以下の説明では、「Xの最も近い（予測可能な）封鎖的証明」というフレーズは、上記のアルゴリズム（または同等のアルゴリズム）が、Xの祖先が最も近いエンクローザーであることを証明することによってXが存在しないことを証明することを意味します。
A validator MUST verify that there is a closest encloser proof for QNAME present in the response and that there is an NSEC3 RR that covers the wildcard at the closest encloser (i.e., the name formed by prepending the asterisk label to the closest encloser).
バリデーターは、応答に存在するQNAMEに最も近いエンクローザー証明があり、最も近いエンクローザーのワイルドカードをカバーするNSEC3 RRがあることを確認する必要があります（つまり、アスタリスクラベルを最も近いエンクロージャーに準備することによって形成された名前）。
The validator MUST verify that an NSEC3 RR that matches QNAME is present and that both the QTYPE and the CNAME type are not set in its Type Bit Maps field.
バリデーターは、QNameに一致するNSEC3 RRが存在し、QTYPEとCNAMEタイプの両方がそのタイプビットマップフィールドに設定されていないことを確認する必要があります。
Note that this test also covers the case where the NSEC3 RR exists because it corresponds to an empty non-terminal, in which case the NSEC3 RR will have an empty Type Bit Maps field.
このテストは、NSEC3 RRが空の非ターミナルに対応するため、NSEC3 RRが存在する場合もカバーしていることに注意してください。この場合、NSEC3 RRには空のタイプビットマップフィールドがあります。
If there is an NSEC3 RR that matches QNAME present in the response, then that NSEC3 RR MUST NOT have the bits corresponding to DS and CNAME set in its Type Bit Maps field.
応答に存在するQNAMEに一致するNSEC3 RRがある場合、NSEC3 RRがその型ビットマップフィールドにDSとCNAMEセットに対応するビットを持っている必要がありません。
If there is no such NSEC3 RR, then the validator MUST verify that a closest provable encloser proof for QNAME is present in the response, and that the NSEC3 RR that covers the "next closer" name has the Opt-Out bit set.
そのようなNSEC3 RRがない場合、VALIBARTARは、QNAMEの最も近い証明可能なエンクローザー証明が応答に存在し、「次の近い」名前をカバーするNSEC3 RRがオプトアウトビットセットを持っていることを確認する必要があります。
The validator MUST verify a closest encloser proof for QNAME and MUST find an NSEC3 RR present in the response that matches the wildcard name generated by prepending the asterisk label to the closest encloser. Furthermore, the bits corresponding to both QTYPE and CNAME MUST NOT be set in the wildcard matching NSEC3 RR.
バリーターは、QNAMEの最も近いエンクローザープルーフを検証する必要があり、アスタリスクラベルを最も近い囲いにプレイすることで生成されたワイルドカード名と一致するNSEC3 RRを見つけなければなりません。さらに、QTYPEとCNAMEの両方に対応するビットを、NSEC3 RRを一致させるワイルドカードに設定してはなりません。
The verified wildcard answer RRSet in the response provides the validator with a (candidate) closest encloser for QNAME. This closest encloser is the immediate ancestor to the generating wildcard.
応答の検証済みのWildCard Answer RRSetは、QNAMEに最も近いエンクローザー（候補）の（候補）の（候補）QNAMEのエンクローザーを提供します。この最も近い囲いは、生成されるワイルドカードの即席の祖先です。
Validators MUST verify that there is an NSEC3 RR that covers the "next closer" name to QNAME present in the response. This proves that QNAME itself did not exist and that the correct wildcard was used to generate the response.
バリデーターは、応答に存在するQNameに「次の近い」名前をカバーするNSEC3 RRがあることを確認する必要があります。これは、QNAME自体が存在せず、正しいワイルドカードが応答を生成するために使用されたことを証明しています。
The delegation name in a referral is the owner name of the NS RRSet present in the authority section of the referral response.
紹介の委任名は、紹介対応の権限セクションに存在するNS RRSetの所有者名です。
If there is an NSEC3 RR present in the response that matches the delegation name, then the validator MUST ensure that the NS bit is set and that the DS bit is not set in the Type Bit Maps field of the NSEC3 RR. The validator MUST also ensure that the NSEC3 RR is from the correct (i.e., parent) zone. This is done by ensuring that the SOA bit is not set in the Type Bit Maps field of this NSEC3 RR.
委任名と一致する応答にNSEC3 RRが存在する場合、VALIBATORはNSビットが設定され、DSビットがNSEC3 RRのタイプビットマップフィールドに設定されていないことを確認する必要があります。また、VALIDATORは、NSEC3 RRが正しい（つまり親）ゾーンからのものであることを確認する必要があります。これは、SOAビットがこのNSEC3 RRのタイプビットマップフィールドに設定されていないことを保証することによって行われます。
Note that the presence of an NS bit implies the absence of a DNAME bit, so there is no need to check for the DNAME bit in the Type Bit Maps field of the NSEC3 RR.
NSビットの存在は、DNAMEビットがないことを意味するため、NSEC3 RRのタイプビットマップフィールドでDNAMEビットを確認する必要はないことに注意してください。
If there is no NSEC3 RR present that matches the delegation name, then the validator MUST verify a closest provable encloser proof for the delegation name. The validator MUST verify that the Opt-Out bit is set in the NSEC3 RR that covers the "next closer" name to the delegation name.
委任名と一致するNSEC3 RRの存在がない場合、バリデーターは、委任名の最も近い証明可能なエンクローザー証明を確認する必要があります。バリーターは、オプトアウトビットが代表団の「次の近い」名前をカバーするNSEC3 RRに設定されていることを確認する必要があります。
Caching resolvers MUST be able to retrieve the appropriate NSEC3 RRs when returning responses that contain them. In DNSSEC [RFC4035], in many cases it is possible to find the correct NSEC RR to return in a response by name (e.g., when returning a referral, the NSEC RR will always have the same owner name as the delegation). With this specification, that will not be true, nor will a cache be able to calculate the name(s) of the appropriate NSEC3 RR(s). Implementations may need to use new methods for caching and retrieving NSEC3 RRs.
キャッシュリゾルバーは、それらを含む応答を返すときに適切なNSEC3 RRを取得できる必要があります。DNSSEC [RFC4035]では、多くの場合、正しいNSEC RRが名前で応答を返すことができます（たとえば、紹介を返すとき、NSEC RRは常に委任と同じ所有者名を持ちます）。この仕様では、それは真実ではなく、キャッシュが適切なNSEC3 RRの名前を計算することもできません。実装は、NSEC3 RRSのキャッシュと取得に新しい方法を使用する必要がある場合があります。
The AD bit, as defined by [RFC4035], MUST NOT be set when returning a response containing a closest (provable) encloser proof in which the NSEC3 RR that covers the "next closer" name has the Opt-Out bit set.
[RFC4035]で定義されているADビットは、「次の近い」名前をカバーするNSEC3 RRがオプトアウトビットセットを持っているNSEC3 RRを含む最も近い（証明可能な）囲い込みの証明を含む応答を返すときに設定してはなりません。
This rule is based on what this closest encloser proof actually proves: names that would be covered by the Opt-Out NSEC3 RR may or may not exist as insecure delegations. As such, not all the data in responses containing such closest encloser proofs will have been cryptographically verified, so the AD bit cannot be set.
このルールは、この最も近い囲いの証明が実際に証明するものに基づいています。オプトアウトNSEC3 RRによってカバーされる名前は、不安定な代表団として存在する場合と存在しない場合があります。そのため、このような最も近い囲いの証明を含む応答のすべてのデータが暗号化された状態で検証されているわけではないため、ADビットを設定できません。
Zones signed using this specification have additional domain name length restrictions imposed upon them. In particular, zones with names that, when converted into hashed owner names exceed the 255 octet length limit imposed by [RFC1035], cannot use this specification.
この仕様を使用して署名されたゾーンには、それらに課される追加のドメイン名の長さの制限があります。特に、ハッシュされた所有者名に変換された場合、[RFC1035]によって課される255オクテットの長さの制限を超える名前のゾーンは、この仕様を使用できません。
The actual maximum length of a domain name in a particular zone depends on both the length of the zone name (versus the whole domain name) and the particular hash function used.
特定のゾーンのドメイン名の実際の最大長は、ゾーン名の長さ（ドメイン名全体）と使用される特定のハッシュ関数の両方に依存します。
As an example, SHA-1 produces a hash of 160 bits. The base-32 encoding of 160 bits results in 32 characters. The 32 characters are prepended to the name of the zone as a single label, which includes a length field of a single octet. The maximum length of the zone name, when using SHA-1, is 222 octets (255 - 33).
例として、SHA-1は160ビットのハッシュを生成します。160ビットのベース32エンコードにより、32文字が発生します。32文字は、単一のラベルとしてゾーンの名前に加えられます。これには、単一のオクテットの長さフィールドが含まれます。ゾーン名の最大長は、SHA -1を使用する場合、222オクテット（255-33）です。
The DNAME specification in Section 3 of [RFC2672] has a 'no-descendants' limitation. If a DNAME RR is present at node N, there MUST be no data at any descendant of N.
[RFC2672]のセクション3のDNAME仕様には、「ne-descendants」の制限があります。DNAME RRがNode Nに存在する場合、Nの子孫にデータがない必要があります。
If N is the apex of the zone, there will be NSEC3 and RRSIG types present at descendants of N. This specification updates the DNAME specification to allow NSEC3 and RRSIG types at descendants of the apex regardless of the existence of DNAME at the apex.
nがゾーンの頂点である場合、Nの子孫にNSEC3およびRRSIGタイプが存在します。この仕様は、dNAME仕様を更新して、頂点でのDNAMEの存在に関係なく、頂点の子孫でNSEC3およびRRSIGタイプを許可します。
Setting the number of iterations used allows the zone owner to choose the cost of computing a hash, and therefore the cost of generating a dictionary. Note that this is distinct from the effect of salt, which prevents the use of a single precomputed dictionary for all time.
使用される反復の数を設定すると、ゾーンの所有者はハッシュを計算するコストを選択するため、辞書を生成するコストを選択できます。これは、塩の効果とは異なることに注意してください。これは、常に1つの事前計算辞書の使用を防ぐことを防ぎます。
Obviously the number of iterations also affects the zone owner's cost of signing and serving the zone as well as the validator's cost of verifying responses from the zone. We therefore impose an upper limit on the number of iterations. We base this on the number of iterations that approximates the cost of verifying an RRSet.
明らかに、反復回数は、ゾーンの所有者の署名とサービスのコストと、ゾーンからの応答を確認するバリデーターのコストにも影響します。したがって、反復数に上限を課します。これを、RRSetを検証するコストに近い反復数に基づいています。
The limits, therefore, are based on the size of the smallest zone signing key, rounded up to the nearest table value (or rounded down if the key is larger than the largest table value).
したがって、制限は、最寄りのテーブル値（またはキーが最大のテーブル値よりも大きい場合は丸められた場合）に丸められた最小ゾーン署名キーのサイズに基づいています。
A zone owner MUST NOT use a value higher than shown in the table below for iterations for the given key size. A resolver MAY treat a response with a higher value as insecure, after the validator has verified that the signature over the NSEC3 RR is correct.
ゾーンの所有者は、指定されたキーサイズの反復について、下の表に示すよりも高い値を使用してはなりません。Resolverは、NSEC3 RRの署名が正しいことを検証装置が確認した後、より高い値でより高い値で応答を不安定に扱うことができます。
+----------+------------+
| Key Size | Iterations |
+----------+------------+
| 1024 | 150 |
| 2048 | 500 |
| 4096 | 2,500 |
+----------+------------+
This table is based on an approximation of the ratio between the cost of an SHA-1 calculation and the cost of an RSA verification for keys of size 1024 bits (150 to 1), 2048 bits (500 to 1), and 4096 bits (2500 to 1).
この表は、SHA-1計算のコストとサイズ1024ビット（150〜1）、2048ビット（500〜1）、および4096ビットのキーのRSA検証のコストの比率の近似に基づいています。2500〜1）。
The ratio between SHA-1 calculation and DSA verification is higher (1500 to 1 for keys of size 1024). A higher iteration count degrades performance, while DSA verification is already more expensive than RSA for the same key size. Therefore the values in the table MUST be used independent of the key algorithm.
SHA-1計算とDSA検証の比率は高くなっています（サイズ1024のキーの場合は1500〜1）。イテレーションカウントが高いほどパフォーマンスが低下しますが、DSAの検証は、同じキーサイズでRSAよりもすでに高価です。したがって、テーブル内の値は、キーアルゴリズムとは無関係に使用する必要があります。
When transitioning an already signed and trusted zone to this specification, care must be taken to prevent client validation failures during the process.
既に署名され、信頼できるゾーンをこの仕様に移行する場合、プロセス中にクライアントの検証障害を防ぐために注意する必要があります。
The basic procedure is as follows:
基本的な手順は次のとおりです。
1. Transition all DNSKEYs to DNSKEYs using the algorithm aliases described in Section 2. The actual method for safely and securely changing the DNSKEY RRSet of the zone is outside the scope of this specification. However, the end result MUST be that all DS RRs in the parent use the specified algorithm aliases.
1. セクション2で説明したアルゴリズムエイリアスを使用して、すべてのdnskeysにdnskeysに移行します。ただし、最終結果は、親のすべてのDS RRSが指定されたアルゴリズムエイリアスを使用していることです。
After this transition is complete, all NSEC3-unaware clients will treat the zone as insecure. At this point, the authoritative server still returns negative and wildcard responses that contain NSEC RRs.
この移行が完了した後、すべてのNSEC3-Unawareクライアントはゾーンを不安定なものとして扱います。この時点で、権威あるサーバーは、NSEC RRSを含むネガティブおよびワイルドカードの応答を引き続き返します。
2. Add signed NSEC3 RRs to the zone, either incrementally or all at once. If adding incrementally, then the last RRSet added MUST be the NSEC3PARAM RRSet.
2. 署名されたNSEC3 RRSを、段階的または一度にすべてをゾーンに追加します。増分的に追加する場合、追加された最後のRRSetはNSEC3Param RRSetでなければなりません。
3. Upon the addition of the NSEC3PARAM RRSet, the server switches to serving negative and wildcard responses with NSEC3 RRs according to this specification.
3. NSEC3PARAM RRSETを追加すると、サーバーはこの仕様に従ってNSEC3 RRSを使用してネガティブおよびワイルドカード応答を提供するように切り替えます。
4. Remove the NSEC RRs either incrementally or all at once.
4. NSEC RRSを徐々にまたは一度にすべて削除します。
To safely transition back to a DNSSEC [RFC4035] signed zone, simply reverse the procedure above:
安全にDNSSEC [RFC4035]署名ゾーンに戻るには、上記の手順を逆にするだけです。
1. Add NSEC RRs incrementally or all at once.
1. NSEC RRSを増分またはすべてを一度に追加します。
2. Remove the NSEC3PARAM RRSet. This will signal the server to use the NSEC RRs for negative and wildcard responses.
2. nsec3param rrsetを削除します。これにより、ネガティブおよびワイルドカードの応答にNSEC RRSを使用するようにサーバーが信号を送ります。
3. Remove the NSEC3 RRs either incrementally or all at once.
3. NSEC3 RRSを徐々にまたは一度にすべて削除します。
4. Transition all of the DNSKEYs to DNSSEC algorithm identifiers. After this transition is complete, all NSEC3-unaware clients will treat the zone as secure.
4. すべてのDNSKEYSをDNSSECアルゴリズム識別子に遷移します。この移行が完了した後、すべてのNSEC3-Unawareクライアントはゾーンを安全なものとして扱います。
Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm parameter, this document does not define a particular mechanism for safely transitioning from one NSEC3 hash algorithm to another. When specifying a new hash algorithm for use with NSEC3, a transition mechanism MUST also be defined.
NSEC3およびNSEC3PARAM RR形式にはハッシュアルゴリズムパラメーターが含まれていますが、このドキュメントは、あるNSEC3ハッシュアルゴリズムから別のNSEC3ハッシュアルゴリズムに安全に移行する特定のメカニズムを定義していません。NSEC3で使用する新しいハッシュアルゴリズムを指定する場合、遷移メカニズムも定義する必要があります。
This document updates the IANA registry "DOMAIN NAME SYSTEM PARAMETERS" (http://www.iana.org/assignments/dns-parameters) in sub-registry "TYPES", by defining two new types. Section 3 defines the NSEC3 RR type 50. Section 4 defines the NSEC3PARAM RR type 51.
このドキュメントは、2つの新しいタイプを定義することにより、サブレジストリ「タイプ」のIANAレジストリ「ドメイン名システムパラメーター」（http://www.iana.org/assignments/dns-parameters）を更新します。セクション3では、NSEC3 RRタイプ50を定義します。セクション4には、NSEC3PARAM RRタイプ51を定義します。
This document updates the IANA registry "DNS SECURITY ALGORITHM NUMBERS -- per [RFC4035]" (http://www.iana.org/assignments/dns-sec-alg-numbers). Section 2 defines the aliases DSA-NSEC3-SHA1 (6) and RSASHA1-NSEC3-SHA1 (7) for respectively existing registrations DSA and RSASHA1 in combination with NSEC3 hash algorithm SHA1.
このドキュメントは、IANAレジストリ「DNSセキュリティアルゴリズム番号-RFC4035]」（http://www.iana.org/assignments/dns-sec-alg-numbers）を更新します。セクション2では、NSEC3ハッシュアルゴリズムSHA1と組み合わせた既存の登録DSAおよびRSASHA1について、それぞれ既存の登録DSAおよびRSASHA1について、DSA-NSEC3-SHA1（6）およびRSASHA1-NSEC3-SHA1（7）エイリアスを定義します。
Since these algorithm numbers are aliases for existing DNSKEY algorithm numbers, the flags that exist for the original algorithm are valid for the alias algorithm.
これらのアルゴリズム番号は既存のDNSKEYアルゴリズム番号のエイリアスであるため、元のアルゴリズムに存在するフラグはエイリアスアルゴリズムに有効です。
This document creates a new IANA registry for NSEC3 flags. This registry is named "DNSSEC NSEC3 Flags". The initial contents of this registry are:
このドキュメントは、NSEC3フラグの新しいIANAレジストリを作成します。このレジストリは、「DNSSEC NSEC3フラグ」と呼ばれます。このレジストリの最初の内容は次のとおりです。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| | | | | | | |Opt|
| | | | | | | |Out|
+---+---+---+---+---+---+---+---+
bit 7 is the Opt-Out flag.
ビット7はオプトアウトフラグです。
bits 0 - 6 are available for assignment.
ビット0-6は割り当てに利用できます。
Assignment of additional NSEC3 Flags in this registry requires IETF Standards Action [RFC2434].
このレジストリでの追加のNSEC3フラグの割り当てには、IETF標準アクション[RFC2434]が必要です。
This document creates a new IANA registry for NSEC3PARAM flags. This registry is named "DNSSEC NSEC3PARAM Flags". The initial contents of this registry are:
このドキュメントは、NSEC3Paramフラグの新しいIANAレジストリを作成します。このレジストリは、「DNSSEC NSEC3PARAMフラグ」と呼ばれます。このレジストリの最初の内容は次のとおりです。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| | | | | | | | 0 |
+---+---+---+---+---+---+---+---+
bit 7 is reserved and must be 0.
ビット7は予約されており、0でなければなりません。
bits 0 - 6 are available for assignment.
ビット0-6は割り当てに利用できます。
Assignment of additional NSEC3PARAM Flags in this registry requires IETF Standards Action [RFC2434].
このレジストリでの追加のNSEC3PARAMフラグの割り当てには、IETF標準アクション[RFC2434]が必要です。
Finally, this document creates a new IANA registry for NSEC3 hash algorithms. This registry is named "DNSSEC NSEC3 Hash Algorithms". The initial contents of this registry are:
最後に、このドキュメントは、NSEC3ハッシュアルゴリズムの新しいIANAレジストリを作成します。このレジストリは「DNSSEC NSEC3ハッシュアルゴリズム」と呼ばれます。このレジストリの最初の内容は次のとおりです。
0 is Reserved.
0は予約されています。
1 is SHA-1.
1はsha-1です。
2-255 Available for assignment.
2-255課題に利用できます。
Assignment of additional NSEC3 hash algorithms in this registry requires IETF Standards Action [RFC2434].
このレジストリにおける追加のNSEC3ハッシュアルゴリズムの割り当てには、IETF標準アクション[RFC2434]が必要です。
The NSEC3 RRs are still susceptible to dictionary attacks (i.e., the attacker retrieves all the NSEC3 RRs, then calculates the hashes of all likely domain names, comparing against the hashes found in the NSEC3 RRs, and thus enumerating the zone). These are substantially more expensive than enumerating the original NSEC RRs would have been, and in any case, such an attack could also be used directly against the name server itself by performing queries for all likely names, though this would obviously be more detectable. The expense of this off-line attack can be chosen by setting the number of iterations in the NSEC3 RR.
NSEC3 RRSは、辞書攻撃の影響を受けやすくなります（つまり、攻撃者はすべてのNSEC3 RRを取得し、すべての可能性の高いドメイン名のハッシュを計算し、NSEC3 RRSで見つかったハッシュと比較してゾーンを列挙します）。これらは、元のNSEC RRSを列挙するよりもかなり高価であり、いずれにせよ、そのような攻撃は、すべての可能性のある名前のクエリを実行することで名前サーバー自体に対して直接使用することもできますが、これは明らかに検出可能です。このオフライン攻撃の費用は、NSEC3 RRの反復回数を設定することで選択できます。
Zones are also susceptible to a pre-calculated dictionary attack -- that is, a list of hashes for all likely names is computed once, then NSEC3 RR is scanned periodically and compared against the precomputed hashes. This attack is prevented by changing the salt on a regular basis.
また、ゾーンは事前に計算された辞書攻撃の影響を受けやすいです。つまり、すべての可能性のある名前のハッシュのリストが一度計算され、NSEC3 RRが定期的にスキャンされ、事前に計算されたハッシュと比較されます。この攻撃は、定期的に塩を変更することにより防止されます。
The salt SHOULD be at least 64 bits long and unpredictable, so that an attacker cannot anticipate the value of the salt and compute the next set of dictionaries before the zone is published.
塩は塩の値を予測し、ゾーンが公開される前に次の一連の辞書を計算することができないため、塩は少なくとも64ビットで予測不可能でなければなりません。
Hash collisions between QNAME and the owner name of an NSEC3 RR may occur. When they do, it will be impossible to prove the non-existence of the colliding QNAME. However, with SHA-1, this is highly unlikely (on the order of 1 in 2^160). Note that DNSSEC already relies on the presumption that a cryptographic hash function is second pre-image resistant, since these hash functions are used for generating and validating signatures and DS RRs.
QNAMEとNSEC3 RRの所有者名との間のハッシュ衝突が発生する可能性があります。彼らがそうするとき、衝突QNameの存在を証明することは不可能です。ただし、SHA-1では、これは非常にありそうもない（2^160で1オーダーで）。DNSSECは、これらのハッシュ関数が署名とDS RRSの生成と検証に使用されるため、暗号化のハッシュ関数が2番目の前イメージ抵抗性であるという推定にすでに依存していることに注意してください。
Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm parameter, this document does not define a particular mechanism for safely transitioning from one NSEC3 hash algorithm to another. When specifying a new hash algorithm for use with NSEC3, a transition mechanism MUST also be defined. It is possible that the only practical and palatable transition mechanisms may require an intermediate transition to an insecure state, or to a state that uses NSEC records instead of NSEC3.
NSEC3およびNSEC3PARAM RR形式にはハッシュアルゴリズムパラメーターが含まれていますが、このドキュメントは、あるNSEC3ハッシュアルゴリズムから別のNSEC3ハッシュアルゴリズムに安全に移行する特定のメカニズムを定義していません。NSEC3で使用する新しいハッシュアルゴリズムを指定する場合、遷移メカニズムも定義する必要があります。唯一の実用的で味付け可能な遷移メカニズムは、安全でない状態、またはNSEC3の代わりにNSECレコードを使用する状態への中間遷移を必要とする可能性があります。
Since validators should treat responses containing NSEC3 RRs with high iteration values as insecure, presence of just one signed NSEC3 RR with a high iteration value in a zone provides attackers with a possible downgrade attack.
バリデーターは、高い反復値を持つNSEC3 RRSを含む応答を不安定であると扱う必要があるため、ゾーン内で高い反復値を持つ1つの署名されたNSEC3 RRの存在は、攻撃者にダウングレード攻撃の可能性を提供します。
The attack is simply to remove any existing NSEC3 RRs from a response, and replace or add a single (or multiple) NSEC3 RR that uses a high iterations value to the response. Validators will then be forced to treat the response as insecure. This attack would be effective only when all of following conditions are met:
攻撃は、単に応答から既存のNSEC3 RRを削除し、応答に高い反復値を使用する単一（または複数の）NSEC3 RRを置き換えるか追加することです。その後、バリデーターは、応答を不安定であると扱うことを余儀なくされます。この攻撃は、次の条件がすべて満たされている場合にのみ有効になります。
o There is at least one signed NSEC3 RR that uses a high iterations value present in the zone.
o ゾーン内に存在する高い反復値を使用する少なくとも1つの署名されたNSEC3 RRがあります。
o The attacker has access to one or more of these NSEC3 RRs. This is trivially true when the NSEC3 RRs with high iteration values are being returned in typical responses, but may also be true if the attacker can access the zone via AXFR or IXFR queries, or any other methodology.
o 攻撃者は、これらのNSEC3 RRの1つ以上にアクセスできます。これは、典型的な応答で高い反復値を持つNSEC3 RRSが返されている場合、些細なことですが、攻撃者がAXFRまたはIXFRクエリまたはその他の方法論を介してゾーンにアクセスできる場合にも当てはまる場合があります。
Using a high number of iterations also introduces an additional denial-of-service opportunity against servers, since servers must calculate several hashes per negative or wildcard response.
また、多数の反復を使用すると、サーバーがネガティブまたはワイルドカード応答ごとにいくつかのハッシュを計算する必要があるため、サーバーに対して追加のサービス拒否の機会が導入されます。
The Opt-Out Flag (O) allows for unsigned names, in the form of delegations to unsigned zones, to exist within an otherwise signed zone. All unsigned names are, by definition, insecure, and their validity or existence cannot be cryptographically proven.
オプトアウトフラグ（o）により、署名されていないゾーンの代表団の形で、署名されていないゾーンに署名されていないゾーン内に存在するようになります。定義上、すべての署名のない名前は安全ではなく、その有効性または存在を暗号化することはできません。
In general:
一般に：
o Resource records with unsigned names (whether existing or not) suffer from the same vulnerabilities as RRs in an unsigned zone. These vulnerabilities are described in more detail in [RFC3833] (note in particular Section 2.3, "Name Chaining" and Section 2.6, "Authenticated Denial of Domain Names").
o 署名されていない名前（既存のかどうかにかかわらず）を持つリソースレコードは、署名されていないゾーンでのRRと同じ脆弱性に苦しんでいます。これらの脆弱性については、[RFC3833]で詳しく説明しています（特にセクション2.3、「名前チェーン」とセクション2.6、「ドメイン名の認証された拒否」）。
o Resource records with signed names have the same security whether or not Opt-Out is used.
o 署名された名前を持つリソースレコードには、オプトアウトが使用されているかどうかにかかわらず、同じセキュリティがあります。
Note that with or without Opt-Out, an insecure delegation may be undetectably altered by an attacker. Because of this, the primary difference in security when using Opt-Out is the loss of the ability to prove the existence or nonexistence of an insecure delegation within the span of an Opt-Out NSEC3 RR.
オプトアウトの有無にかかわらず、不安定な代表団は攻撃者によって検出可能に変更される可能性があることに注意してください。このため、オプトアウトを使用する際のセキュリティの主な違いは、オプトアウトNSEC3 RRの範囲内での不安定な代表団の存在または非存在を証明する能力の喪失です。
In particular, this means that a malicious entity may be able to insert or delete RRs with unsigned names. These RRs are normally NS RRs, but this also includes signed wildcard expansions (while the wildcard RR itself is signed, its expanded name is an unsigned name).
特に、これは悪意のあるエンティティが、署名されていない名前でRRを挿入または削除できることを意味します。これらのRRは通常NS RRSですが、これには署名されたワイルドカード拡張も含まれます（ワイルドカードRR自体が署名されている間、その拡張名は署名されていない名前です）。
Note that being able to add a delegation is functionally equivalent to being able to add any RR type: an attacker merely has to forge a delegation to name server under his/her control and place whatever RRs needed at the subzone apex.
代表団を追加できることは、任意のRRタイプを追加できることと機能的に同等です。攻撃者は、自分のコントロールの下にサーバーに名前を付けるための代表団を偽造し、Subzone Apexで必要なRRを配置するだけです。
While in particular cases, this issue may not present a significant security problem, in general it should not be lightly dismissed. Therefore, it is strongly RECOMMENDED that Opt-Out be used sparingly. In particular, zone signing tools SHOULD NOT default to using Opt-Out, and MAY choose to not support Opt-Out at all.
特にケースでは、この問題は重大なセキュリティの問題を提示しない可能性がありますが、一般に軽く却下するべきではありません。したがって、オプトアウトを控えめに使用することを強くお勧めします。特に、ゾーン署名ツールはオプトアウトを使用することをデフォルトしないでください。また、オプトアウトをまったくサポートしないことを選択できます。
Walking the NSEC3 RRs will reveal the total number of RRs in the zone (plus empty non-terminals), and also what types there are. This could be mitigated by adding dummy entries, but certainly an upper limit can always be found.
NSEC3 RRSを歩くと、ゾーン内のRRの総数（プラス空の非ターミナル）、およびそこにあるタイプが明らかになります。これは、ダミーエントリを追加することで軽減できますが、確かに上限はいつでも見つかります。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136] Vixie、P.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメイン名システム（DNSアップデート）の動的更新」、RFC 2136、1997年4月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、RFC 2181、1997年7月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308] Andrews、M。、「DNSクエリの負のキャッシュ（DNS NCACHE）」、RFC 2308、1998年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, September 2000.
[RFC2929] Eastlake、D.、Brunner-Williams、E.、およびB. Manning、「ドメイン名システム（DNS）IANA考慮事項」、BCP 42、RFC 2929、2000年9月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597] Gustafsson、A。、「不明なDNSリソースレコード（RR）タイプの取り扱い」、RFC 3597、2003年9月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のリソースレコード」、RFC 4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張のプロトコル変更」、RFC 4035、2005年3月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[DNSEXT-NO] Josefsson, S., "Authenticating Denial of Existence in DNS with Minimum Disclosure", Work in Progress, July 2000.
[Dnsext-no] Josefsson、S。、「最小開示を伴うDNSにおける存在の拒否を認証する」、2000年7月、進行中の作業。
[DNSEXT-NSEC2v2] Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format", Work in Progress, December 2004.
[DNSEXT-NSEC2V2] Laurie、B。、「DNSSEC NSEC2所有者およびRDATA形式」、2004年12月、進行中の作業。
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[RFC2672] Crawford、M。、「非末端DNS名リダイレクト」、RFC 2672、1999年8月。
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[RFC2898] Kaliski、B。、「PKCS＃5：パスワードベースの暗号仕様バージョン2.0」、RFC 2898、2000年9月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析（DNS）」、RFC 3833、2004年8月。
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006.
[RFC4592]ルイス、E。、「ドメイン名システムにおけるワイルドカードの役割」、RFC 4592、2006年7月。
[RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security (DNSSEC) Opt-In", RFC 4956, July 2007.
[RFC4956] Arends、R.、Kosters、M。、およびD. Blacka、「DNS Security（DNSSEC）Opt-in」、RFC 4956、2007年7月。
This is a zone showing its NSEC3 RRs. They can also be used as test vectors for the hash algorithm.
これは、NSEC3 RRSを示すゾーンです。また、ハッシュアルゴリズムのテストベクトルとして使用することもできます。
The overall TTL and class are specified in the SOA RR, and are subsequently omitted for clarity.
全体的なTTLとクラスはSOA RRで指定されており、その後、明確にするために省略されます。
The zone is preceded by a list that contains the hashes of the original ownernames.
ゾーンの前には、元の所有者のハッシュを含むリストがあります。
; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
; H(a.example) = 35mthgpgcu1qg68fab165klnsnk3dpvl
; H(ai.example) = gjeqe526plbf1g8mklp59enfd789njgi
; H(ns1.example) = 2t7b4g4vsa5smi47k61mv5bv1a22bojr
; H(ns2.example) = q04jkcevqvmu85r014c7dkba38o0ji5r
; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en
; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
; H(y.w.example) = ji6neoaepv8b5o6k4ev33abha8ht9fgc
; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s
; H(xx.example) = t644ebqk9bibcna874givr6joj62mlhv
; H(2t7b4g4vsa5smi47k61mv5bv1a22bojr.example)
; = kohar7mbb8dc2ce8a9qvl8hon4k53uhi
example. 3600 IN SOA ns1.example. bugs.x.w.example. 1 3600 300 (
3600000 3600 )
RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
40430 example.
Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
VI2LmKusbZsT0Q== )
NS ns1.example.
NS ns2.example.
RRSIG NS 7 1 3600 20150420235959 20051021000000 (
40430 example.
PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ
qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv
CnMXjtz6SyObxA== )
MX 1 xx.example.
RRSIG MX 7 1 3600 20150420235959 20051021000000 (
40430 example.
GgQ1A9xs47k42VPvpL/a1BWUz/6XsnHkjotw
9So8MQtZtl2wJBsnOQsaoHrRCrRbyriEl/GZ
n9Mto/Kx+wBo+w== )
DNSKEY 256 3 7 AwEAAaetidLzsKWUt4swWR8yu0wPHPiUi8LU (
sAD0QPWU+wzt89epO6tHzkMBVDkC7qphQO2h
TY4hHn9npWFRw5BYubE= )
DNSKEY 257 3 7 AwEAAcUlFV1vhmqx6NSOUOq2R/dsR7Xm3upJ ( j7IommWSpJABVfW8Q0rOvXdM6kzt+TAu92L9 AbsUdblMFin8CVF3n4s= ) RRSIG DNSKEY 7 1 3600 20150420235959 ( 20051021000000 12708 example. AuU4juU9RaxescSmStrQks3Gh9FblGBlVU31 uzMZ/U/FpsUb8aC6QZS+sTsJXnLnz7flGOsm MGQZf3bH+QsCtg== ) NSEC3PARAM 1 0 12 aabbccdd RRSIG NSEC3PARAM 7 1 3600 20150420235959 ( 20051021000000 40430 example. C1Gl8tPZNtnjlrYWDeeUV/sGLCyy/IHie2re rN05XSA3Pq0U3+4VvGWYWdUMfflOdxqnXHwJ TLQsjlkynhG6Cg== ) 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762 BOCXJZMnpuwhpA== ) 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127 RRSIG A 7 2 3600 20150420235959 20051021000000 ( 40430 example. h6c++bzhRuWWt2bykN6mjaTNBcXNq5UuL5Ed K+iDP4eY8I0kSiKaCjg3tC1SQkeloMeub2GW k8p6xHMPZumXlw== ) NSEC3 1 1 12 aabbccdd ( 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN 4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq NI6mRk/r1dOSUw== ) 2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd ( 35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. KL1V2oFYghNV0Hm7Tf2vpJjM6l+0g1JCcVYG VfI0lKrhPmTsOA96cLEACgo1x8I7kApJX+ob TuktZ+sdsZPY1w== ) 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
DNSKEY 257 3 7 AWEAACULFV1VHMQX6NSOUOQ2R/DSR7XM3UPJ（J7IOMMWSPJABVVFWW8Q0ROVXDM6KZT TAU92L9 AUSUDBLMFIN8CVF3N4S =）rrsig U31 UZMZ/U/FPSUB8AC6QZS STSJXNLNZ7FLGOSM MGQZF3BH QSCTG ==）NSEC3PARAM 1 0 12 AABBCCDD RRSIG NSEC3PARAM 7 1 3600 20150420235959（200510210000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000430NSEC3 1 1 12 AABBCCDD（2T7B4G4VSA5SMI47K61MV5BV1A22BOJR MX DNSKEY NS SOA NSEC3PARAM RRSIG）RRSIG NSEC3 7 2 3600 20150420235959200510210000（40430のDDECWM26CHM26CHM26CHM26CHM26CHM26CHM26302100000210000021000002100000210000021000002100000210000） 0bmjpwq4mliuw85h2ey762 bocxjzmnpuwhpa ==）2T7B4G4VSA5SMI47K61MV5BV1A22BOJR.EXAMPLE。=）2VPTU5TIMAMQTGL4LUU9KG21E0AOR3S.EXAMPLE。NSEC3 1 1 12 AABBCCDD（B4UM86EGHHDS6NEA196SMVMLO4ORS995 NS DS RRSIG）
RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ XtAIR3chwgW+SA== ) a.example. NS ns1.a.example. NS ns2.a.example. DS 58470 5 1 ( 3079F1593EBAD6DC121E202A8B766A6A4837206C ) RRSIG DS 7 2 3600 20150420235959 20051021000000 ( 40430 example. XacFcQVHLVzdoc45EJhN616zQ4mEXtE8FzUh M2KWjfy1VfRKD9r1MeVGwwoukOKgJxBPFsWo o722vZ4UZ2dIdA== ) ns1.a.example. A 192.0.2.5 ns2.a.example. A 192.0.2.6 ai.example. A 192.0.2.9 RRSIG A 7 2 3600 20150420235959 20051021000000 ( 40430 example. hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+ rznEn8sQ64UdqA== ) HINFO "KLH-10" "ITS" RRSIG HINFO 7 2 3600 20150420235959 20051021000000 ( 40430 example. Yi42uOq43eyO6qXHNvwwfFnIustWgV5urFcx enkLvs6pKRh00VBjODmf3Z4nMO7IOl6nHSQ1 v0wLHpEZG7Xj2w== ) AAAA 2001:db8:0:0:0:0:f00:baa9 RRSIG AAAA 7 2 3600 20150420235959 20051021000000 ( 40430 example. LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG cHueLuXkMjBArQ== ) b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd ( gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh 5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3 pOv0TSTyiTxIZg== ) c.example. NS ns1.c.example. NS ns2.c.example. ns1.c.example. A 192.0.2.7 ns2.c.example. A 192.0.2.8 gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd ( ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA RRSIG )
rrsig nsec3 7 2 3600 20150420235959 20051021000000（40430の例。g6jpuupduajkrljusn8gb4uagax0nxy9shwqaynzo8euwh z6heiblutpgj15ezll6vhhqgz dextair3chwgw sa =NS NS1.A.Example。NS NS2.A.Example。DS 58470 5 1（3079F1593EBAD6DC121E202A8B766A6A4837206C）RRSIG DS 7 2 3600 20150420235959 20051021000000（40430の例。XACFCVFCVFCKCFCM61616161616161616161616161616161616161616161616161 22vz4uz2dida ==）ns1.a.example。A 192.0.2.5 NS2.A.Example。A 192.0.2.6 ai.example。192.0.2.9 rrsig a 7 2 3600 20150420235959 20051021000000（40430の例。HVEWKIMLOBTRPHX0NL67GXEZFDXQR/QER6F TFDAJ5 FGYXYZPEJIZVKWY00HWIL6WD3BWS fINFCN FAMFC hmf f.f flnfcwy 20235959 2005102100000000（40430の例。yi42uoq43eyo6qhnvwwffniustwgv55urfcx enklvs6pkrh00vbjodmf3z4nmo7iol6nhsq1 v0wlhpezg7xj2w ====NSEC3 1 1 12 AABBCCDD（GJEQE526PLBF1G8MKLP59ENFD789NJGI MX RRSIG）RRSIG NSEC3 7 2 3600 20150420235959 20051021000000（40430/ckpg3m32mm6pakfakfakfakfakfakfakfakfakfcpg3m2lmm6pakfcpg3m32lmm6pakfcpg32lmm6pakfm43mm6pakfcpg3m32lmm32lmm6pcpg32lmm32mm32mm632mm6pmpmm6pakfcpg32lmをix43alx3 pov0tstyitxizg ==）c。例。NS NS1.C.Example。NS NS2.C.Example。ns1.c.example。A 192.0.2.7 NS2.C.Example。A 192.0.2.8 GJEQE526PLBF1G8MKLP59ENFD789NJGI.example。nsec3 1 1 12 aabbccdd（ji6neoaepv8b5o6k4ev33abha8ht9fgc hinfo aaaa rrsig）
RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. IVnezTJ9iqblFF97vPSmfXZ5Zozngx3KX3by LTZC4QBH2dFWhf6scrGFZB980AfCxoD9qbbK Dy+rdGIeRSVNyw== ) ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd ( k8udemvp1j2f7eg6jebps17vp3n8i58h ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7 2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0 MpzVSKfTwx4uYA== ) k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd ( kohar7mbb8dc2ce8a9qvl8hon4k53uhi ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt Otx7w9WfcIg62A== ) kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd ( q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. VrDXs2uVW21N08SyQIz88zml+y4ZCInTwgDr 6zz43yAg+LFERjOrj3Ojct51ac7Dp4eZbf9F QJazmASFKGxGXg== ) ns1.example. A 192.0.2.1 RRSIG A 7 2 3600 20150420235959 20051021000000 ( 40430 example. bu6kx73n6XEunoVGuRfAgY7EF/AJqHy7hj0j kiqJjB0dOrx3wuz9SaBeGfqWIdn/uta3SavN 4FRvZR9SCFHF5Q== ) ns2.example. A 192.0.2.2 RRSIG A 7 2 3600 20150420235959 20051021000000 ( 40430 example. ktQ3TqE0CfRfki0Rb/Ip5BM0VnxelbuejCC4 zpLbFKA/7eD7UNAwxMgxJPtbdST+syjYSJaj 4IHfeX6n8vfoGA== ) q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3 ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN NlkxWcLsIlMmUg== )
rrsig nsec3 7 2 3600 20150420235959 2005102100000000（40430の例。Ivneztj9iqblff97Vpsmfxz5zozngx3kx3byltzc4qbh2dfwhf6scrgfzb980 = ddfwwhf6scrgfzb984kbnyfckgfnedgfmefckgfnedgfmefckgfnedgfmneNSEC3 1 1 12 AABBCCDD（K8UDEMVP1J2F7EG6JEBPS17VP3N8I58H）RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 kftwx4uya ==）k8udemvp1j2f7eg6jebps17vp3n8i58h.example。NSEC3 1 1 12 AABBCCDD（Q04JKCEVQVMU85R014C7DKBA38O0JI5R A RRSIG） azmasfkgxgxg ==）ns1.example。A 192.0.2.1 rrsig A 7 2 3600 20150420235959 20051021000000（40430の例。BU6KX73N6XEUNOVGURFAGY7EF/AJQHY7HJ0J KIQJJB0DORX3WUZ9SABIDN/UTA3SABMSVN 4F5
r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd ( t644ebqk9bibcna874givr6joj62mlhv MX RRSIG ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+ HF1FWKW7RIJdtQ== ) t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd ( 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA RRSIG ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. RAjGECB8P7O+F4Pa4Dx3tC0M+Z3KmlLKImca fb9XWwx+NWUNz7NBEDBQHivIyKPVDkChcePI X1xPl1ATNa+8Dw== ) *.w.example. MX 1 ai.example. RRSIG MX 7 2 3600 20150420235959 20051021000000 ( 40430 example. CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb 9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM ivEBP6+4KS3ldA== ) x.w.example. MX 1 xx.example. RRSIG MX 7 3 3600 20150420235959 20051021000000 ( 40430 example. IrK3tq/tHFIBF0scHiE/1IwMAvckS/55hAVv QyxTFbkAdDloP3NbZzu+yoSsr3b3OX6qbBpY 7WCtwwekLKRAwQ== ) x.y.w.example. MX 1 xx.example. RRSIG MX 7 4 3600 20150420235959 20051021000000 ( 40430 example. MqSt5HqJIN8+SLlzTOImrh5h9Xa6gDvAW/Gn nbdPc6Z7nXvCpLPJj/5lCwx3VuzVOjkbvXze 8/8Ccl2Zn2hbug== ) xx.example. A 192.0.2.10 RRSIG A 7 2 3600 20150420235959 20051021000000 ( 40430 example. T35hBWEZ017VC5u2c4OriKyVn/pu+fVK4AlX YOxJ6iQylfV2HQIKjv6b7DzINB3aF/wjJqgX pQvhq+Ac6+ZiFg== ) HINFO "KLH-10" "TOPS-20" RRSIG HINFO 7 2 3600 20150420235959 20051021000000 ( 40430 example. KimG+rDd+7VA1zRsu0ITNAQUTRlpnsmqWrih FRnU+bRa93v2e5oFNFYCs3Rqgv62K93N7AhW 6Jfqj/8NzWjvKg== ) AAAA 2001:db8:0:0:0:0:f00:baaa RRSIG AAAA 7 2 3600 20150420235959 20051021000000 ( 40430 example. IXBcXORITNwd8h3gNwyxtYFvAupS/CYWufVe uBUX0O25ivBCULjZjpDxFSxfohb/KA7YRdxE NzYfMItpILl/Xw== )
R53bq7cc2uvmubfu5ocmm6pers9tk9en.example。NSEC3 1 1 12 AABBCCDD（0P9MHAVEQVM6T7VBL5LOP2U3T2RP3TOMHINFO A AAAA RRSIG）RRSIG NSEC3 7 2 3600 chcepi x1xpl1atna 8dw ==） *.w.example。MX 1 ai.example。rrsig mx 7 2 3600 20150420235959 20051021000000（40430の例。cikebjqwgqpwijvcxgczczcsjktfynugtlbikb9fcbtrmooq4inowvudhcwsh/urx3lc4wrum eivebp6 4kks3lda = = = = = = = = =会い。mx 1 xx.example。RRSIG MX 7 3 3600 20150420235959 20051021000000（40430の例。IRK3TQ/THFIBF0SCHIE/1IWMAVCKS/55HAVV QYXTFBKADDLOP3NBZZU YOSSR3B3OX6QBBBYmx 1 xx.example。rrsig mx 7 4 3600 20150420235959 20051021000000（40430の例。MQST5HQJIN8SLLZTOIMRHRH5H9XA6GDVAW/GN NBDPC6Z7NXVCPLPJJ/5LCWX3VUZVOJKBBBXZE 8/5HBUGZE。A 192.0.2.10 rrsig A 7 2 3600 20150420235959 20051021000000（40430の例。T35HBWEZ017VC5U2C4ORIKYVN/PU FVK4ALX YOXJ6IQYLFV2HQIKJV6B6B7DZINB3AF/FJQF fINF/fJQFKID fidfe 20150420235959 20051021000000（40430の例。Kimg Rdd 7va1zrsu0itnaqutrlpnsmqwrih frnu bra93v2e5ofnfycs3rqgv62k93n7ahw6jfqj/8nzwjvkg == d8h3gnwyxtyfvaups/cywufve ubux0o25ivbculjzjpdxfsxfohb/ka7yrdxe nzyfmitpill/xw ==）
The examples in this section show response messages using the signed zone example in Appendix A.
このセクションの例は、付録Aの署名ゾーンの例を使用した応答メッセージを示しています。
An authoritative name error. The NSEC3 RRs prove that the name does not exist and that there is no wildcard RR that should have been expanded.
権威ある名前エラー。NSEC3 RRSは、名前が存在せず、拡張されるべきワイルドカードRRがないことを証明しています。
;; Header: QR AA DO RCODE=3
;;
;; Question
a.c.x.w.example. IN A
;; Answer
;; (empty)
;; Authority
;;権限
example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 ( 40430 example. Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd VI2LmKusbZsT0Q== )
例。soa ns1.example。bugs.x.w.example。1 3600 300（3600000 3600）の例。rrsig soa 7 1 3600 20150420235959 20051021000000（40430の例。Hu25uiynpmvpivbrldn9mlp9zql39qaud8i q4zllywfuubbas41pg 68z81q1xhkyaceyhd vi2lmkusbzst0qq =
;; NSEC3 RR that covers the "next closer" name (c.x.w.example)
;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh
0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG ) 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762 BOCXJZMnpuwhpA== )
0P9MHAVEQVM6T7VBL5LOP2U3T2RP3TOM.example。NSEC3 1 1 12 AABBCCDD（2T7B4G4VSA5SMI47K61MV5BV1A22BOJR MX DNSKEY NS SOA NSEC3PARAM RRSIG）RRSIG NSEC3 7 2 3600（20150420235959 20051021000000000040430例。OSGWSM26BCS DDL8B5QRWR/DEWHTCSKLWKL IBHYH6BLRXK9RC0BMJPWQ4MLIUW85H2Y762 BOCXJNNPUWHPUWWWWWW85H2Y762
;; NSEC3 RR that matches the closest encloser (x.w.example)
;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd ( gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) b4um86eghhds6nea196smvmlo4ors995.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh 5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3 pOv0TSTyiTxIZg== )
b4um86eghhds6nea196smvmlo4ors995.example。NSEC3 1 1 12 AABBCCDD（GJEQE526PLBF1G8MKLP59ENFD789NJGI MX RRSIG）B4UM86EGHHDS6NEA196SMVMLO4ORS95.EXAPLERRSIG NSEC3 7 2 3600（20150420235959 20051021000000000040430例。ZKPG3M32LMOHM6PA3D6GZFGB/RHL // BS3OMH 5U4M/CUIWTBLEVOAAKKZD7S9599OEIX43ALX3 POV0TTTYTTYTTYTTYTTYTTTYTTYTTTYTTTYTTYTTYTTTYTTTYTTYTTTYTTYTTTYTTYTTTYTTYTTY
;; NSEC3 RR that covers wildcard at the closest encloser (*.x.w.example)
;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m
35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) 35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ XtAIR3chwgW+SA== )
35MTHGPGCU1QG68FAB165KLNSNK3DPVL.example。NSEC3 1 1 12 AABBCCDD（B4UM86EGHHDS6NEA196SMVMLO4ORS995 NS DS RRSIG）35MTHGPGCU1QG68FAB165KLNSNK3DPVL.example。RRSIG NSEC3 7 2 3600（20150420235959 20051021000000000040430例。G6JPUUPDUAJKRLJUSN8GB4UAGAX0NXY9SHWQAYNZO8EUWHZ6HEIBLUTPGJ15EZLL6VHHQGZ XXTGGZ XTAIR3CHWWWWWWGWWWGWWGWWGWWW
;; Additional
;; (empty)
The query returned three NSEC3 RRs that prove that the requested data does not exist and that no wildcard expansion applies. The negative response is authenticated by verifying the NSEC3 RRs. The corresponding RRSIGs indicate that the NSEC3 RRs are signed by an "example" DNSKEY of algorithm 7 and with key tag 40430. The resolver needs the corresponding DNSKEY RR in order to authenticate this answer.
クエリは、要求されたデータが存在せず、ワイルドカードの拡張が適用されないことを証明する3つのNSEC3 RRSを返しました。否定的な応答は、NSEC3 RRSを検証することにより認証されます。対応するRRSIGは、NSEC3 RRSがアルゴリズム7の「例」DNSKEYとキータグ40430で署名されていることを示しています。この回答を認証するために、リゾルバーには対応するDNSKEY RRが必要です。
One of the owner names of the NSEC3 RRs matches the closest encloser. One of the NSEC3 RRs prove that there exists no longer name. One of the NSEC3 RRs prove that there exists no wildcard RRSets that should have been expanded. The closest encloser can be found by applying the algorithm in Section 8.3.
NSEC3 RRSの所有者名の1つは、最も近い封筒と一致します。NSEC3 RRSの1つは、名前が存在しなくなったことを証明しています。NSEC3 RRSの1つは、拡張されるはずのワイルドカードRRSetsが存在しないことを証明しています。最も近いエンクローザーは、セクション8.3にアルゴリズムを適用することで見つけることができます。
In the above example, the name 'x.w.example' hashes to 'b4um86eghhds6nea196smvmlo4ors995'. This indicates that this might be the closest encloser. To prove that 'c.x.w.example' and '*.x.w.example' do not exist, these names are hashed to, respectively, '0va5bpr2ou0vk0lbqeeljri88laipsfh' and '92pqneegtaue7pjatc3l3qnk738c6v5m'. The first and last NSEC3 RRs prove that these hashed owner names do not exist.
上記の例では、 'b4um86eghhds6nea196smvmlo4ors995'の名前 'x.w.example' hashes '。これは、これが最も近い囲いである可能性があることを示しています。「c.x.w.example」と「*.x.w.example」が存在しないことを証明するために、これらの名前はそれぞれ '0va5bpr2ou0vk0lbqeeljri88laipsfh'および '92pqneegtaue7pjatc3l3qnk738c6v5m'にハッシュされます。最初と最後のNSEC3 RRSは、これらのハッシュされた所有者名が存在しないことを証明しています。
A "no data" response. The NSEC3 RR proves that the name exists and that the requested RR type does not.
「データなし」応答。NSEC3 RRは、名前が存在し、要求されたRRタイプが存在しないことを証明しています。
;; Header: QR AA DO RCODE=0
;;
;; Question
ns1.example. IN MX
;; Answer
;; (empty)
;; Authority example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 ( 40430 example. Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd VI2LmKusbZsT0Q== )
;;権限の例。soa ns1.example。bugs.x.w.example。1 3600 300（3600000 3600）の例。rrsig soa 7 1 3600 20150420235959 20051021000000（40430の例。Hu25uiynpmvpivbrldn9mlp9zql39qaud8i q4zllywfuubbas41pg 68z81q1xhkyaceyhd vi2lmkusbzst0qq =
;; NSEC3 RR matches the QNAME and shows that the MX type bit is not set.
;;NSEC3 RRはQNAMEと一致し、MXタイプビットが設定されていないことを示しています。
2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd ( 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG ) 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN 4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq NI6mRk/r1dOSUw== ) ;; Additional ;; (empty)
2T7B4G4VSA5SMI47K61MV5BV1A22BOJR.EXAMPLE。NSEC3 1 1 12 AABBCCDD（2VPTU5TIMAMQTTGL4LUU9K21E0AOR3S A RRSIG）2T7B4G4VSA5SMI47K61MV5BV1A22BOJR.EXAMPLE。RRSIG NSEC3 7 2 3600（20150420235959 2005102100000040430例。OMBVJ1VGG1HCKMXHFINEIHK9XVW0ILDLWJN4TFONXZUP03GAXEI634YWOC4YBNITRJ413IQ NI6MRKW/r13IQ NI6MRKW/追加 ;;（空）
The query returned an NSEC3 RR that proves that the requested name exists ("ns1.example." hashes to "2t7b4g4vsa5smi47k61mv5bv1a22bojr"), but the requested RR type does not exist (type MX is absent in the type code list of the NSEC3 RR), and was not a CNAME (type CNAME is also absent in the type code list of the NSEC3 RR).
クエリは、要求された名前が存在することを証明するNSEC3 RRを返しました（ "ns1.example。"に "2t7b4g4g4vvsa5smi47k61mv5bv1a22bojr"にハッシュ）が、要求されたRRタイプは存在しません（タイプMXはNSEC3 RRのタイプに存在しません）、およびcnameではありませんでした（nsec3 rrのタイプコードリストにも型cnameがありません）。
A "no data" response because of an empty non-terminal. The NSEC3 RR proves that the name exists and that the requested RR type does not.
空の非ターミナルによる「データなし」応答。NSEC3 RRは、名前が存在し、要求されたRRタイプが存在しないことを証明しています。
;; Header: QR AA DO RCODE=0
;;
;; Question
y.w.example. IN A
;; Answer
;; (empty)
;; Authority example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 ( 40430 example. Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd VI2LmKusbZsT0Q== )
;;権限の例。soa ns1.example。bugs.x.w.example。1 3600 300（3600000 3600）の例。rrsig soa 7 1 3600 20150420235959 20051021000000（40430の例。Hu25uiynpmvpivbrldn9mlp9zql39qaud8i q4zllywfuubbas41pg 68z81q1xhkyaceyhd vi2lmkusbzst0qq =
;; NSEC3 RR matches the QNAME and shows that the A type bit is not set.
;;NSEC3 RRはQNameと一致し、A型ビットが設定されていないことを示しています。
ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd ( k8udemvp1j2f7eg6jebps17vp3n8i58h ) ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7 2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0 MpzVSKfTwx4uYA== )
ji6neoaepv8b5o6k4ev333abha8ht9fgc.example。NSEC3 1 1 12 AABBCCDD（K8UDEMVP1J2F7EG6JEBPS17VP3N8I58H）JI6NEOAEPV8B5O6K4EV3333ABHA8HT9FGC.EXAMPLE。RRSIG NSEC3 7 2 3600（20150420235959 20051021000000000040430例。GPKFP1S2QDQ6WQZCG1USEBZ61W33RUBDCTJ72F3KQ490FEDP7K1K1BUIFBCZTPBX3YCPE SITIT0 MPZVSKFSKFSKFSKFSKFSKFSKBSKFSKBSKFSKFCFX4UX4UXPES SITIT0 SITIT0 SITET0MECPETIT0
;; Additional
;; (empty)
The query returned an NSEC3 RR that proves that the requested name exists ("y.w.example." hashes to "ji6neoaepv8b5o6k4ev33abha8ht9fgc"), but the requested RR type does not exist (Type A is absent in the Type Bit Maps field of the NSEC3 RR). Note that, unlike an empty non-terminal proof using NSECs, this is identical to a No Data Error. This example is solely mentioned to be complete.
クエリは、要求された名前が存在することを証明するNSEC3 RRを返しました（ "y.w.example。" "hashes" hashes "hashes" ji6neoaepv8b5o6k4ev33abha8ht9fgc "）が、要求されたRRタイプは存在しません（タイプAはNSEC3 RRのタイプビットマップフィールドには存在しません））。NSECを使用した空の非末端証明とは異なり、これはデータなしエラーと同じであることに注意してください。この例は、完全であることのみが言及されています。
The NSEC3 RRs prove that nothing for this delegation was signed. There is no proof that the unsigned delegation exists.
NSEC3 RRSは、この代表団のために何も署名されていないことを証明しています。署名されていない代表団が存在するという証拠はありません。
;; Header: QR DO RCODE=0
;;
;; Question
mc.c.example. IN MX
;; Answer
;; (empty)
;; Authority c.example. NS ns1.c.example. NS ns2.c.example.
;;権限c.example。NS NS1.C.Example。NS NS2.C.Example。
;; NSEC3 RR that covers the "next closer" name (c.example)
;; H(c.example) = 4g6p9u5gvfshp30pqecj98b3maqbn1ck
35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) 35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ XtAIR3chwgW+SA== )
35MTHGPGCU1QG68FAB165KLNSNK3DPVL.example。NSEC3 1 1 12 AABBCCDD（B4UM86EGHHDS6NEA196SMVMLO4ORS995 NS DS RRSIG）35MTHGPGCU1QG68FAB165KLNSNK3DPVL.example。RRSIG NSEC3 7 2 3600（20150420235959 20051021000000000040430例。G6JPUUPDUAJKRLJUSN8GB4UAGAX0NXY9SHWQAYNZO8EUWHZ6HEIBLUTPGJ15EZLL6VHHQGZ XXTGGZ XTAIR3CHWWWWWWGWWWGWWGWWGWWW
;; NSEC3 RR that matches the closest encloser (example)
;; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG ) 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762 BOCXJZMnpuwhpA== )
0P9MHAVEQVM6T7VBL5LOP2U3T2RP3TOM.example。NSEC3 1 1 12 AABBCCDD（2T7B4G4VSA5SMI47K61MV5BV1A22BOJR MX DNSKEY NS SOA NSEC3PARAM RRSIG）RRSIG NSEC3 7 2 3600（20150420235959 20051021000000000040430例。OSGWSM26BCS DDL8B5QRWR/DEWHTCSKLWKL IBHYH6BLRXK9RC0BMJPWQ4MLIUW85H2Y762 BOCXJNNPUWHPUWWWWWW85H2Y762
;; Additional ns1.c.example. A 192.0.2.7 ns2.c.example. A 192.0.2.8
;;追加のns1.c.example。A 192.0.2.7 NS2.C.Example。192.0.2.8
The query returned a referral to the unsigned "c.example." zone. The response contains the closest provable encloser of "c.example" to be "example", since the hash of "c.example" ("4g6p9u5gvfshp30pqecj98b3maqbn1ck") is covered by the first NSEC3 RR and its Opt-Out bit is set.
クエリは、署名されていない「C.example」への紹介を返しました。ゾーン。応答には、「c.example」の最も近い証明可能なエンクローザーが「例」になります。「c.example」（「4g6p9u5gvfshpshpshp30pqecj98b3maqbn1ck "）のハッシュは最初のNSEC3 RRでカバーされ、オプトアウトビットが設定されています。
A query that was answered with a response containing a wildcard expansion. The label count in the RRSIG RRSet in the answer section indicates that a wildcard RRSet was expanded to produce this response, and the NSEC3 RR proves that no "next closer" name exists in the zone.
ワイルドカードの拡張を含む応答で回答されたクエリ。回答セクションのRRSIG RRSetのラベルカウントは、この応答を生成するためにワイルドカードRRSetが拡張されたことを示しており、NSEC3 RRはゾーンに「次の近い」名前が存在しないことを証明しています。
;; Header: QR AA DO RCODE=0
;;
;; Question
a.z.w.example. IN MX
;; Answer a.z.w.example. MX 1 ai.example. a.z.w.example. RRSIG MX 7 2 3600 20150420235959 20051021000000 ( 40430 example. CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb 9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM ivEBP6+4KS3ldA== )
;;回答a.z.w.example。MX 1 ai.example。a.z.w.example。RRSIG MX 7 2 3600 20150420235959 20051021000000（40430の例。Cikebjqwgqpwijvcxgczcsjktfynugtlbikb9fcbtrmooq4inowvudhcwsh/urx3lc4wrum
;; Authority example. NS ns1.example. example. NS ns2.example. example. RRSIG NS 7 1 3600 20150420235959 20051021000000 ( 40430 example. PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv CnMXjtz6SyObxA== )
;;権限の例。NS NS1.example。例。NS NS2.example。例。rrsig ns 7 1 3600 20150420235959 20051021000000（40430の例。pvogtmk1hhhestauhwdwc8ts 6c8qtqd4pqj qotdevgg ma ai4fwdehu3qhjylcq9tbd2vv cnmxjtz6syobxa
;; NSEC3 RR that covers the "next closer" name (z.w.example)
;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3 ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN NlkxWcLsIlMmUg== )
Q04JKCEVQVMU85R014C7DKBA38O0JI5R.EXAMPLE。NSEC3 1 1 12 AABBCCDD（R53BQ7CC2UVMUBFU5OCMM6PERS9TK9EN A RRSIG）Q04JKCEVQVMU85R014C7DKBA38O0JI5R.example。RRSIG NSEC3 7 2 3600（20150420235959 20051021000000000040430例。HV5I89B4FHJDATP09G4BBN0R1F845CAXPL3ZXLMKIMOPAYQLETMLEWWLFFIA7SDPSZN ZLN NLKCLCLSILMMUG = =
;; Additional
ai.example. A 192.0.2.9
ai.example. RRSIG A 7 2 3600 20150420235959 20051021000000 (
40430 example.
hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F
tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+
rznEn8sQ64UdqA== )
ai.example. AAAA 2001:db8:0:0:0:0:f00:baa9
ai.example. RRSIG AAAA 7 2 3600 20150420235959 20051021000000 (
40430 example.
LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W
uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG
cHueLuXkMjBArQ== )
The query returned an answer that was produced as a result of a wildcard expansion. The answer section contains a wildcard RRSet expanded as it would be in a traditional DNS response. The RRSIG Labels field value of 2 indicates that the answer is the result of a wildcard expansion, as the "a.z.w.example" name contains 4 labels. This also shows that "w.example" exists, so there is no need for an NSEC3 RR that matches the closest encloser.
クエリは、ワイルドカードの拡張の結果として生成された答えを返しました。回答セクションには、従来のDNS応答で拡張されたワイルドカードRRSetが含まれています。RRSIGラベル2のフィールド値は、「a.z.w.example」名には4つのラベルが含まれているため、答えがワイルドカードの拡張の結果であることを示します。これはまた、「w.example」が存在することを示しているため、最も近い封筒に一致するNSEC3 RRは必要ありません。
The NSEC3 RR proves that no closer match could have been used to answer this query.
NSEC3 RRは、このクエリに答えるために近い一致を使用できなかったことを証明しています。
A "no data" response for a name covered by a wildcard. The NSEC3 RRs prove that the matching wildcard name does not have any RRs of the requested type and that no closer match exists in the zone.
ワイルドカードでカバーされている名前の「データなし」応答。NSEC3 RRSは、一致するワイルドカード名に要求されたタイプのRRがなく、ゾーンに近い一致が存在しないことを証明しています。
;; Header: QR AA DO RCODE=0
;;
;; Question
a.z.w.example. IN AAAA
;; Answer
;; (empty)
;; Authority example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 ( 40430 example. Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd VI2LmKusbZsT0Q== )
;;権限の例。soa ns1.example。bugs.x.w.example。1 3600 300（3600000 3600）の例。rrsig soa 7 1 3600 20150420235959 20051021000000（40430の例。Hu25uiynpmvpivbrldn9mlp9zql39qaud8i q4zllywfuubbas41pg 68z81q1xhkyaceyhd vi2lmkusbzst0qq =
;; NSEC3 RR that matches the closest encloser (w.example)
;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd ( kohar7mbb8dc2ce8a9qvl8hon4k53uhi ) k8udemvp1j2f7eg6jebps17vp3n8i58h.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt Otx7w9WfcIg62A== )
k8udemvp1j2f7eg6jebps17vp3n8i58h.example。NSEC3 1 1 12 AABBCCDD（KOHAR7MBB8DC2CE8A9QVL8HON4K53UHI）K8UDEMVP1J2F7EG6JEBPS17VP3N8I58H.EXAMPLE。RRSIG NSEC3 7 2 3600（20150420235959 20051021000000000040430例。FTXGBVF0WF8IWKYO73ENAUVX03KLNPILBK S6QCCFTVTVTFH4YVZSEZQUJ27NHR7NHR7RUXJWDNMT TOTX7W9W9WCIG62A）
;; NSEC3 RR that covers the "next closer" name (z.w.example)
;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3 ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN NlkxWcLsIlMmUg== )
Q04JKCEVQVMU85R014C7DKBA38O0JI5R.EXAMPLE。NSEC3 1 1 12 AABBCCDD（R53BQ7CC2UVMUBFU5OCMM6PERS9TK9EN A RRSIG）Q04JKCEVQVMU85R014C7DKBA38O0JI5R.example。RRSIG NSEC3 7 2 3600（20150420235959 20051021000000000040430例。HV5I89B4FHJDATP09G4BBN0R1F845CAXPL3ZXLMKIMOPAYQLETMLEWWLFFIA7SDPSZN ZLN NLKCLCLSILMMUG = =
;; NSEC3 RR that matches a wildcard at the closest encloser.
;; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en
r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd ( t644ebqk9bibcna874givr6joj62mlhv MX RRSIG ) r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+ HF1FWKW7RIJdtQ== )
R53bq7cc2uvmubfu5ocmm6pers9tk9en.example。NSEC3 1 1 12 AABBCCDD（T644EBQK9BIBCNA874GIVR6JOJ62MLHV MX RRSIG）R53BQ7CC2UVMUBFU5OCMM6PERS9TK9EN.example。Rrsig nsec3 7 2 3600（20150420235959 2005102100000040430例。Aupviviruxs4bdg9rcbezbmf9h1zldvbw/c zfkuligxxlj8b/fsdjarxvda9bnuorhbkp hff1fw7ijdt）
;; Additional
;; (empty)
The query returned the NSEC3 RRs that prove that the requested data does not exist and no wildcard RR applies.
クエリは、要求されたデータが存在せず、ワイルドカードRRが適用されないことを証明するNSEC3 RRSを返しました。
A "no data" response for a QTYPE=DS query that was mistakenly sent to a name server for the child zone.
チャイルドゾーンの名前サーバーに誤って送信されたQTYPE = DSクエリの「データなし」応答。
;; Header: QR AA DO RCODE=0
;;
;; Question
example. IN DS
;; Answer
;; (empty)
;; Authority example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 ( 40430 example. Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd VI2LmKusbZsT0Q== )
;;権限の例。soa ns1.example。bugs.x.w.example。1 3600 300（3600000 3600）の例。rrsig soa 7 1 3600 20150420235959 20051021000000（40430の例。Hu25uiynpmvpivbrldn9mlp9zql39qaud8i q4zllywfuubbas41pg 68z81q1xhkyaceyhd vi2lmkusbzst0qq =
;; NSEC3 RR matches the QNAME and shows that the DS type bit is not set.
;;NSEC3 RRはQNameと一致し、DSタイプビットが設定されていないことを示しています。
0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG ) 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 40430 example. OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762 BOCXJZMnpuwhpA== )
0P9MHAVEQVM6T7VBL5LOP2U3T2RP3TOM.example。NSEC3 1 1 12 AABBCCDD（2T7B4G4VSA5SMI47K61MV5BV1A22BOJR MX DNSKEY NS SOA NSEC3PARAM RRSIG）RRSIG NSEC3 7 2 3600 20150420235959 200510210000000000430例。OSGWSM26B CS DDL8B5QRWR/DEWHTCSKLWKL IBHYH6BLRXK9RC0BMJPWQ4MLIUW85H2EY762 BOCXJZMNPUWHPA ==）
;; Additional
;; (empty)
The query returned an NSEC3 RR showing that the requested was answered by the server authoritative for the zone "example". The NSEC3 RR indicates the presence of an SOA RR, showing that this NSEC3 RR is from the apex of the child, not from the zone cut of the parent. Queries for the "example" DS RRSet should be sent to the parent servers (which are in this case the root servers).
クエリは、要求されたものがゾーン「例」に対して権威あるサーバーによって回答されたことを示すNSEC3 RRを返しました。NSEC3 RRは、SOA RRの存在を示しており、このNSEC3 RRが親のゾーンカットからではなく、子供の頂点からのものであることを示しています。「例」DS RRSetのクエリは、親サーバー（この場合はルートサーバー）に送信する必要があります。
The following paragraphs clarify specific behavior and explain special considerations for implementations.
次の段落では、特定の動作を明確にし、実装に関する特別な考慮事項を説明します。
Augmenting original owner names with salt before hashing increases the cost of a dictionary of pre-generated hash-values. For every bit of salt, the cost of a precomputed dictionary doubles (because there must be an entry for each word combined with each possible salt value). The NSEC3 RR can use a maximum of 2040 bits (255 octets) of salt, multiplying the cost by 2^2040. This means that an attacker must, in practice, recompute the dictionary each time the salt is changed.
ハッシュする前に元の所有者名を塩で増強すると、事前に生成されたハッシュ値の辞書のコストが増加します。塩分ごとに、事前計算された辞書のコストが2倍になります（各単語のエントリが可能な各塩値を組み合わせている必要があるため）。NSEC3 RRは、最大2040ビット（255オクテット）の塩を使用して、コストに2^2040を掛けることができます。つまり、攻撃者は、実際には、塩が変更されるたびに辞書を再計算する必要があることを意味します。
Including a salt, regardless of size, does not affect the cost of constructing NSEC3 RRs. It does increase the size of the NSEC3 RR.
サイズに関係なく、塩を含めることは、NSEC3 RRSの構築コストに影響しません。NSEC3 RRのサイズが増加します。
There MUST be at least one complete set of NSEC3 RRs for the zone using the same salt value.
同じ塩値を使用して、ゾーンにNSEC3 RRSの少なくとも1つの完全なセットが必要です。
The salt SHOULD be changed periodically to prevent pre-computation using a single salt. It is RECOMMENDED that the salt be changed for every re-signing.
塩は、単一の塩を使用した事前計算を防ぐために定期的に交換する必要があります。再署名ごとに塩を変更することをお勧めします。
Note that this could cause a resolver to see RRs with different salt values for the same zone. This is harmless, since each RR stands alone (that is, it denies the set of owner names whose hashes, using the salt in the NSEC3 RR, fall between the two hashes in the NSEC3 RR) -- it is only the server that needs a complete set of NSEC3 RRs with the same salt in order to be able to answer every possible query.
これにより、同じゾーンの塩値が異なるRRSがリゾルバーが表示される可能性があることに注意してください。これは無害です。各RRは単独で立っているためです（つまり、NSEC3RRの塩を使用して、NSEC3 RRの2つのハッシュの間にあるハッシュがハッシュする所有者名のセットを否定します） - 必要なのはサーバーだけですすべての可能なクエリに答えることができるように、同じ塩を備えたNSEC3 RRの完全なセット。
There is no prohibition with having NSEC3 RRs with different salts within the same zone. However, in order for authoritative servers to be able to consistently find covering NSEC3 RRs, the authoritative server MUST choose a single set of parameters (algorithm, salt, and iterations) to use when selecting NSEC3 RRs.
同じゾーン内に異なる塩を持つNSEC3 RRSを持つことは禁止されていません。ただし、権威あるサーバーがNSEC3 RRSをカバーすることが一貫して見つけることができるためには、権威あるサーバーは、NSEC3 RRを選択する際に使用する単一のパラメーター（アルゴリズム、塩、および反復）を選択する必要があります。
Hash collisions occur when different messages have the same hash value. The expected number of domain names needed to give a 1 in 2 chance of a single collision is about 2^(n/2) for a hash of length n bits (i.e., 2^80 for SHA-1). Though this probability is extremely low, the following paragraphs deal with avoiding collisions and assessing possible damage in the event of an attack using hash collisions.
異なるメッセージが同じハッシュ値を持っている場合、ハッシュ衝突が発生します。長さのnビットのハッシュ（つまり、SHA-1の場合は2^80）の場合、1回の衝突の2分の1のチャンスの1つに1つのチャンスを与えるために必要なドメイン名の数は約2^（n/2）です。この確率は非常に低いですが、次の段落では、ハッシュ衝突を使用して攻撃が発生した場合の衝突の回避と可能性のある損害の評価に対処しています。
During generation of NSEC3 RRs, hash values are supposedly unique. In the (academic) case of a collision occurring, an alternative salt MUST be chosen and all hash values MUST be regenerated.
NSEC3 RRSの生成中、ハッシュ値はおそらく一意です。発生する衝突の（アカデミックな）ケースでは、代替塩を選択する必要があり、すべてのハッシュ値を再生する必要があります。
A cryptographic hash function has a second-preimage resistance property. The second-preimage resistance property means that it is computationally infeasible to find another message with the same hash value as a given message, i.e., given preimage X, to find a second preimage X' != X such that hash(X) = hash(X'). The work factor for finding a second preimage is of the order of 2^160 for SHA-1. To mount an attack using an existing NSEC3 RR, an adversary needs to find a second preimage.
暗号化のハッシュ関数には、2番目のプリメージ抵抗特性があります。2番目のプレイマージ抵抗プロパティは、特定のメッセージと同じハッシュ値を持つ別のメッセージを見つけること、つまり、プリイメージxが与えられ、2番目のプリイメージx '！= xを見つけることが、ハッシュ（x）= hashを見つけることが計算可能に不可能であることを意味します。（バツ'）。2番目のプリイメージを見つけるための作業要因は、SHA-1の2^160のオーダーです。既存のNSEC3 RRを使用して攻撃を実施するには、敵が2回目の前想像を見つける必要があります。
Assuming an adversary is capable of mounting such an extreme attack, the actual damage is that a response message can be generated that claims that a certain QNAME (i.e., the second pre-image) does exist, while in reality QNAME does not exist (a false positive), which will either cause a security-aware resolver to re-query for the non-existent name, or to fail the initial query. Note that the adversary can't mount this attack on an existing name, but only on a name that the adversary can't choose and that does not yet exist.
敵がこのような極端な攻撃を増やすことができると仮定すると、実際の損害は、特定のQName（つまり、2番目の前イメージ）が存在すると主張する応答メッセージを生成できることですが、実際にはQNameは存在しません（FALSE陽性）、これにより、セキュリティ認識のリゾルバーが存在しない名前のために再クエリを引き起こすか、最初のクエリに失敗します。敵はこの攻撃を既存の名前にマウントすることはできませんが、敵が選択できず、まだ存在していない名前にのみ存在することに注意してください。
Authors' Addresses
著者のアドレス
Ben Laurie Nominet 17 Perryn Road London W3 7LR England
ベンローリーノミネット17ペリーロードロンドンW3 7LRイングランド
Phone: +44 20 8735 0686
EMail: ben@links.org
Geoffrey Sisson Nominet Minerva House Edmund Halley Road Oxford Science Park Oxford OX4 4DQ UNITED KINGDOM
ジェフリーシッソンノミネットミネルバハウスエドマンドハレーロードオックスフォードサイエンスパークオックスフォードオックス4dqイギリス
Phone: +44 1865 332211
EMail: geoff-s@panix.com
Roy Arends Nominet Minerva House Edmund Halley Road Oxford Science Park Oxford OX4 4DQ UNITED KINGDOM
ロイ・アレンズノミネット・ミネルバ・ハウス・エドマンド・ハレー・ロード・オックスフォード・サイエンス・パーク・オックスフォード・オックス44DQ英国
Phone: +44 1865 332211
EMail: roy@nominet.org.uk
David Blacka VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US
David Blacka Verisign、Inc。21355 Ridgetop Circle Dulles、VA 20166 US
Phone: +1 703 948 3200
EMail: davidb@verisign.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。