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
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 RRの使用は、これらの政策が執行不能でレンダリングします。
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例では、認知セキュリティ上の利点に比べて、高いことです。これらのケースでは、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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].
[RFC2136]、[RFC2181]：読者は[RFC1035]、[RFC4033]、[RFC4034]、[RFC4035]、およびそれらの更新以降のRFCs、[RFC1034]で説明した基本的な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].
ハッシュ順序：所有者名をハッシュする順序は、最も重要なオクテットとして左端（最も小さい番号の）オクテットを治療する、その数値に応じて配置されています。ハッシュされた所有者名をbase32で、拡張進アルファベット[RFC4648]で符号化された場合、この順序は、[RFC4034]で指定された正規のDNS名の順序と同じであることに留意されたいです。
Empty non-terminal: a domain name that owns no resource records, but has one or more subdomains that do.
空の非終端：なしリソースレコードを所有していないが、やる一個の以上のサブドメインを持つドメイン名。
Delegation: an NS RRSet with a name different from the current zone apex (non-zone-apex), signifying a delegation to a child zone.
委任：子ゾーンへの委任を意味する現在のゾーンの頂点（非ゾーン頂点）、異なる名前を持つNS資源レコード集合。
Secure delegation: a name containing a delegation (NS RRSet) and a signed DS RRSet, signifying a delegation to a signed child zone.
セキュア委任：委任を含む名前（NS資源レコード集合）と署名DS資源レコード集合、署名した子ゾーンへの委任を意味します。
Insecure delegation: a name containing a delegation (NS RRSet), but lacking a DS RRSet, signifying a delegation to an unsigned child zone.
安全でない委任：委任を含む名前（NS資源レコード集合）が、符号なしの子ゾーンへの委任を意味する、DS資源レコード集合を欠いています。
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.
オプトアウトゾーン：少なくとも一つのオプトアウトNSEC3 RRとのゾーン。
Closest encloser: the longest existing ancestor of a name. See also Section 3.3.1 of [RFC4592].
最も近いencloser：名前の最長の既存の祖先。また、[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.
次近づく名前：名前ラベル長い名前の最も近い証明可能なencloserより1。
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非対応レゾルバ）は、この文書で紹介した応答の検証に失敗することがあります。
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は、DSAアルゴリズム3の別名です。アルゴリズム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のRRのためにこれらのアルゴリズム識別子を使用しなければなりません。これらの新しい識別子は、既存の、NSEC3非対応リゾルバに、未知のアルゴリズムとなりますので、それらのリゾルバは、NSEC3からの応答を処理します[RFC4035]のセクション5.2で説明するように、安全でないとして、ゾーンに署名しました。
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から移行するための方法は、セクション10.4で説明されNSEC3を使用して署名されたゾーンをゾーンに署名しました。
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 RRの完全なセットは、RRの最初の所有者名に存在し、ゾーン内のハッシュ所有者名のチェーンを形成する資源レコード集合を示しています。この情報は、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.
符号なしの代表団のハッシュ所有者名がチェーンから除外することができます。そのスパン所有者名または符号なし委任の「次に、より近い」という名前のハッシュを覆うNSEC3 RRは、オプトアウトNSEC3 RRと呼ばれ、フラグの存在によって示されます。
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.
反復フィールドには、ハッシュ関数が実行された追加の回数を定義します。より多くの反復は、辞書攻撃に対するハッシュ値の大きい弾力性になりますが、サーバとリゾルバの両方のための高い計算コストで。このフィールドの使用の詳細については、第5章、および値の制限については、セクション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のオリジナル所有者名に存在する資源レコード集合の種類を識別する。
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:
フラグフィールドは単一オクテットであり、以下に示すように、オプトアウトフラグは、最下位ビットです。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |O|
+-+-+-+-+-+-+-+-+
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 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型空間は、それぞれが16ビットRR型空間の下位8ビットを表す、256個のウィンドウブロックに分割されます。有する各ブロック、少なくとも1つの活性RR型ウィンドウブロックのビットマップのために使用されるオクテットの数を示す（1から32まで）は、単一のオクテットのウィンドウ番号（0〜255）、単一のオクテットのビットマップの長さを使用して符号化され、ビットマップの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.
各ビットマップは、ネットワークビット順に、窓ブロック内のRR型の下位8ビットを符号化します。最初のビットは、ビット1は、RRタイプ1（A）に対応する、ウィンドウブロック0のビット0である2等RRタイプ2（NS）とに対応するビット。ウィンドウブロック1のために、1ビットが1に設定されている場合、それはそのタイプの資源レコード集合はNSEC3 RRのオリジナルの所有者名のために存在することを示すRRタイプ258にRRタイプ257、ビット2に対応するビット。ビットが0に設定されている場合、そのタイプのない資源レコード集合はNSEC3 RRのオリジナルの所有者名のために存在しないことを示します。
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のビット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ハッシュアルゴリズムフィールドは符号なしの10進整数として表されます。値が255の最大値を有します。
o The Flags field is represented as an unsigned decimal integer. The value has a maximum of 255.
Oフラグフィールドは符号なしの10進整数として表されます。値が255の最大値を有します。
o The Iterations field is represented as an unsigned decimal integer. The value is between 0 and 65535, inclusive.
O反復フィールドは符号なしの10進整数として表されます。値は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ソルトフィールドは、大文字と小文字を区別しない16進数のシーケンスとして表されます。空白はシーケンス内で許可されていません。 「 - 」ソルト長フィールドは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次にハッシュ所有者名フィールドは空白なしで、大文字と小文字を区別しないbase32桁パディングされていない配列として表されます。
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で説明したようにニーモニックは、TYPE表現を知られていない場合に使用しなければなりません。
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 RRの適切なセットを選択するために正式のサーバによって使用され得ることを示しています。 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.
ゼロ以外のFlagsフィールド値を持つNSEC3PARAM RRは無視しなければなりません。
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:
NSEC3PARAM 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 Algorithm is a single octet.
ハッシュアルゴリズムは、単一のオクテットです。
Flags field is a single octet.
Flagsフィールドは、単一のオクテットです。
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ハッシュアルゴリズムフィールドは符号なしの10進整数として表されます。値が255の最大値を有します。
o The Flags field is represented as an unsigned decimal integer. The value has a maximum value of 255.
Oフラグフィールドは符号なしの10進整数として表されます。値が255の最大値を有します。
o The Iterations field is represented as an unsigned decimal integer. The value is between 0 and 65535, inclusive.
O反復フィールドは符号なしの10進整数として表されます。値は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ソルトフィールドは、大文字と小文字を区別しない16進数のシーケンスとして表されます。空白はシーケンス内で許可されていません。 「 - 」ソルト長フィールドがゼロの場合（引用符なし）このフィールドは、次のように表されます。
The hash calculation uses three of the NSEC3 RDATA fields: Hash Algorithm, Salt, and Iterations.
ハッシュアルゴリズム、塩、および反復：ハッシュ計算はNSEC3 RDATAフィールドの3を使用しています。
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:
H（x）はNSEC3 RRによって選択されたハッシュアルゴリズムを使用して、xのハッシュであると定義し、kは反復の数である、とする||連結を示します。次に定義します。
IH(salt, x, 0) = H(x || salt), and
IH（塩、X、0）= H（X ||塩）、及び
IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0
IH（塩、X、K）= H（IH（塩、X、K-1）||塩）、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の資源レコード集合は署名されておらず、DS資源レコード集合を伴うことができます。オプトアウトビットをクリアすると、子ゾーンのセキュリティステータスは、暗号委任のハッシュされた所有者名で署名したNSEC3 RRによって証明され、このDS資源レコード集合の有無によって決定されます。オプトアウトフラグを設定すると、安全でない委任委任のハッシュ化された所有者名に対応する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 RRを他の、権威の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のRRと非オプトアウト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権威RRセットを所有しているゾーン内の各所有者名は、対応するNSEC3 RRを持たなければなりません。符号なしの代表団に対応して所有者名は、対応するNSEC3 RRを持っているかもしれません。対応するNSEC3 RRが存在しない場合は、委任に「次に、より近い」という名前をカバーオプトアウトNSEC3のRRがあるに違いありません。その他の非権威のRRはNSEC3のRRで表現されていません。
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.
空の非末端のみオプトアウトNSEC3 RRによって覆われ、安全でない委任から誘導されていない限り、O、各空の非端末は、対応する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 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は、タイプビットマップフィールド内の対応するビットを設定します。
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より大きい場合、追加のNSEC3 RRは頂点と元の所有者の名前との間の非端末毎に空のために添加される必要があります。このプロセスは、重複したハッシュ化された所有者名とNSEC3 RRを生成してもよいです。必要に応じて、衝突検出のために、これらのNSEC3 RRの元の所有者名を追跡し、ステップ1に同様の方法でワイルドカードの衝突のために一時的なNSEC3 RRを作成します。
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 RRの集合によって表される種類の組合からなるタイプビットマップフィールドを有する単一NSEC3のRRでそれらを置き換えることによって、同一のハッシュ化された所有者名でNSEC3 RRを組み合わせます。元の所有者名を追跡した場合組み合わせた場合、その後、衝突が一致するNSEC3 RRの全てが同一の元の所有者名を有していなければならないように、検出することができます。すべての可能な一時的なNSEC3のRRを破棄します。
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.
各NSEC3 RR 7.、ハッシュ順序で次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応答を修正します。特に、NSEC3のRRを持つような応答におけるNSEC RRの使用を置き換えます。
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 RRは、同じ事実を証明するNSEC3のRRに置き換えられます。 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 RRを含む応答を返すとき、NSEC3 RRの全てが同じハッシュアルゴリズム、反復、およびソルト値を使用しなければなりません。 Flagsフィールドの値が0または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応答の最も近いencloserの証明が必要です。これはQNAMEのいくつかの祖先がQNAMEの最も近いencloserであることを証明しています。
This proof consists of (up to) two different NSEC3 RRs:
この証明は、二つの異なるNSEC3のRRを（まで）で構成されています。
o An NSEC3 RR that matches the closest (provable) encloser.
最も近い（証明可能）エンクロージャに一致するNSEC3のRR O。
o An NSEC3 RR that covers the "next closer" name to the closest encloser.
最寄りのエンクロージャに「次に、より近い」という名前をカバーするNSEC3 RR O。
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は、本質的に可能な最も近いencloserを提案し、そして特定なencloserがないことを証明し、実際に、存在します。第NSEC3 RRが可能最も近いencloserが最も近い、およびQNAME（およびQNAMEと最も近いencloserの間の任意の先祖）が存在しないことを証明することを証明しています。
These NSEC3 RRs are collectively referred to as the "closest encloser proof" in the subsequent descriptions.
これらNSEC3のRRをまとめ以降の説明において、「最も近いencloser証拠」と呼ばれます。
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).
たとえば、存在しないため、最も近いencloser証拠「alpha.beta.gamma.example。」所有者名は、「gamma.example。」を証明するかもしれません最も近いencloserです。この応答は、「gamma.example」と一致するNSEC3 RRを含んでいるでしょうし、またカバーするNSEC3 RR含んでいるでしょう「beta.gamma.exampleを。」 （これは「次に、より近い」という名前です）。
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".
実際に最も近いencloserを立証することはできませんし、（第6節）オプトアウトを使用しているとき、それはある、またはオプトアウトスパンでカバー不安定な代表団の一部であるので、可能です。この場合には、代わりに実際に最も近いencloserを証明する、最も近い証明可能なencloserが使用されます。これは、最も近い囲み権威名が代わりに使用されています。この場合、NSEC3 RRのセットは、「最も近い証明可能なencloser証拠」と呼ばれるこの証明のために使用されます。
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の有無を証明するために、最も近いencloserで（存在しない）ワイルドカードRRを覆う証拠とNSEC3 RR最も近いencloserは、応答に含まれなければなりません。 3つのNSEC3 RRは両方ともその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、その後、NSEC3 RRのカバーに最も近い証明可能なencloserである「* .gamma.exampleが。」応答の権限セクションに含まれています。
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のために最も近い証明可能なencloser証拠を返さなければなりません。 「次に、より近い」という名前をカバーする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のための最も近いencloser証拠を含まなければならないし、ワイルドカードに一致するNSEC3 RRを含まなければなりません。この組み合わせは、QNAME自体が存在しないこととQNAMEに一致するワイルドカードが存在しないことの両方を証明しています。 QNAMEへの最も近いencloserは、ワイルドカード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のワイルドカード一致がある場合は、拡張ワイルドカードに加えて、資源レコード集合は、応答の解答セクションに返され、その後、ワイルドカード一致が有効であったという証拠は返却しなければなりません。
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とワイルドカードの即時の祖先の最も近いencloserが同じであること（すなわち、正しいワイルドカードが一致します）。
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を返さなければなりません。この最も近いencloserの存在が応答で拡大ワイルドカードの存在によって証明されるように、最も近いencloserに一致する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が存在しないことがあります。この場合、最も近い証明可能なencloser証拠は応答に含まれなければなりません。代表団のために、「次に、より近い」という名前をカバー含ま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資源レコード集合によって証明することができますので、これは、パラドックスです。
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いいえRRタイプがQNAMEに存在し、またQNAMEの任意の子孫で、
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のRRが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 RRの適切なセットを選択できるようにするために、確実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のRRの存在がある場合は、複数の有効な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.
ゾーンは、動的更新[RFC2136]を受け入れることができるNSEC3を使用して署名しました。しかし、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.
対応するNSEC3 RRと名前を削除する場合、O、その名前で作成された非端末を空に対応する任意のNSEC3のRRは除去されなければなりません。複数の名前は、特定の空の非末端の存在をアサートすることができることに留意されたいです。
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.
NSEC3 RRを追加する必要が名前を追加する場合、O、NSEC3 RRはまた、作成された空の非端末のために添加しなければなりません。空の非末端と一致する既存の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.
委任資源レコード集合を削除すると、その代表団は、一致するNSEC3 RRを持っていない場合は、O、それはオプトアウトされました。この場合、何もさらに行われる必要がありません。
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.
委任資源レコード集合を追加する場合、委任の「次に、より近い」という名前が既存のオプトアウトNSEC3 RRによって覆われている場合、O、次いで、委任は、ゾーン内のNSEC3 RRを変更せずに追加されるかもしれません。
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 RRを追加または削除するときに、新規または変更されたNSEC3のRRに設定されるべきであるオプトアウトフラグの値が曖昧であることを意味します。サーバーは、あいまいさを解決するための基本的なルールのこのセットに従ってください。
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.
NSEC3 RRを取り外すときは、O、前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.
NSEC3 RRを追加する場合、O、オプトアウトフラグの値が以前に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.
バリデータは、フィールドが0または1以外の値フラグでNSEC3 RRを無視しなければなりません。
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のRRを含まれている場合、バリデータは偽として応答を扱うかもしれ。
In order to verify a closest encloser proof, the validator MUST find the longest name, X, such that
最も近いencloser証拠を検証するために、バリデータは、このような最長の名前、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の先祖です。これは、最も近いencloserの候補である、と
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.
つのラベル長いXより名前O（それでもの祖先 - 又は等しい - QNAME）が応答したNSEC3 RRの存在によって覆われています。
One possible algorithm for verifying this proof is as follows:
次のようにこの証拠を検証するための一つの可能なアルゴリズムは次のとおりです。
* 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.
* If there is an NSEC3 RR in the response that covers SNAME, set the flag.
* NSEC3 RRはSNAMEを覆う応答がある場合は、フラグを設定します。
* 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は最も近いencloserです。
* If there is a matching NSEC3 RR in the response, but the flag is not set, then the response is bogus.
*が一致するNSEC3 RRが応答であるが、フラグがセットされていない場合、応答が偽である場合。
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.
最も近いencloserが発見されたら、バリデータは元の所有者名として最も近いencloserを持っている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最も近い（証明可能）なencloser証拠」とは、上記のアルゴリズム（または同等のアルゴリズム）は、XはXの祖先は、その最も近いencloserであることを証明では存在しないことを証明することを意味します。
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のための最も近いencloser証拠があることを確認しなければならず、最も近いencloserにワイルドカードを覆うNSEC3 RRが存在すること（すなわち、最も近いencloserにアスタリスクラベルを付加することによって形成される名前）。
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が空タイプビットマップフィールドを持っている場合には。
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が存在しない場合、バリデータはQNAME最も近い証明可能なencloser証拠が応答中に存在し、「次に、より近い」という名前をカバーする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のための最も近いencloser証拠を確かめなければなりませんし、最も近いencloserにアスタリスクラベルを付加することで生成されたワイルドカード名と一致応じて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.
検証ワイルドカードは対応して資源レコード集合に答えるQNAMEのための（候補）最も近いencloserでバリデータを提供します。この最も近いencloserは発生ワイルドカードへの直接の祖先です。
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資源レコード集合の所有者名です。
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の存在がある場合、バリデータは、NSビットが設定されていることを確認しなければならなくて、DSビットはNSEC3 RRのタイプビットマップのフィールドに設定されていないこと。バリデータはまた、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のType Bit Maps分野における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が存在しない場合は、バリデータは代表団名に最も近い証明可能なencloser証拠を確かめなければなりません。バリデータはオプトアウトビットは代表団名に「次に、より近い」という名前をカバーする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（S）の名前（複数可）を計算することができるようになります。実装はキャッシングとNSEC3 RRを取得するための新しい方法を使用する必要があります。
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.
「次に、より近い」という名前をカバーするNSEC3 RRがオプトアウトビットセットを有する、最も近い（証明可能）なencloser証拠を含む応答を返すときADビットは、[RFC4035]で定義されるように、設定してはいけません。
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でカバーされるだろう名前がまたはのように不安定な代表団を存在しない可能性があります。このルールは、この最も近いencloser証拠が実際に証明しているものに基づいています。そのため、そのような最も近いencloserの証明を含む応答ではなく、すべてのデータが暗号的に検証されていますので、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ビットのハッシュを生成します。 32文字で160ビットの結果のベース32符号化。 32の文字は単一オクテットの長さフィールドを含む単一のラベルとしてゾーンの名前の前に付加されています。 SHA-1を使用してゾーン名の最大長は、222個のオクテット（ - 33 255）です。
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仕様は、「無子孫」制限を有しています。 DNAME RRがノード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がゾーンの頂点である場合に、この仕様は、頂点に関係なくDNAMEの存在の頂点の子孫でNSEC3とRRSIG種類を許可するようにDNAME仕様を更新N.の子孫に存在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.
使用される反復回数を設定すると、ゾーンの所有者は、ハッシュを計算するコストを選択することができ、及び辞書の生成従ってコスト。これはすべての時間のための単一の予め計算された辞書の使用を防止する塩の効果とは異なることに留意されたいです。
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.
明らかに、反復回数も署名のゾーン所有者のコストに影響し、ゾーンからの応答を確認するのゾーンだけでなく、バリのコストを提供します。したがって、我々は、反復回数に上限を課します。私たちは、資源レコード集合の検証のコストを近似反復回数でこれをベースにします。
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.
ゾーン所有者は、特定のキーサイズの反復のために、以下の表に示されているよりも高い値を使用してはいけません。バリデータが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キーの検証のコスト（の比の近似に基づいています1から2500まで）。
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キーの1から1500まで）高くなっています。 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.
安全かつ確実ゾーンのDNSKEY資源レコード集合を変更するための実際の方法2セクションで説明されたアルゴリズム別名を使用DNSKEYsに全てDNSKEYs 1の遷移は、本明細書の範囲外です。しかし、最終的な結果は、親のすべてのDS用のRRは、指定されたアルゴリズムの別名を使用することでなければなりません。
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.
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のRRを追加します。インクリメンタルに追加する場合は、最後に追加した資源レコード集合はNSEC3PARAM資源レコード集合でなければなりません。
3. Upon the addition of the NSEC3PARAM RRSet, the server switches to serving negative and wildcard responses with NSEC3 RRs according to this specification.
この仕様によればNSEC3のRRを負とワイルドカード応答をサービングするNSEC3PARAM資源レコード集合、サーバスイッチを添加すると3。
To safely transition back to a DNSSEC [RFC4035] signed zone, simply reverse the procedure above:
安全バックDNSSEC [RFC4035]署名されたゾーンに移行するには、上記の手順を逆：
2. Remove the NSEC3PARAM RRSet. This will signal the server to use the NSEC RRs for negative and wildcard responses.
2. NSEC3PARAM資源レコード集合を削除します。これは否定的、そして、ワイルドカード応答のためのNSEC RRを使用するようにサーバーを通知します。
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.遷移DNSSECアルゴリズム識別子にDNSKEYsのすべて。この移行が完了すると、すべてのNSEC3非対応のクライアントは、セキュアとしてゾーンを扱います。
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で使用するための新しいハッシュアルゴリズムを指定する場合、遷移機構も定義されなければなりません。
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つの新しいタイプを定義することによって、サブレジストリ「TYPES」で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.
" - [RFC4035]あたりのDNSセキュリティアルゴリズム番号"（http://www.iana.org/assignments/dns-sec-alg-numbers）この文書は、IANAレジストリを更新します。セクション2は、NSEC3ハッシュアルゴリズムSHA1と組み合わせて、それぞれの既存の登録DSAとRSASHA1（7）（6）エイリアスDSA-NSEC3-SHA1を定義しRSASHA1-NSEC3-SHA1。
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のRR（すなわち、攻撃者がすべてのNSEC3 RRを取得し、その後、NSEC3のRRに見出されるハッシュと比較する、すべての可能性のドメイン名のハッシュを計算し、従ってゾーンを列挙）まだ辞書攻撃を受けやすいです。これらは、実質的にオリジナルのNSECのRRがあったであろう列挙するよりも高価であり、これは明らかに、より検出可能になるものの、いずれの場合には、このような攻撃はまた、すべての可能性が名前のクエリを実行することにより、ネームサーバ自体に対して直接使用することができます。このオフライン攻撃の費用は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 RRを生成し、検証するために使用されるので、暗号ハッシュ関数は、プリイメージ耐性秒であることを前提に依存していることに留意されたいです。
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の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 RRを含む応答を治療する必要があるため、ただ一つの存在が可能ダウングレード攻撃に攻撃を提供するゾーン内の高い反復値と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の少なくとも一つのゾーン内に存在する高反復値を使用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の一つ以上へのアクセスを持っています。 NSEC3のRR高い反復値は、典型的な応答で返されているが、攻撃者が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資源レコードであるが、これはまた、（ワイルドカード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タイプを追加することができることと機能的に同等であることに注意してください：攻撃者は、単にの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 RRを歩くことは、ゾーン内の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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、トムソン、S.、Rekhter、Y.、およびJ.バウンド、 "ドメインネームシステムにおける動的更新（DNS更新）"、RFC 2136、1997年4月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
"DNS仕様の明確化" [RFC2181]エルツ、R.とR.ブッシュ、RFC 2181、1997年7月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308]アンドリュース、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]イーストレーク、D.、ブルンナー - ウィリアムズ、E.、およびB.マニング、 "ドメインネームシステム（DNS）IANAの考慮事項"、BCP 42、RFC 2929、2000年9月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597]グスタフソン、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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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]ローリー、B.、 "DNSSEC NSEC2所有者とRDATAフォーマット"、進歩、2004年12月に作業。
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[RFC2672]クロフォード、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]アトキンス、D.とR. Austeinと、RFC 3833 "ドメインネームシステム（DNS）の脅威分析"、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]アレンズ、R.、Kosters、M.、およびD. Blacka、 "DNSセキュリティ（DNSSEC）オプトイン"、RFC 4956、2007年7月。
Appendix A. Example Zone
付録A.例ゾーン
This is a zone showing its NSEC3 RRs. They can also be used as test vectors for the hash algorithm.
これは、そのNSEC3 RRを示すゾーンです。彼らはまた、ハッシュアルゴリズムのためのテストベクトルとして使用することができます。
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.
ゾーンは、元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= )
; H（例えば）= 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例。 SOAのns1.example 3600。 bugs.x.w.example。 3600 300（3600000 3600）1 RRSIG SOA 7 1 3600 20150420235959 20051021000000（40430例。Hu25UIyNPmvPIVBrldN + 9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG + 68z81q1xhkYAcEyHd VI2LmKusbZsT0Q ==）NS ns1.example。 NSのns2.example。 RRSIG NS 7 1 3600 20150420235959 20051021000000（40430例。PVOgtMK1HHeSTau + HwDWC8Ts + 6C8qtqd4pQJ qOtdEVgg + MA + ai4fWDEhu3qHJyLcQ9tbD2vv CnMXjtz6SyObxA ==）MX 1 xx.example。 RRSIG MX 7 1 3600 20150420235959 20051021000000（40430例。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（j7IommWSpJABVfW8Q0rOvXdM6kzt + TAu92L9 AbsUdblMFin8CVF3n4s =）RRSIG DNSKEY 7 1 3600 20150420235959（20051021000000 12708例。AuU4juU9RaxescSmStrQks3Gh9FblGBlVU31 uzMZ / U / FpsUb8aC6QZS + sTsJXnLnz7flGOsm MGQZf3bH + QsCtg ==）NSEC3PARAM 1 0 12 AABBCCDD RRSIG NSEC3PARAM 7 1 3600 20150420235959 （20051021000000 40430例。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例。OSgWSm26B + CS、dDL8b5QrWr / dEWhtCsKlwKL IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762 BOCXJZMnpuwhpA ==）2t7b4g4vsa5smi47k61mv5bv1a22bojr.example。 192.0.2.127 RRSIG A 7 2 3600 20150420235959 20051021000000（40430例。h6c ++ bzhRuWWt2bykN6mjaTNBcXNq5UuL5Ed K + iDP4eY8I0kSiKaCjg3tC1SQkeloMeub2GW k8p6xHMPZumXlwの==）NSEC3 1 1 12 AABBCCDD（RRSIGを2vptu5timamqttgl4luu9kg21e0aor3s）RRSIG NSEC3 7 2 3600 20150420235959 20051021000000（40430例。OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN 4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq NI6mRk / r1dOSUw ==）2vptu5timamqttgl4luu9kg21e0aor3s.example。 NSEC3 1 1 12 AABBCCDD（35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG）RRSIG NSEC3 7 2 3600 20150420235959 20051021000000（40430例。KL1V2oFYghNV0Hm7Tf2vpJjM6l + 0g1JCcVYG VfI0lKrhPmTsOA96cLEACgo1x8I7kApJX + OB TuktZ + sdsZPY1w ==）35mthgpgcu1qg68fab165klnsnk3dpvl.example。 NSEC3 1 1 12 AABBCCDD（NS DS RRSIG b4um86eghhds6nea196smvmlo4ors995）
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例。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例。XacFcQVHLVzdoc45EJhN616zQ4mEXtE8FzUh M2KWjfy1VfRKD9r1MeVGwwoukOKgJxBPFsWo o722vZ4UZ2dIdA ==）ns1.a.example。 192.0.2.5のns2.a.example。 192.0.2.6のai.example。 192.0.2.9 RRSIG A 7 2 3600 20150420235959 20051021000000（40430例。HVE + wKYMlObTRPhX0NL67GxeZfdxqr / QeR6F tfdAj5 + FgYxyzPEjIzvKWy00hWIl6wD3Vws + rznEn8sQ64UdqA ==）HINFO "KLH-10"、 "ITS" RRSIG HINFO 7 2 3600 20150420235959 20051021000000（40430例。Yi42uOq43eyO6qXHNvwwfFnIustWgV5urFcx enkLvs6pKRh00VBjODmf3Z4nMO7IOl6nHSQ1 v0wLHpEZG7Xj2w ==）AAAA 2001：DB8：0：0：0：0：F00：baa9 RRSIGのAAAA 7 2 3600 20150420235959 20051021000000（40430例LcdxKaCB5bGZwPDg + 3JJ4O02zoMBrjxqlf6W uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG cHueLuXkMjBArQ ==）b4um86eghhds6nea196smvmlo4ors995.example。 NSEC3 1 1 12 AABBCCDD（gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG）RRSIG NSEC3 7 2 3600 20150420235959 20051021000000（40430例。ZkPG3M32lmoHM6pa3D6gZFGB / RHL // Bs3Omh 5u4m / CUiwtblEVOaAKKZd7S959OeiX43aLX3 pOv0TSTyiTxIZg ==）c.example。 NSのns1.c.example。 NSのns2.c.example。 ns1.c.example。 192.0.2.7のns2.c.example。 192.0.2.8のgjeqe526plbf1g8mklp59enfd789njgi.example。 NSEC3 1 1 12 AABBCCDD（ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A 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 20051021000000（40430例。IVnezTJ9iqblFF97vPSmfXZ5Zozngx3KX3by LTZC4QBH2dFWhf6scrGFZB980AfCxoD9qbbKのDy + rdGIeRSVNyw ==）ji6neoaepv8b5o6k4ev33abha8ht9fgc.example。 NSEC3 1 1 12 AABBCCDD（k8udemvp1j2f7eg6jebps17vp3n8i58h）RRSIG NSEC3 7 2 3600 20150420235959 20051021000000（40430例。gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7 2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE + sIt0 MpzVSKfTwx4uYA ==）k8udemvp1j2f7eg6jebps17vp3n8i58h.example。 NSEC3 1 1 12 AABBCCDD（kohar7mbb8dc2ce8a9qvl8hon4k53uhi）RRSIG NSEC3 7 2 3600 20150420235959 20051021000000（40430例。FtXGbvF0 + wf8iWkyo73enAuVx03klN + pILBK S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt Otx7w9WfcIg62A ==）kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example。 NSEC3 1 1 12 AABBCCDD（q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG）RRSIG NSEC3 7 2 3600 20150420235959 20051021000000（40430例。VrDXs2uVW21N08SyQIz88zml + y4ZCInTwgDr 6zz43yAg + LFERjOrj3Ojct51ac7Dp4eZbf9F QJazmASFKGxGXg ==）ns1.example。 192.0.2.1 RRSIG A 7 2 3600 20150420235959 20051021000000（40430例。bu6kx73n6XEunoVGuRfAgY7EF / AJqHy7hj0j kiqJjB0dOrx3wuz9SaBeGfqWIdn / uta3SavN 4FRvZR9SCFHF5Q ==）ns2.example。 192.0.2.2 RRSIG A 7 2 3600 20150420235959 20051021000000（40430例。ktQ3TqE0CfRfki0Rb / Ip5BM0VnxelbuejCC4 zpLbFKA / 7eD7UNAwxMgxJPtbdST + syjYSJaj 4IHfeX6n8vfoGA ==）q04jkcevqvmu85r014c7dkba38o0ji5r.example。 NSEC3 1 1 12 AABBCCDD（r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG）RRSIG NSEC3 7 2 3600 20150420235959 20051021000000（40430例。hV5I89b + 4FHJDATp09g4bbN0R1F845CaXpL3 ZxlMKimoPAyqletMlEWwLfFia7sdpSzn + ZLN NlkxWcLsIlMmUg ==）
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
r53bq7cc2uvmubfu5ocmm6pers9tk9en.example。 NSEC3 1 1 12 AABBCCDD（MX RRSIG t644ebqk9bibcna874givr6joj62mlhv）RRSIG NSEC3 7 2 3600 20150420235959 20051021000000（40430例。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例。RAjGECB8P7O + F4Pa4Dx3tC0M + Z3KmlLKImca fb9XWwx + NWUNz7NBEDBQHivIyKPVDkChcePI X1xPl1ATNa + 8Dw ==）* .w.example。 MX 1 ai.example。 RRSIG MX 7 2 3600 20150420235959 20051021000000（40430例。CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb 9FcBTrmOoyQ4InoWVudhCWsh / URX3lc4WRUM ivEBP6 + 4KS3ldA ==）x.w.example。 MX 1 xx.example。 RRSIG MX 7 3 3600 20150420235959 20051021000000（40430例。IrK3tq / tHFIBF0scHiE / 1IwMAvckS / 55hAVv QyxTFbkAdDloP3NbZzu + yoSsr3b3OX6qbBpY 7WCtwwekLKRAwQ ==）x.y.w.example。 MX 1 xx.example。 RRSIG MX 7 4 3600 20150420235959 20051021000000（40430例。MqSt5HqJIN8 + SLlzTOImrh5h9Xa6gDvAW / GnをnbdPc6Z7nXvCpLPJj / 5lCwx3VuzVOjkbvXze 8 / 8Ccl2Zn2hbug ==）xx.example。 192.0.2.10 RRSIG A 7 2 3600 20150420235959 20051021000000（40430例。T35hBWEZ017VC5u2c4OriKyVn / PU + fVK4AlX YOxJ6iQylfV2HQIKjv6b7DzINB3aF / wjJqgX pQvhq + AC6 + ZiFg ==）HINFO "KLH-10" "TOPS-20" RRSIG HINFO 7 2 3600 20150420235959 20051021000000（ 。40430例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== )
Appendix B. Example Responses
付録B.例応答
The examples in this section show response messages using the signed zone example in Appendix A.
付録Aの署名されたゾーンの例を使用して、このセクションを示す応答メッセージの例
B.1. Name Error
B.1。名エラー
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 RRは名前が存在しないことを証明し、拡張されていなければならないワイルドカードRRが存在しないこと。
;; Header: QR AA DO RCODE=3 ;; ;; Question a.c.x.w.example. IN A
;;ヘッダー：QR AA DO RCODE = 3 ;; ;;質問a.c.x.w.example。 A、IN
;; 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例。Hu25UIyNPmvPIVBrldN + 9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG + 68z81q1xhkYAcEyHd VI2LmKusbZsT0Q ==）
;; NSEC3 RR that covers the "next closer" name (c.x.w.example) ;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh
;; 「次に、より近い」名（c.x.w.example）をカバーするNSEC3 RR ;; 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）0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example。 RRSIG NSEC3 7 2 3600（20150420235959 20051021000000 40430例。OSgWSm26B + CS、dDL8b5QrWr / dEWhtCsKlwKL IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762 BOCXJZMnpuwhpA ==）
;; NSEC3 RR that matches the closest encloser (x.w.example) ;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
;;最も近いencloser（x.w.example）に一致するNSEC3 RR ;; 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）b4um86eghhds6nea196smvmlo4ors995.example。 RRSIG NSEC3 7 2 3600（20150420235959 20051021000000 40430例。ZkPG3M32lmoHM6pa3D6gZFGB / RHL // Bs3Omh 5u4m / CUiwtblEVOaAKKZd7S959OeiX43aLX3 pOv0TSTyiTxIZg ==）
;; NSEC3 RR that covers wildcard at the closest encloser (*.x.w.example) ;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m
;;最も近いencloser（* .x.w.example）にワイルドカードをカバーするNSEC3 RR ;; 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 20051021000000 40430例。g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ Aynzo8EUWH + z6hEIBlUTPGj15eZll6VhQqgZ XtAIR3chwgW + SA ==）
;; 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 RRを返されました。否定応答がNSEC3 RRを検証することによって認証されます。対応RRSIGsはNSEC3のRRアルゴリズム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 RRの所有者名の一つは、最も近いencloserに一致します。 NSEC3 RRの一つは、もはや名が存在しないことを証明します。 NSEC3 RRの一つは、拡張されているはず何のワイルドカードRRセットが存在しないことを証明します。最も近いencloserは、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.
上記の例では、名「x.w.exampleは」「b4um86eghhds6nea196smvmlo4ors995」にハッシュします。これは、これは最も近いencloserであるかもしれないことを示しています。 「c.x.w.example」と「* .x.w.example」が存在しないことを証明するために、これらの名前は、それぞれ、「0va5bpr2ou0vk0lbqeeljri88laipsfh」と「92pqneegtaue7pjatc3l3qnk738c6v5m」にハッシュ化されています。最初と最後のNSEC3 RRはこれらのハッシュされた所有者名が存在しないことを証明します。
B.2. No Data Error
B.2。いいえデータエラーません
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
;;ヘッダー：QR AA DO RCODE = 0 ;; ;;質問ns1.example。 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例。Hu25UIyNPmvPIVBrldN + 9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG + 68z81q1xhkYAcEyHd VI2LmKusbZsT0Q ==）
;; 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は2t7b4g4vsa5smi47k61mv5bv1a22bojr.example（RRSIGを2vptu5timamqttgl4luu9kg21e0aor3s）。 RRSIG NSEC3 7 2 3600（20150420235959 20051021000000 40430例。OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN 4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq NI6mRk / r1dOSUw ==）;;追加;; （空の）
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」を「2t7b4g4vsa5smi47k61mv5bv1a22bojr」にハッシュ）（タイプMXはNSEC3 RRのタイプコードリストに存在しない）が、要求されたRR型が存在しません、およびCNAME（タイプCNAMEもNSEC3 RRのタイプコードリストに存在しない）されませんでした。
B.2.1. No Data Error, Empty Non-Terminal
B.2.1。いいえデータエラーません、空非ターミナル
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
;;ヘッダー：QR AA DO RCODE = 0 ;; ;;質問y.w.example。 A、IN
;; 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例。Hu25UIyNPmvPIVBrldN + 9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG + 68z81q1xhkYAcEyHd VI2LmKusbZsT0Q ==）
;; NSEC3 RR matches the QNAME and shows that the A type bit is not set.
;; NSEC3 RRは、QNAMEに一致し、タイプビットが設定されていないことを示しています。
ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd ( k8udemvp1j2f7eg6jebps17vp3n8i58h ) ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7 2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0 MpzVSKfTwx4uYA== )
ji6neoaepv8b5o6k4ev33abha8ht9fgc.example。 NSEC3 1 1 12 AABBCCDD（k8udemvp1j2f7eg6jebps17vp3n8i58h）ji6neoaepv8b5o6k4ev33abha8ht9fgc.example。 RRSIG NSEC3 7 2 3600（20150420235959 20051021000000 40430例。gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7 2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE + sIt0 MpzVSKfTwx4uYA ==）
;; 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返された（「ywexampleを。」「ji6neoaepv8b5o6k4ev33abha8ht9fgc」にハッシュ）（タイプAはNSEC3 RRのタイプビットマップのフィールドに存在しない）が、要求されたRRタイプが存在しません。 。 NSECSを使用して、空の非終端証拠とは異なり、これはデータなしのエラーと同じである、ということに注意してください。この例では、単に完全であると述べています。
B.3. Referral to an Opt-Out Unsigned Zone
B.3。オプトアウト未署名のゾーンへの紹介
The NSEC3 RRs prove that nothing for this delegation was signed. There is no proof that the unsigned delegation exists.
NSEC3 RRは、この代表団のために何も署名しなかったことを証明します。未署名の代表団が存在するという証拠はありません。
;; Header: QR DO RCODE=0 ;; ;; Question mc.c.example. IN MX
;;ヘッダー：QR DO RCODE = 0 ;; ;;質問mc.c.example。 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
;; 「次に、より近い」名（c.example）をカバーするNSEC3 RR ;; 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 20051021000000 40430例。g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ Aynzo8EUWH + z6hEIBlUTPGj15eZll6VhQqgZ XtAIR3chwgW + SA ==）
;; NSEC3 RR that matches the closest encloser (example) ;; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
;;最も近いencloser（例）に一致するNSEC3のRR ;; H（例えば）= 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）0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example。 RRSIG NSEC3 7 2 3600（20150420235959 20051021000000 40430例。OSgWSm26B + CS、dDL8b5QrWr / dEWhtCsKlwKL IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762 BOCXJZMnpuwhpA ==）
;; Additional ns1.c.example. A 192.0.2.7 ns2.c.example. A 192.0.2.8
;;追加ns1.c.example。 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」（「4g6p9u5gvfshp30pqecj98b3maqbn1ck」）のハッシュは、第一NSEC3のRRによって覆われ、そのオプトアウトビットが設定されているので、応答は、「一例」と「c.example」の最も近い証明可能なencloserを含有します。
B.4. Wildcard Expansion
B.4。ワイルドカードの展開
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資源レコード集合のラベルカウントはワイルドカード資源レコード集合はこの応答を生成するために拡張されたことを示し、およびNSEC3 RRには、「次に、より近い」という名前がゾーンに存在しないことを証明しています。
;; Header: QR AA DO RCODE=0 ;; ;; Question a.z.w.example. IN MX
;;ヘッダー：QR AA DO RCODE = 0 ;; ;;質問a.z.w.example。 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例。CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb 9FcBTrmOoyQ4InoWVudhCWsh / URX3lc4WRUM ivEBP6 + 4KS3ldA ==）
;; 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例。PVOgtMK1HHeSTau + HwDWC8Ts + 6C8qtqd4pQJ qOtdEVgg + MA + ai4fWDEhu3qHJyLcQ9tbD2vv CnMXjtz6SyObxA ==）
;; NSEC3 RR that covers the "next closer" name (z.w.example) ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
;; 「次に、より近い」名（z.w.example）をカバーするNSEC3 RR ;; 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 20051021000000 40430例。hV5I89b + 4FHJDATp09g4bbN0R1F845CaXpL3 ZxlMKimoPAyqletMlEWwLfFia7sdpSzn + ZLN NlkxWcLsIlMmUg ==）
;; 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== )
;;追加ai.example。 192.0.2.9のai.example。 RRSIG A 7 2 3600 20150420235959 20051021000000（40430例。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例。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応答になるよう資源レコード集合が展開ワイルドカードが含まれています。 2のRRSIGラベルフィールドの値が「a.z.w.example」名前が4つのラベルを含むよう答えは、ワイルドカード拡張の結果であることを示しています。これはまた、「w.example」が存在することを示しているので、最も近いencloserに一致するNSEC3のRRのための必要はありません。
The NSEC3 RR proves that no closer match could have been used to answer this query.
NSEC3 RRにはより近いマッチがこのクエリに応答するために使用されていない可能性があることを証明しています。
B.5. Wildcard No Data Error
B.5。ワイルドカードデータなしエラー
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のRRは一致するワイルドカードの名前は、要求されたタイプのいずれかのRRを持っているし、何より近いマッチがゾーンに存在しないことをしないことを証明します。
;; Header: QR AA DO RCODE=0 ;; ;; Question a.z.w.example. IN AAAA
;;ヘッダー：QR AA DO RCODE = 0 ;; ;;質問a.z.w.example。 AAAA、IN
;; 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例。Hu25UIyNPmvPIVBrldN + 9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG + 68z81q1xhkYAcEyHd VI2LmKusbZsT0Q ==）
;; NSEC3 RR that matches the closest encloser (w.example) ;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
;;最寄りのエンクロージャ（with.example）に一致するNSEC3 RR ;; H（w.example）= k8ud mvp1j2f7eg6je ps17vp3n8i58h
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 20051021000000 40430例。FtXGbvF0 + wf8iWkyo73enAuVx03klN + pILBK S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt Otx7w9WfcIg62A ==）
;; NSEC3 RR that covers the "next closer" name (z.w.example) ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
;; 「次に、より近い」名（z.w.example）をカバーするNSEC3 RR ;; 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 20051021000000 40430例。hV5I89b + 4FHJDATp09g4bbN0R1F845CaXpL3 ZxlMKimoPAyqletMlEWwLfFia7sdpSzn + ZLN NlkxWcLsIlMmUg ==）
;; NSEC3 RR that matches a wildcard at the closest encloser. ;; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en
;;最も近いencloserにワイルドカードに一致するNSEC3のRR。 ;; 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 20051021000000 40430例。aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW / C ZFKulIGXXLj8B / fsDJarXVDA9bnUoRhEbKp + HF1FWKW7RIJdtQ ==）
;; Additional ;; (empty)
;;追加;; （空の）
The query returned the NSEC3 RRs that prove that the requested data does not exist and no wildcard RR applies.
クエリは、要求されたデータが存在しないことを証明するNSEC3のRRを返され、ワイルドカードRRは適用されません。
B.6. DS Child Zone No Data Error
B.6。 DSチャイルドゾーンデータなしエラー
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
;;ヘッダー：QR AA DO RCODE = 0 ;; ;;質問の例。 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例。Hu25UIyNPmvPIVBrldN + 9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG + 68z81q1xhkYAcEyHd VI2LmKusbZsT0Q ==）
;; 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）0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example。 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 40430例。 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は、このNSEC3 RRが子供の頂点からではなく、親のゾーンカットからのものであることを示す、SOA RRの存在を示します。 「例」DS資源レコード集合のためのクエリは、（この場合はルートサーバにある）親サーバーに送信する必要があります。
Appendix C. Special Considerations
付録C.特記事項
The following paragraphs clarify specific behavior and explain special considerations for implementations.
次の段落では、特定の動作を明確にし、実装のための特別な考慮事項について説明します。
C.1. Salting
C.1。塩田
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.
ハッシュ前に塩と元の所有者名を増強することは、予め生成されたハッシュ値の辞書のコストを増大させます。 （それぞれの可能なソルト値と組み合わせて、各ワードのためのエントリが存在しなければならないので）塩のビット毎に、予め計算された辞書のコストが倍になります。 NSEC3 RRは2 ^ 2040年コストを掛ける、塩の2040ビット（255オクテット）の最大値を使用することができます。これにより、攻撃者は、実際には、辞書に塩が変更されるたびに再計算しなければならないことを意味します。
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 RRを構築するコストに影響を与えることはありません。これはNSEC3 RRのサイズを増加しません。
There MUST be at least one complete set of NSEC3 RRs for the zone using the same salt value.
同じsalt値を使用してゾーンのNSEC3 RRの少なくとも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.
これは、同じゾーンの異なる塩値でRRを参照するには、リゾルバを引き起こす可能性があることに注意してください。各RRは、単独で（すなわち、それはNSEC3 RR中の塩を使用して、ハッシュ所有者名のセットを拒否し、ある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 RRを持つ一切禁止はありません。しかし、権威サーバは一貫しNSEC3 RRを覆って見つけることができるようにするためには、権限のあるサーバーはNSEC3 RRを選択する際に使用するパラメータ（アルゴリズム、塩、および反復回数）のセットを1つ選択する必要があります。
C.2. Hash Collision
C.2。ハッシュ衝突
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.
異なるメッセージが同じハッシュ値を持つとき、ハッシュ衝突が起こります。単一衝突の1 2にチャンスを与えるために必要なドメイン名の予想される数は約2 ^（N / 2）の長さnビットのハッシュのために（すなわち、SHA-1の2 ^ 80）。この確率は非常に低いですが、次の段落では、衝突を回避し、ハッシュ衝突を利用した攻撃が発生した場合に損傷を評価するに対処します。
C.2.1. Avoiding Hash Collisions During Generation
C.2.1。生成中にハッシュ衝突の回避
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 RRの生成中に、ハッシュ値は、おそらくユニークです。発生する衝突（アカデミック）場合に、別の塩を選択する必要があり、全てのハッシュ値を再生しなければなりません。
C.2.2. Second Preimage Requirement Analysis
C.2.2。第二のプリイメージ要求分析
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.
暗号ハッシュ関数は第二プレイメージ抵抗性を有します。第二プリイメージ抵抗性は、第二プレイメージX「を見つけるために、プレイメージのX与えられ、すなわち、所与のメッセージ、同じハッシュ値を持つ別のメッセージを見つけることが計算上実行不可能であることを意味する！= Xようにハッシュ（X）=ハッシュ（バツ'）。第二プレイメージを見つけるための作業係数はSHA-1のための2 ^ 160のオーダーです。既存のNSEC3 RRを使って攻撃をマウントするには、敵は、第二プレイメージを見つける必要があります。
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に存在しない状態応答メッセージは、特定のQNAME（すなわち、第2プリ画像）が存在しないと主張し、その生成され得ることである（A存在しない名前のために再クエリにセキュリティ対応リゾルバの原因となるか、最初のクエリに失敗した、）偽陽性。敵対者が既存の名前ではなく、唯一の敵が選択することはできませんし、それがまだ存在しない名前で、この攻撃を仕掛けることができないことに注意してください。
Authors' Addresses
著者のアドレス
Ben Laurie Nominet 17 Perryn Road London W3 7LR England
ベン・ローリーNominet 17ペリーロードロンドンW3イングランド7LR
Phone: +44 20 8735 0686 EMail: ben@links.org
電話：+44 20 8735 0686 Eメール：ben@links.org
Geoffrey Sisson Nominet Minerva House Edmund Halley Road Oxford Science Park Oxford OX4 4DQ UNITED KINGDOM
ジェフリー・シッソンNominetミネルヴァハウスエドモンド・ハレーロードオックスフォードサイエンスパークオックスフォードOX4 4DQ UNITED KINGDOM
Phone: +44 1865 332211 EMail: geoff-s@panix.com
電話：+44 1865 332211 Eメール：geoff-s@panix.com
Roy Arends Nominet Minerva House Edmund Halley Road Oxford Science Park Oxford OX4 4DQ UNITED KINGDOM
ロイ・アレンズNominetミネルヴァハウスエドモンド・ハレーロードオックスフォードサイエンスパークオックスフォードOX4 4DQ UNITED KINGDOM
Phone: +44 1865 332211 EMail: roy@nominet.org.uk
電話：+44 1865 332211 Eメール：roy@nominet.org.uk
David Blacka VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US
デビッドBlackaベリサイン社21355 Ridgetopサークルダレス、VA 20166米国
Phone: +1 703 948 3200 EMail: davidb@verisign.com
電話：+1 703 948 3200 Eメール：davidb@verisign.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。