RFC5155 日本語訳
5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence.B. Laurie, G. Sisson, R. Arends, D. Blacka. March 2008. (Format: TXT=112338 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Laurie
Request for Comments: 5155 G. Sisson
Category: Standards Track R. Arends
Nominet
D. Blacka
VeriSign, Inc.
March 2008
コメントを求めるワーキンググループB.ローリー要求をネットワークでつないでください: 5155年のG.シスンカテゴリ: 2008年の標準化過程R.Arends Nominet D.BlackaベリサインのInc.行進
DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
セキュリティ(DNSSEC)が論じ尽くしたDNSは存在の否定を認証しました。
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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.
ドメインネームシステムSecurity(DNSSEC)拡張子は存在の認証された否定のためのNSECリソース記録(RR)を紹介しました。 このドキュメントは代替のリソース記録、NSEC3を導入します。(同様に、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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1。 原理. . . . . . . . . . . . . . . . . . . . . . . . 4 1.2。 要件. . . . . . . . . . . . . . . . . . . . . . . 4 1.3。 用語. . . . . . . . . . . . . . . . . . . . . . . 5 2。 遅れている互換性. . . . . . . . . . . . . . . . . . . 6 3。 NSEC3リソース記録. . . . . . . . . . . . . . . . . . 7 3.1。 RDATA分野. . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1。 アルゴリズム. . . . . . . . . . . . . . . . . . . . 8 3.1.2を論じ尽くしてください。 .83.1に.3に旗を揚げさせます。 繰り返し. . . . . . . . . . . . . . . . . . . . . . 8 3.1.4。 長さ. . . . . . . . . . . . . . . . . . . . . 8 3.1の.5に塩味を付けさせてください。 塩. . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1の.6。 長さ. . . . . . . . . . . . . . . . . . . . . 9 3.1の.7を論じ尽くしてください。 次の論じ尽くされた所有者名. . . . . . . . . . . . . . . . 9 3.1の.8。 ビットマップ. . . . . . . . . . . . . . . . . . . . 9 3.2をタイプしてください。 NSEC3 RDATAは形式. . . . . . . . . . . . . . . . . 9 3.2.1を配線します。 .103.3をコード化するビットマップをタイプしてください。 プレゼンテーション形式. . . . . . . . . . . . . . . . . . . 11
Laurie, et al. Standards Track [Page 1] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[1ページ]RFC5155NSEC3 March 2008
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
4. NSEC3PARAMリソース記録. . . . . . . . . . . . . . . . 12 4.1。 RDATA分野. . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1。 アルゴリズム. . . . . . . . . . . . . . . . . . . . 12 4.1.2を論じ尽くしてください。 分野. . . . . . . . . . . . . . . . . . . . . 12 4.1.3に旗を揚げさせてください。 繰り返し. . . . . . . . . . . . . . . . . . . . . . 13 4.1.4。 長さ. . . . . . . . . . . . . . . . . . . . . 13 4.1の.5に塩味を付けさせてください。 .134.2に塩味を付けさせてください。 NSEC3PARAM RDATAは形式. . . . . . . . . . . . . . . 13 4.3を配線します。 プレゼンテーション形式. . . . . . . . . . . . . . . . . . . 14 5。 細切れ肉料理. . . . . . . . . . . . . . . . . . . 14 6の計算。 .157を抜けさせてください。 正式のサーバ問題. . . . . . . . . . . . . 16 7.1。 ゾーン調印. . . . . . . . . . . . . . . . . . . . . . . 16 7.2。 ゾーンの給仕. . . . . . . . . . . . . . . . . . . . . . . 17 7.2.1。 最も近いEncloser証拠. . . . . . . . . . . . . . . . 18 7.2.2。 誤り応答. . . . . . . . . . . . . . . . . 19 7.2を.3と命名してください。 Data Responsesでなく、QTYPEはDS. . . . . . . . . . 19 7.2.4ではありません。 Data Responsesでなく、QTYPEはDS. . . . . . . . . . . . 19 7.2.5です。 ワイルドカードいいえデータ応答. . . . . . . . . . . . . . 19 7.2.6。 ワイルドカード答え応答. . . . . . . . . . . . . . 20 7.2.7。 無記名のSubzones. . . . . . . . . . . . 20 7.2.8への紹介。 .9にNSEC3所有者名. . . . . 20 7.2のための質問に応じます。 ランタイム衝突. . . . . . . 21 7.3へのサーバ応答。 セカンダリサーバ. . . . . . . . . . . . . . . . . . . . 21 7.4。 未知を使用するゾーンがアルゴリズム. . . . . . . . . . . 21 7.5を論じ尽くします。 ダイナミック・アップデート. . . . . . . . . . . . . . . . . . . . . . 21 8。 Validator問題. . . . . . . . . . . . . . . . . . . 23 8.1。 未知との応答はタイプ. . . . . . . . . . . . 23 8.2を論じ尽くします。 NSEC3 RRs. . . . . . . . . . . . . . . . . . . 23 8.3について確かめます。 最も近いEncloser証拠. . . . . . . . . . . . . . . . . . 23 8.4。 名前誤り応答. . . . . . . . . . . . . 24 8.5を有効にします。 Data Responsesを全く有効にしないで、QTYPEはDS. . . . . . 24 8.6ではありません。 Data Responsesを全く有効にしないで、QTYPEはDS. . . . . . . . 24 8.7です。 ワイルドカードいいえデータ応答. . . . . . . . . . 25 8.8を有効にします。 ワイルドカード答え応答. . . . . . . . . . . 25 8.9を有効にします。 紹介を無記名のSubzones. . . . . . . . 25 9に有効にします。 レゾルバ問題. . . . . . . . . . . . . . . . . . . 26 9.1。 NSEC3リソース記録キャッシュ. . . . . . . . . . . . . . 26 9.2。 ADの使用は.26 10に噛み付きました。 特別な問題. . . . . . . . . . . . . . . . . . . . 26 10.1。 ドメイン名長さの制限. . . . . . . . . . . . . 26 10.2。 ゾーンの頂点. . . . . . . . . . . . . . . . . . 27 10.3のDNAME。 繰り返し. . . . . . . . . . . . . . . . . . . . . . . . 27 10.4。 移行しているaはnsecからNSEC3. . . . . . 28 10.5までゾーンにサインしました。 移行しているaはNSEC3からnsec. . . . . . 28 11までゾーンにサインしました。 IANA問題. . . . . . . . . . . . . . . . . . . . . 29 12。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 30 12.1。 問題. . . . . . . . . . . . . . . . . . 30を論じ尽くします。
Laurie, et al. Standards Track [Page 2] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[2ページ]RFC5155NSEC3 March 2008
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
12.1.1. 辞書攻撃. . . . . . . . . . . . . . . . . . 30 12.1.2。 衝突. . . . . . . . . . . . . . . . . . . . . . 31 12.1.3。 新しい細切れ肉料理アルゴリズム. . . . . . . . 31 12.1.4に移行します。 高い繰り返し値. . . . . . . . . . . . . 31 12.2を使用します。 問題. . . . . . . . . . . . . . . . . . 32 12.3を抜けさせてください。 他の問題. . . . . . . . . . . . . . . . . . . 33 13。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 33 13.1。 引用規格. . . . . . . . . . . . . . . . . . . 33 13.2。 有益な参照. . . . . . . . . . . . . . . . . . 34付録A..35の例のゾーン付録B.例の応答. . . . . . . . . . . . . . . . . . 40B.1。 誤り. . . . . . . . . . . . . . . . . . . . . . . . 40をB.2と命名してください。 いいえ、データ誤り. . . . . . . . . . . . . . . . . . . . . . 42B.2.1。 データ誤りがない、空の非端末.43B.3。 外で選ぶことの無記名のゾーン.44B.4への紹介。 ワイルドカード拡大. . . . . . . . . . . . . . . . . . . . 45B.5。 ワイルドカードいいえデータ誤り. . . . . . . . . . . . . . . . . . 46B.6。 DS子供ゾーンいいえデータ誤り. . . . . . . . . . . . . . . 48の付録のC.の特別な問題. . . . . . . . . . . . . . . 48C.1。 .49C.2に塩味を付けさせます。 衝突. . . . . . . . . . . . . . . . . . . . . . 49C.2.1を論じ尽くしてください。 世代. . . . . . 50C.2.2の間、細切れ肉料理衝突を避けます。 2番目のPreimage要件分析. . . . . . . . . 50
Laurie, et al. Standards Track [Page 3] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[3ページ]RFC5155NSEC3 March 2008
1. Introduction
1. 序論
1.1. Rationale
1.1. 原理
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 Security Extensionsは、存在の認証された否定を提供するために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.
列挙されたゾーンを使用できます、例えば、そんなに多くの登録には、スパムのためのありえそうなEメールアドレスの源として、または、複数のWHOIS質問が記入者データを明らかにするキーとして保護する法律上の義務があるかもしれません。 したがって、多くの登録がそれらのゾーンデータのコピーを禁止します。 しかしながら、NSEC RRsの使用はこれらの方針を「非-実施でき」に表します。
A second problem is that the cost to cryptographically secure delegations to unsigned zones is high, relative to the perceived security benefit, in two cases: large, delegation-centric zones, and zones where insecure delegations will be updated rapidly. In these cases, the costs of maintaining the NSEC RR chain may be extremely high and use of the "Opt-Out" convention may be more appropriate (for these unsecured zones).
2番目の問題は暗号で無記名のゾーンに代表団を安全にする費用が高いということです、知覚されたセキュリティ利益に比例して、2つの場合で: 大きくて、代表団中心のゾーン、および不安定な代表団が急速にアップデートされるゾーン。 これらの場合では、NSEC RRチェーンが非常に高いかもしれないと主張するコストと「外では、選び」コンベンションの使用は、より適切であるかもしれません(これらがゾーンを非安全にしたので)。
This document presents the NSEC3 Resource Record which can be used as an alternative to NSEC to mitigate these issues.
このドキュメントはNSECに代わる手段としてこれらの問題を緩和するのに使用できるNSEC3 Resource Recordを寄贈します。
Earlier work to address these issues include [DNSEXT-NO], [RFC4956], and [DNSEXT-NSEC2v2].
より早く、[DNSEXT-いいえ]、[RFC4956]、および[DNSEXT-NSEC2v2]はこれらの問題が含むアドレスに取り組みます。
1.2. Requirements
1.2. 要件
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Laurie, et al. Standards Track [Page 4] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[4ページ]RFC5155NSEC3 March 2008
1.3. Terminology
1.3. 用語
The reader is assumed to be familiar with the basic DNS and DNSSEC concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], [RFC4035], and subsequent RFCs that update them: [RFC2136], [RFC2181], and [RFC2308].
読者が概念が[RFC1034]、[RFC1035]、[RFC4033]、[RFC4034]、[RFC4035]、および彼らをアップデートするその後のRFCsで説明した基本的なDNSとDNSSECによく知られさせると思われます: [RFC2136]、[RFC2181]、および[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にあるとき[RFC4034]で指定された正準なDNS名がExtended Hex Alphabetと共に[RFC4648]をコード化したので、このオーダーが同じであることに注意してください。
Empty non-terminal: a domain name that owns no resource records, but
has one or more subdomains that do.
非端末を空にしてください: リソースを全く所有していないドメイン名は、そうする1つ以上のサブドメインを、記録しますが、持っています。
Delegation: an NS RRSet with a name different from the current zone
apex (non-zone-apex), signifying a delegation to a child zone.
代表団: 代表団を意味する現在のゾーンの頂点(非ゾーンの頂点)から子供ゾーンまで異なった名前があるNS RRSet。
Secure delegation: a name containing a delegation (NS RRSet) and a
signed DS RRSet, signifying a delegation to a signed child zone.
代表団を安全にしてください: サインされた子供ゾーンに代表団を意味して、代表団(NS RRSet)とサインされたDS RRSetを含む名前。
Insecure delegation: a name containing a delegation (NS RRSet), but
lacking a DS RRSet, signifying a delegation to an unsigned child
zone.
不安定な代表団: 代表団(NS RRSet)を含みますが、無記名の子供ゾーンに代表団を意味して、DS RRSetを欠いている名前。
Opt-Out NSEC3 resource record: an NSEC3 resource record that has the
Opt-Out flag set to 1.
NSEC3リソース記録を抜けさせてください: 外のOpt旗を持っているNSEC3リソース記録は1にセットしました。
Opt-Out zone: a zone with at least one Opt-Out NSEC3 RR.
ゾーンを抜けさせてください: 少なくとも1外のOpt NSEC3 RRがあるゾーン。
Closest encloser: the longest existing ancestor of a name. See also
Section 3.3.1 of [RFC4592].
最も近いencloser: 名前の最も長い既存の先祖。 また、.1セクション3.3[RFC4592]を見てください。
Laurie, et al. Standards Track [Page 5] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[5ページ]RFC5155NSEC3 March 2008
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.
最も近い証明可能なencloser: 存在すると立証できる名前の最も長い先祖。 これが外のOptゾーンで最も近いencloserと異なるだけであることに注意してください。
Next closer name: the name one label longer than the closest
provable encloser of a name.
次の、より近い名前: 名前1は名前の最も近くより長い証明可能なencloserをラベルします。
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)の間に落ちるなら、NSEC3 RRは名前を「覆う」と言われます。 言い換えれば直接か名前の先祖の非実在を立証することによって名前の非実在を立証するなら。
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は名前を「合わせる」と言われます。
2. Backwards Compatibility
2. 遅れている互換性
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アルゴリズム識別子を割り当てます。 DSA、アルゴリズム6、DSA-NSEC3-SHA1はアルゴリズム3のための別名です。 RSASHA1、アルゴリズム7、RSASHA1-NSEC3-SHA1はアルゴリズム5のための別名です。 これらが新しいアルゴリズムでない、それらは既存のアルゴリズムのための追加識別子です。
Zones signed according to this specification MUST only use these algorithm identifiers for their DNSKEY RRs. Because these new identifiers will be unknown algorithms to existing, NSEC3-unaware resolvers, those resolvers will then treat responses from the NSEC3 signed zone as insecure, as detailed in Section 5.2 of [RFC4035].
この仕様通りにサインされたゾーンはそれらのDNSKEY RRsにこれらのアルゴリズム識別子を使用するだけでよいです。 これらの新しい識別子が存在することへの未知のアルゴリズムになるので、NSEC3からの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を見てください)。
Laurie, et al. Standards Track [Page 6] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[6ページ]RFC5155NSEC3 March 2008
Security aware resolvers that are aware of this specification MUST recognize the new algorithm identifiers and treat them as equivalent to the algorithms that they alias.
この仕様を意識しているセキュリティ意識しているレゾルバが新しいアルゴリズム識別子を認めて、アルゴリズムと同等物としてそれらを扱わなければならない、それ、それら、別名。
A methodology for transitioning from a DNSSEC signed zone to a zone signed using NSEC3 is discussed in Section 10.4.
DNSSECから移行するのがNSEC3を使用することでサインされたゾーンにゾーンにサインしたので、セクション10.4で方法論について議論します。
3. The NSEC3 Resource Record
3. NSEC3リソース記録
The NSEC3 Resource Record (RR) provides authenticated denial of existence for DNS Resource Record Sets.
NSEC3 Resource Record(RR)は存在の認証された否定をDNS Resource Record Setsに供給します。
The NSEC3 RR lists RR types present at the original owner name of the NSEC3 RR. It includes the next hashed owner name in the hash order of the zone. The complete set of NSEC3 RRs in a zone indicates which RRSets exist for the original owner name of the RR and form a chain of hashed owner names in the zone. This information is used to provide authenticated denial of existence for DNS data. To provide protection against zone enumeration, the owner names used in the NSEC3 RR are cryptographic hashes of the original owner name prepended as a single label to the name of the zone. The NSEC3 RR indicates which hash function is used to construct the hash, which salt is used, and how many iterations of the hash function are performed over the original owner name. The hashing technique is described fully in Section 5.
NSEC3 RRは最初の所有者名(NSEC3 RR)で出席しているRRタイプを記載します。 それはゾーンの細切れ肉料理注文に次の論じ尽くされた所有者名を含んでいます。 ゾーンのNSEC3 RRsの完全なセットは、どのRRSetsが最初の所有者名(RR)のために存在していて、ゾーンで論じ尽くされた所有者名のチェーンを形成するかを示します。 この情報は、存在の認証された否定をDNSデータに提供するのに使用されます。 ゾーン列挙に対する保護を提供するために、NSEC3 RRで使用される所有者名は暗号です。単一のラベルとしてゾーンの名前にprependedされた名前を最初の所有者に論じ尽くします。 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が所有者名の細切れ肉料理を覆っているか、「次に、より近いところでは、」無記名の代表団の名前は、外のOpt 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のための所有者名は単一のラベルとしてゾーンの名前にprependedされた論じ尽くされた所有者名の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 SHOULDには、SOAの最小のTTL分野と同じTTL値があります。 否定的キャッシュ[RFC2308]の精神にはこれがあります。
Laurie, et al. Standards Track [Page 7] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[7ページ]RFC5155NSEC3 March 2008
3.1. RDATA Fields
3.1. RDATA分野
3.1.1. Hash Algorithm
3.1.1. 細切れ肉料理アルゴリズム
The Hash Algorithm field identifies the cryptographic hash algorithm used to construct the hash-value.
Hash Algorithm分野はハッシュ値を構成するのに使用される暗号の細切れ肉料理アルゴリズムを特定します。
The values for this field are defined in the NSEC3 hash algorithm registry defined in Section 11.
この分野への値はセクション11で定義されたNSEC3細切れ肉料理アルゴリズム登録で定義されます。
3.1.2. Flags
3.1.2. 旗
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.
Flags分野は異なった処理を示すのに使用できる8個の1ビットの旗を含んでいます。 すべての未定義の旗がゼロであるに違いありません。 この仕様で定義された唯一の旗が外のOpt旗です。
3.1.2.1. Opt-Out Flag
3.1.2.1. 外で選び旗
If the Opt-Out flag is set, the NSEC3 record covers zero or more unsigned delegations.
外のOpt旗が設定されるなら、NSEC3記録はゼロか、より無記名の代表団をカバーします。
If the Opt-Out flag is clear, the NSEC3 record covers zero unsigned delegations.
外のOpt旗が明確であるなら、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.
外のOpt Flagは、このNSEC3 RRが無記名の代表団を覆うかもしれないかどうかを示します。 それはFlags分野の最下位ビットです。 この旗の使用に関する詳細に関してセクション6を見てください。
3.1.3. Iterations
3.1.3. 繰り返し
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.
Iterations分野はハッシュ関数が実行されたという追加回の数を定義します。 より多くの繰り返しは、辞書攻撃に対するハッシュ値の、よりすばらしい弾性となりますが、サーバとレゾルバの両方には、より高いコンピュータの費用でなります。値でこの分野の使用の詳細のためのセクション5、および制限のためのセクション10.3を見てください。
3.1.4. Salt Length
3.1.4. 塩の長さ
The Salt Length field defines the length of the Salt field in octets, ranging in value from 0 to 255.
0〜255まで値のねらいを定めて、Salt Length分野は八重奏における、Salt分野の長さを定義します。
3.1.5. Salt
3.1.5. 塩
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.
論じ尽くす前にあらかじめ計算された辞書攻撃に対して防御するためにSalt野原を最初の所有者名に追加します。 塩がどう使用されているかに関する詳細に関してセクション5を見てください。
Laurie, et al. Standards Track [Page 8] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[8ページ]RFC5155NSEC3 March 2008
3.1.6. Hash Length
3.1.6. 細切れ肉料理の長さ
The Hash Length field defines the length of the Next Hashed Owner Name field, ranging in value from 1 to 255 octets.
Hash Length分野はNext Hashed Owner Name分野の長さを定義します、1〜255八重奏から値のねらいを定めて。
3.1.7. Next Hashed Owner Name
3.1.7. 次の論じ尽くされた所有者名
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.
Next Hashed Owner Name分野は細切れ肉料理オーダーにおける次の論じ尽くされた所有者名を含んでいます。 バイナリフォーマットにはこの値があります。 すべての論じ尽くされた所有者名の順序集合を考えて、Next Hashed Owner Name分野はすぐに所有者名(与えられたNSEC3 RR)に従う所有者名の細切れ肉料理を含んでいます。 ゾーンにおける最後のNSEC3 RRのNext Hashed Owner Name分野の値は論じ尽くされた所有者名(細切れ肉料理オーダーにおけるゾーンにおける最初のNSEC3 RR)と同じです。 この分野の値が所有者名(NSEC3 RR)と異なって追加されたゾーン名を含まないことに注意してください。
3.1.8. Type Bit Maps
3.1.8. ビットマップをタイプしてください。
The Type Bit Maps field identifies the RRSet types that exist at the original owner name of the NSEC3 RR.
Type Bit Maps分野は最初の所有者名(NSEC3 RR)で存在するRRSetタイプを特定します。
3.2. NSEC3 RDATA Wire Format
3.2. NSEC3 RDATAワイヤ形式
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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algを論じ尽くしてください。 | 旗| 繰り返し| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 塩の長さ| 塩/+++++++++++++++++++++++++++++++++| 細切れ肉料理の長さ| 次..論じ尽くす..所有者..名前..タイプ..ビットマップ
Hash Algorithm is a single octet.
細切れ肉料理Algorithmはただ一つの八重奏です。
Flags field is a single octet, the Opt-Out flag is the least significant bit, as shown below:
旗の分野がただ一つの八重奏である、外のOpt旗は以下に示されるように最下位ビットです:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |O|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | |O| +-+-+-+-+-+-+-+-+
Laurie, et al. Standards Track [Page 9] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[9ページ]RFC5155NSEC3 March 2008
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.
塩のLengthは無記名の八重奏として表されます。 塩のLengthは八重奏における、Salt分野の長さを表します。 値がゼロであるなら、以下のSalt分野は省略されます。
Salt, if present, is encoded as a sequence of binary octets. The length of this field is determined by the preceding Salt Length field.
存在しているなら、塩は2進の八重奏の系列としてコード化されます。 この分野の長さは前のSalt Length分野のそばで決定しています。
Hash Length is represented as an unsigned octet. Hash Length represents the length of the Next Hashed Owner Name field in octets.
細切れ肉料理Lengthは無記名の八重奏として表されます。 細切れ肉料理Lengthは八重奏における、Next Hashed Owner Name分野の長さを表します。
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ではありません。 それは変更されていない2進のハッシュ値です。 それは含んでいるゾーンの名前を含んでいません。 この分野の長さは前のHash Length分野のそばで決定しています。
3.2.1. Type Bit Maps Encoding
3.2.1. ビットマップコード化をタイプしてください。
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.
Type Bit Maps分野のコード化は[RFC4034]で説明されたNSEC RRによって使用されたそれと同じです。 それは、明快ためにここで説明されて、はっきりさせられます。
The RR type space is split into 256 window blocks, each representing the low-order 8 bits of the 16-bit RR type space. Each block that has at least one active RR type is encoded using a single octet window number (from 0 to 255), a single octet bitmap length (from 1 to 32) indicating the number of octets used for the bitmap of the window block, and up to 32 octets (256 bits) of bitmap.
RRタイプスペースは256ウィンドウブロックに分けられます、それぞれ16ビットのRRタイプスペースの下位の8ビットを表して。 少なくとも1アクティブなRRがタイプする各ブロックは、ビットマップのただ一つの八重奏窓の番号(0〜255までの)、ウィンドウブロックのビットマップに使用される八重奏の数を示すただ一つの八重奏ビットマップの長さ(1〜32までの)、および最大32の八重奏(256ビット)を使用することでコード化されます。
Blocks are present in the NSEC3 RR RDATA in increasing numerical order.
ブロックは増加する番号のNSEC3 RR RDATAに存在しています。
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
ビットマップがさばくタイプは+と等しいです(ウィンドウブロック#| ビットマップの長さ| ビットマップ)。
where "|" denotes concatenation.
「どこ」|「連結を指示します。」
Each bitmap encodes the low-order 8 bits of RR types within the window block, in network bit order. The first bit is bit 0. For window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS), and so forth. For window block 1, bit 1 corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to 1, it indicates that an RRSet of that type is present for the original owner name of the NSEC3 RR. If a bit is set to 0, it indicates that no RRSet of that type is present for the original owner name of the NSEC3 RR.
各ビットマップはネットワークビットオーダーにおけるウィンドウブロックの中でRRタイプの下位の8ビットをコード化します。 最初のビットはビット0です。 ウィンドウブロック0に関しては、ビット1はRRタイプ1(A)に対応している、ビット2はRRタイプ2(NS)などに文通されます。 ウィンドウブロック1に関しては、ビット1はRRタイプ257に文通されて、RRへのビット2は258をタイプします。 しばらくが1に決められるなら、それは、そのタイプのRRSetが最初の所有者名(NSEC3 RR)のために存在しているのを示します。 しばらくが0に決められるなら、それは、そのタイプのどんなRRSetも最初の所有者名(NSEC3 RR)のために存在していないのを示します。
Laurie, et al. Standards Track [Page 10] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[10ページ]RFC5155NSEC3 March 2008
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にそれを設定しなければなりません。 検証の後に、validatorはウィンドウブロック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とMeta-TYPEsだけへの課題のために予約された範囲の中で指定されているとしてMeta-TYPEsか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タイプのセットの中で。 どんな八重奏としても八重奏が指定しなかった引きずることを解釈してはいけません。
3.3. Presentation Format
3.3. プレゼンテーション形式
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 Hash Algorithm分野は無記名の10進整数として表されます。 値には、最大255があります。
o The Flags field is represented as an unsigned decimal integer.
The value has a maximum of 255.
o Flags分野は無記名の10進整数として表されます。 値には、最大255があります。
o The Iterations field is represented as an unsigned decimal
integer. The value is between 0 and 65535, inclusive.
o Iterations分野は無記名の10進整数として表されます。 値が0と65535の間あります。包括的。
o The Salt Length field is not represented.
o Salt Length分野は表されません。
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 Salt分野は大文字と小文字を区別しない16進数字の系列として表されます。 空白は系列の中に許容されていません。 塩の長さの分野に0の値があると、Salt分野は「-」(引用文のない)として表されます。
o The Hash Length field is not represented.
o Hash Length分野は表されません。
o The Next Hashed Owner Name field is represented as an unpadded
sequence of case-insensitive base32 digits, without whitespace.
o Next Hashed Owner Name分野は大文字と小文字を区別しない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 Type Bit Maps分野はRRタイプニーモニックの系列として表されます。 ニーモニックが知られていないとき、[RFC3597]のセクション5で説明されるTYPE表現を使用しなければなりません。
Laurie, et al. Standards Track [Page 11] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[11ページ]RFC5155NSEC3 March 2008
4. The NSEC3PARAM Resource Record
4. NSEC3PARAMリソース記録
The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm, flags, iterations, and salt) needed by authoritative servers to calculate hashed owner names. The presence of an NSEC3PARAM RR at a zone apex indicates that the specified parameters may be used by authoritative servers to choose an appropriate set of NSEC3 RRs for negative responses. The NSEC3PARAM RR is not used by validators or resolvers.
NSEC3PARAM RRはパラメタ(細切れ肉料理アルゴリズム、旗、繰り返し、および塩)が正式のサーバで論じ尽くされた所有者名について計算する必要があったNSEC3を含んでいます。 ゾーンの頂点のNSEC3PARAM RRの存在は指定されたパラメタが正式のサーバによって使用されて、否定応答のためのNSEC3 RRsの適切なセットを選ぶかもしれないのを示します。 NSEC3PARAM RRはvalidatorsかレゾルバによって使用されません。
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がゾーンの頂点にゼロのFlags分野価値について存在しているなら、あらゆる論じ尽くされた所有者名における現在の同じ細切れ肉料理アルゴリズム、繰り返し、および塩のパラメタを使用するNSEC3 RRがゾーンにあるに違いありません。 すなわち、ゾーンは同じ細切れ肉料理アルゴリズム、繰り返し、および塩のパラメタがあるNSEC3 RRsの完全なセットを含まなければなりません。
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 RRsと同じであるに違いありません。
4.1. RDATA Fields
4.1. RDATA分野
The RDATA for this RR mirrors the first four fields in the NSEC3 RR.
このRRのためのRDATAはNSEC3 RRの最初の4つの野原を映します。
4.1.1. Hash Algorithm
4.1.1. 細切れ肉料理アルゴリズム
The Hash Algorithm field identifies the cryptographic hash algorithm used to construct the hash-value.
Hash Algorithm分野はハッシュ値を構成するのに使用される暗号の細切れ肉料理アルゴリズムを特定します。
The acceptable values are the same as the corresponding field in the NSEC3 RR.
許容値はNSEC3 RRの対応する分野と同じです。
4.1.2. Flag Fields
4.1.2. 旗の分野
The Opt-Out flag is not used and is set to zero.
外のOpt旗は、使用されていなくて、ゼロに設定されます。
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 RRsを無視しなければなりません。
Laurie, et al. Standards Track [Page 12] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[12ページ]RFC5155NSEC3 March 2008
4.1.3. Iterations
4.1.3. 繰り返し
The Iterations field defines the number of additional times the hash is performed.
Iterations分野は細切れ肉料理が実行されるという追加回の数を定義します。
Its acceptable values are the same as the corresponding field in the NSEC3 RR.
許容値はNSEC3 RRの対応する分野と同じです。
4.1.4. Salt Length
4.1.4. 塩の長さ
The Salt Length field defines the length of the salt in octets, ranging in value from 0 to 255.
0〜255まで値のねらいを定めて、Salt Length分野は八重奏で塩の長さを定義します。
4.1.5. Salt
4.1.5. 塩
The Salt field is appended to the original owner name before hashing.
論じ尽くす前にSalt野原を最初の所有者名に追加します。
4.2. NSEC3PARAM RDATA Wire Format
4.2. NSEC3PARAM RDATAワイヤ形式
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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algを論じ尽くしてください。 | 旗| 繰り返し| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 塩の長さ| 塩/+++++++++++++++++++++++++++++++++
Hash Algorithm is a single octet.
細切れ肉料理Algorithmはただ一つの八重奏です。
Flags field is a single octet.
旗の分野はただ一つの八重奏です。
Iterations is represented as a 16-bit unsigned integer, with the most significant bit first.
繰り返しは最初に、16ビットの符号のない整数として最も重要なビットで表されます。
Salt Length is represented as an unsigned octet. Salt Length represents the length of the following Salt field in octets. If the value is zero, the Salt field is omitted.
塩のLengthは無記名の八重奏として表されます。 塩のLengthは八重奏における、以下のSalt分野の長さを表します。 値がゼロであるなら、Salt分野は省略されます。
Salt, if present, is encoded as a sequence of binary octets. The length of this field is determined by the preceding Salt Length field.
存在しているなら、塩は2進の八重奏の系列としてコード化されます。 この分野の長さは前のSalt Length分野のそばで決定しています。
Laurie, et al. Standards Track [Page 13] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[13ページ]RFC5155NSEC3 March 2008
4.3. Presentation Format
4.3. プレゼンテーション形式
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 Hash Algorithm分野は無記名の10進整数として表されます。 値には、最大255があります。
o The Flags field is represented as an unsigned decimal integer.
The value has a maximum value of 255.
o Flags分野は無記名の10進整数として表されます。 値には、255の最大値があります。
o The Iterations field is represented as an unsigned decimal
integer. The value is between 0 and 65535, inclusive.
o Iterations分野は無記名の10進整数として表されます。 値が0と65535の間あります。包括的。
o The Salt Length field is not represented.
o Salt Length分野は表されません。
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 Salt分野は大文字と小文字を区別しない16進数字の系列として表されます。 空白は系列の中に許容されていません。 塩の長さの分野がゼロであるときに、この分野は「-」(引用文のない)として表されます。
5. Calculation of the Hash
5. 細切れ肉料理の計算
The hash calculation uses three of the NSEC3 RDATA fields: Hash Algorithm, Salt, and Iterations.
細切れ肉料理計算は3つのNSEC3 RDATA分野を使用します: アルゴリズム、塩、および繰り返しを論じ尽くしてください。
Define H(x) to be the hash of x using the Hash Algorithm selected by the NSEC3 RR, k to be the number of Iterations, and || to indicate concatenation. Then define:
そしてNSEC3 RRによって選択されたHash Algorithmを使用して、xの細切れ肉料理になるようにH(x)を定義してください、Iterationsの数である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)はk>0であるならH(IH(塩、x、k-1)| | 塩)と等しいです。
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. すべての大文字している米国-ASCII手紙を対応する小文字の米国-ASCII手紙に取り替えます。
Laurie, et al. Standards Track [Page 14] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[14ページ]RFC5155NSEC3 March 2008
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].
Hashについて計算する方法は[RFC2898]に基づいています。
6. Opt-Out
6. 抜けてください。
In this specification, as in [RFC4033], [RFC4034] and [RFC4035], NS RRSets at delegation points are not signed and may be accompanied by a DS RRSet. With the Opt-Out bit clear, the security status of the child zone is determined by the presence or absence of this DS RRSet, cryptographically proven by the signed NSEC3 RR at the hashed owner name of the delegation. Setting the Opt-Out flag modifies this by allowing insecure delegations to exist within the signed zone without a corresponding NSEC3 RR at the hashed owner name of the delegation.
この仕様では、[RFC4033]、[RFC4034]、および[RFC4035]のように、代表団ポイントのNS RRSetsはサインされないで、DS RRSetによって同伴されるかもしれません。 外のOptビットが明確な状態で、子供ゾーンのセキュリティ状態は、このDS RRSetの存在か不在によって決定して、代表団の論じ尽くされた所有者名におけるサインされたNSEC3 RRによって暗号で立証されています。 外のOpt旗を設定すると、不安定な代表団がサインされたゾーンの中に対応する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)と次の論じ尽くされた所有者名の間には、代表団の所有者名か「次に、より近い」という名前の細切れ肉料理があるなら、外のOpt 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.
外のOpt NSEC3 RRはそれが覆うかもしれない不安定な代表団の存在か非存在について断言しません。NSEC3 RRチェーンでRRsに再計算するか、または再サインしないで、これはこれらの代表団の添加か取り外しを考慮します。 しかしながら、外のOpt NSEC3 RRsが断言する、(非、)、他の、そして、正式のRRSetsの存在。
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.
外のOpt NSEC3 RR MAYには、不安定な代表団と同じ最初の所有者名があります。 この場合、代表団はタイプ地図の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.
そして、外のOptを使用するゾーンが外のOpt NSEC3 RRsの混合物を含むかもしれない、非、抜けてください、NSEC3 RRs。 NSEC3 RRが外のOptでないなら、NSEC3 RDATAの次の論じ尽くされた所有者名によって示されたそれと名前の間には、不安定な代表団(または、いかなる他のRRsも)のどんな論じ尽くされた所有者名もあるはずがありません。 外のOptであるなら、それは不安定な代表団の論じ尽くされた所有者名か「次に、より近い」という論じ尽くされて、名前をカバーするだけでよいです。
The effects of the Opt-Out flag on signing, serving, and validating responses are covered in following sections.
応答にサインして、役立って、有効にすることへの外のOpt旗の効果は以下の章でカバーされています。
Laurie, et al. Standards Track [Page 15] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[15ページ]RFC5155NSEC3 March 2008
7. Authoritative Server Considerations
7. 正式のサーバ問題
7.1. Zone Signing
7.1. ゾーン調印
Zones using NSEC3 must satisfy the following properties:
NSEC3を使用するゾーンは以下の特性を満たさなければなりません:
o Each owner name within the zone that owns authoritative RRSets
MUST have a corresponding NSEC3 RR. Owner names that correspond
to unsigned delegations MAY have a corresponding NSEC3 RR.
However, if there is not a corresponding NSEC3 RR, there MUST be
an Opt-Out NSEC3 RR that covers the "next closer" name to the
delegation. Other non-authoritative RRs are not represented by
NSEC3 RRs.
o 正式のRRSetsを所有しているゾーンの中のそれぞれの所有者名には、対応するNSEC3 RRがなければなりません。 無記名の代表団に対応する所有者名は対応するNSEC3 RRを持っているかもしれません。 しかしながら、対応するNSEC3 RRがなければ、「次に、より近い」という名前を代表団にカバーする外のOpt NSEC3 RRがあるに違いありません。 他の非正式のRRsはNSEC3 RRsによって表されません。
o Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
the empty non-terminal is only derived from an insecure delegation
covered by an Opt-Out NSEC3 RR.
o それぞれの人影のない非端末には対応するNSEC3 RRがなければなりません、人影のない非端末が外のOpt 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 TTLはゾーンの最小のTTL値の分野と同じくらいがSOA RRであったならいずれのためにもNSEC3 RR SHOULDを評価します。
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のType Bit Maps分野は最初の所有者名で出席しているすべてのタイプの存在を示さなければなりません、NSEC3 RR自身によって唯一寄付されたタイプを除いて。 これが、NSEC3タイプ自体がType Bit Mapsに決して出席しないことを意味することに注意してください。
The following steps describe a method of proper construction of NSEC3 RRs. This is not the only such possible method.
以下のステップはNSEC3 RRsの適切な構造の方法を説明します。 これは唯一のそのようなもの可能な方法ではありません。
1. Select the hash algorithm and the values for salt and iterations.
1. 塩と繰り返しのために細切れ肉料理アルゴリズムと値を選択してください。
2. For each unique original owner name in the zone add an NSEC3 RR.
2. ゾーンのそれぞれのユニークな最初の所有者名には、NSEC3 RRを加えてください。
* If Opt-Out is being used, owner names of unsigned delegations
MAY be excluded.
* 外のOptが使用されているなら、無記名の代表団の所有者名は除かれるかもしれません。
* 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)は単一のラベルとしてゾーン名にprependedされた最初の所有者名の細切れ肉料理です。
* The Next Hashed Owner Name field is left blank for the moment.
* Next Hashed Owner Name野原はさしあたり、空白のままにされます。
* If Opt-Out is being used, set the Opt-Out bit to one.
* 外のOptが使用されているなら、外のOptビットを1つに設定してください。
* For collision detection purposes, optionally keep track of the
original owner name with the NSEC3 RR.
* 衝突検出目的には、任意にNSEC3 RRの最初の所有者名の動向をおさえてください。
Laurie, et al. Standards Track [Page 16] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[16ページ]RFC5155NSEC3 March 2008
* 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.
* 衝突検出目的には、さらに、任意にprependedされるアスタリスクラベルの最初の所有者名に対応する追加NSEC3 RRを作成してください、そして、(すなわち、まるでワイルドカードがこの所有者名の子供として存在しているかのように)この最初の所有者名の動向をおさえてください。 一時的であるとしてこのNSEC3 RRをマークしてください。
3. For each RRSet at the original owner name, set the corresponding
bit in the Type Bit Maps field.
3. 最初の所有者名における各RRSetに関しては、Type Bit Maps分野に対応するビットをはめ込んでください。
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 RRsは、頂点と最初の所有者名の間のあらゆる人影のない非端末に加えられる必要があります。 この過程は論じ尽くされた所有者が命名する写しでNSEC3 RRsを発生させるかもしれません。 衝突検出には、任意に、最初の所有者名(これらのNSEC3 RRs)を追跡してください、そして、ワイルドカード衝突のための一時的なNSEC3 RRsを同様にステップ1に作成してください。
5. Sort the set of NSEC3 RRs into hash order.
5. NSEC3 RRsのセットを細切れ肉料理オーダーに分類してください。
6. Combine NSEC3 RRs with identical hashed owner names by replacing
them with a single NSEC3 RR with the Type Bit Maps field
consisting of the union of the types represented by the set of
NSEC3 RRs. If the original owner name was tracked, then
collisions may be detected when combining, as all of the matching
NSEC3 RRs should have the same original owner name. Discard any
possible temporary NSEC3 RRs.
6. NSEC3 RRsのセットによって代理をされたタイプの組合から成るType Bit Maps分野でそれらを独身のNSEC3 RRに取り替えることによって、同じ論じ尽くされた所有者名にNSEC3 RRsを結合してください。 結合するとき、最初の所有者名が追跡されたなら、衝突は検出されるかもしれません、合っているNSEC3 RRsのすべてに同じ最初の所有者名があるべきであるとき。 あらゆる可能な一時的なNSEC3 RRsを捨ててください。
7. In each NSEC3 RR, insert the next hashed owner name by using the
value of the next NSEC3 RR in hash order. The next hashed owner
name of the last NSEC3 RR in the zone contains the value of the
hashed owner name of the first NSEC3 RR in the hash order.
7. 各NSEC3 RRに、細切れ肉料理オーダーにおける、次のNSEC3 RRの値を使用することによって、次の論じ尽くされた所有者名を挿入してください。 次の論じ尽くされた所有者名(ゾーンにおける最後のNSEC3 RR)は細切れ肉料理オーダーにおける、論じ尽くされた所有者名(最初のNSEC3 RR)の値を含んでいます。
8. Finally, add an NSEC3PARAM RR with the same Hash Algorithm,
Iterations, and Salt fields to the zone apex.
8. 最終的に、同じHash Algorithm、Iterations、およびSalt分野があるNSEC3PARAM RRをゾーンの頂点に加えてください。
If a hash collision is detected, then a new salt has to be chosen, and the signing process restarted.
細切れ肉料理衝突が検出されるなら、新しい塩は選ばれなければなりませんでした、そして、サインアップ過程は再開しました。
7.2. Zone Serving
7.2. ゾーンの給仕
This specification modifies DNSSEC-enabled DNS responses generated by authoritative servers. In particular, it replaces the use of NSEC RRs in such responses with NSEC3 RRs.
この仕様は正式のサーバで発生するDNSSECによって可能にされたDNS応答を変更します。 特に、それはそのような応答におけるNSEC RRsの使用をNSEC3 RRsに取り替えます。
Laurie, et al. Standards Track [Page 17] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[17ページ]RFC5155NSEC3 March 2008
In the following response cases, the NSEC RRs dictated by DNSSEC [RFC4035] are replaced with NSEC3 RRs that prove the same facts. Responses that would not contain NSEC RRs are unchanged by this specification.
以下の応答場合では、DNSSEC[RFC4035]によって書き取られたNSEC RRsを同じ事実を立証するNSEC3 RRsに取り替えます。 NSEC RRsを含まない応答はこの仕様で変わりがありません。
When returning responses containing multiple NSEC3 RRs, all of the NSEC3 RRs MUST use the same hash algorithm, iteration, and salt values. The Flags field value MUST be either zero or one.
複数のNSEC3 RRsを含む応答を返すとき、NSEC3 RRsのすべてが同じ細切れ肉料理アルゴリズム、繰り返し、および塩の値を使用しなければなりません。 Flags分野価値は、ゼロか1つのどちらかであるに違いありません。
7.2.1. Closest Encloser Proof
7.2.1. 最も近いEncloser証拠
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:
この証拠は(up to)twoの異なったNSEC3 RRsから成ります:
o An NSEC3 RR that matches the closest (provable) encloser.
o 最も近く(証明可能な)でencloserに合っているNSEC3 RR。
o An NSEC3 RR that covers the "next closer" name to the closest
encloser.
o 「次に、より近い」という名前を最も近いencloserにカバーするNSEC3 RR。
The first NSEC3 RR essentially proposes a possible closest encloser, and proves that the particular encloser does, in fact, exist. The second NSEC3 RR proves that the possible closest encloser is the closest, and proves that the QNAME (and any ancestors between QNAME and the closest encloser) does not exist.
最初のNSEC3 RRは、本質的には可能な限り近いencloserを提案して、事実上、特定のencloserが存在すると立証します。 第2NSEC3 RRは、可能な限り近いencloserが最も近くにあると立証して、QNAME(そして、QNAMEと最も近いencloserの間のどんな先祖も)が存在しないと立証します。
These NSEC3 RRs are collectively referred to as the "closest encloser proof" in the subsequent descriptions.
これらのNSEC3 RRsはその後の記述における「最も近い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).
例えば、"alpha.beta.gamma.example" 所有者が命名する実在しなさのための最も近いencloser証拠はその"gamma.example"を立証するかもしれません。最も近いのはencloserですか? この応答は合っているNSEC3 RRを含んでいるでしょう。"gamma.example" また、"beta.gamma.example"を覆うNSEC3 RRを含んでいるでしょう。 (「次に、より近い」という名前です。)
It is possible, when using Opt-Out (Section 6), to not be able to prove the actual closest encloser because it is, or is part of an insecure delegation covered by an Opt-Out span. In this case, instead of proving the actual closest encloser, the closest provable encloser is used. That is, the closest enclosing authoritative name is used instead. In this case, the set of NSEC3 RRs used for this proof is referred to as the "closest provable encloser proof".
それは、それが可能であるので、実際の最も近いencloserを立証できないように、外のOpt(セクション6)を使用するとき、可能であるか、または外のOptの長さで覆われた不安定な代表団の一部です。 この場合、実際の最も近いencloserを立証することの代わりに、最も近い証明可能なencloserは使用されています。 すなわち、最も近くでは、正式の名前を同封するのが代わりに使用されます。 この場合、この証拠に使用されるNSEC3 RRsのセットは「最も近い証明可能なencloser証拠」と呼ばれます。
Laurie, et al. Standards Track [Page 18] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[18ページ]RFC5155NSEC3 March 2008
7.2.2. Name Error Responses
7.2.2. 名前誤り応答
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.
最も近くで(実在しません)のワイルドカードRRを覆うQNAME、最も近いencloser証拠、およびNSEC3 RRの非実在を立証するために、応答にencloserを含まなければなりません。 3NSEC3 RRsが立証するQNAMEがする(up to)の両方のこの収集は存在していません、そして、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.
「例えば、そして、NSEC3 RR覆い"gamma.example"がQNAMEへの最も近い証明可能なencloserであるなら」*.gamma.example」 応答の権威部では、含まれています。
7.2.3. No Data Responses, QTYPE is not DS
7.2.3. いいえData Responses、QTYPEはDSではありません。
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 MUST NOTはType Bit Maps分野にQTYPEかCNAMEのどちらかに対応するビットをセットさせます。
7.2.4. No Data Responses, QTYPE is DS
7.2.4. いいえData Responses、QTYPEはDSです。
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があれば、サーバは応答でそれを返さなければなりません。 このType Bit Maps分野におけるセットがNSEC3 RRであったならDSとCNAME MUST NOTに対応するビット。
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は外のOptビットを設定させなければなりません(これが定義上本当であることに注意してください--外のOptビットが設定されないなら、何かが支障をきたしました)。
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で正式であるなら、サーバはゾーンカットの親側から証拠を返さなければなりません。
7.2.5. Wildcard No Data Responses
7.2.5. ワイルドカードいいえデータ応答
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 MUSTへの最も近いencloserがワイルドカードRRの即座の先祖であることに注意してください(これがそうでないなら、何かが支障をきたしました)。
Laurie, et al. Standards Track [Page 19] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[19ページ]RFC5155NSEC3 March 2008
7.2.6. Wildcard Answer Responses
7.2.6. ワイルドカード答え応答
If there is a wildcard match for QNAME and QTYPE, then, in addition to the expanded wildcard RRSet returned in the answer section of the response, proof that the wildcard match was valid must be returned.
QNAMEとQTYPEのためのワイルドカードマッチがあれば、応答の答え部で返された拡張ワイルドカードRRSetに加えて、ワイルドカードマッチが有効であったという証拠を返さなければなりません。
This proof is accomplished by proving that both QNAME does not exist and that the closest encloser of the QNAME and the immediate ancestor of the wildcard are the same (i.e., the correct wildcard matched).
QNAMEがする両方が存在していなくて、QNAMEの最も近い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に合っているNSEC3 RRを返すのは必要ではありません、この最も近いencloserの存在が応答における、拡張ワイルドカードの存在によって立証されるとき。
7.2.7. Referrals to Unsigned Subzones
7.2.7. 無記名のSubzonesへの紹介
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 MUSTが応答に含まれているその時。 DSはNSEC3 RR MUST NOTのタイプビットマップで噛み付きました。設定されます。
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).
ゾーンが外のOptであるなら、代表団に対応するNSEC3 RRがないかもしれません。 この場合、応答に最も近い証明可能なencloser証拠を含まなければなりません。 代表団のために「次に、より近い」という名前をカバーする含まれているNSEC3 RRは外のOpt旗を1つに設定させなければなりません。 (何かが支障をきたさない場合これがそうになることに注意します。)
7.2.8. Responding to Queries for NSEC3 Owner Names
7.2.8. NSEC3所有者名のための質問に応じます。
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 RRs)は他の所有者名のようにNSEC3 RRチェーンで表されません。 その結果、それぞれのNSEC3所有者名は別のNSEC3 RRでカバーされています、事実上、NSEC3 RRの存在を否定して。 RRSIG RRSetがNSEC3 RRの存在を立証できるので、これはパラドックスです。
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.
そして、Name Error応答(セクション7.2.2)として応答を構成しなければなりません。 または、言い換えれば、まるで所有者名(NSEC3 RR)が存在していないかのように正式のネームサーバは行動するでしょう。
Laurie, et al. Standards Track [Page 20] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[20ページ]RFC5155NSEC3 March 2008
Note that NSEC3 RRs are returned as a result of an AXFR or IXFR query.
NSEC3 RRsがAXFRかIXFR質問の結果、返されることに注意してください。
7.2.9. Server Response to a Run-Time Collision
7.2.9. ランタイム衝突へのサーバ応答
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に、そのような衝突が非常にありそうもないことに注意してください。
7.3. Secondary Servers
7.3. セカンダリサーバ
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パラメタ(すなわち、細切れ肉料理、塩、および繰り返し)があらゆる論じ尽くされた所有者名で存在しているかを確かに決定する必要があります、否定応答のためのNSEC3 RRsの適切なセットを選ぶことができるように。 これはゾーンの頂点の現在のNSEC3PARAM RRによって示されます。
If there are multiple NSEC3PARAM RRs present, there are multiple valid NSEC3 chains present. The server must choose one of them, but may use any criteria to do so.
複数の存在しているNSEC3PARAM RRsがあれば、複数の存在している有効なNSEC3チェーンがあります。 サーバは、それらの1つを選ばなければなりませんが、そうするのにどんな評価基準も使用するかもしれません。
7.4. Zones Using Unknown Hash Algorithms
7.4. 未知の細切れ肉料理アルゴリズムを使用するゾーン
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細切れ肉料理アルゴリズム価値を使用しているゾーンに役立つことができません。 そのようなものはSHOULDを区分します。ロードするとき、拒絶されます。 そのようなゾーンの下で下がる質問を扱うとき、サーバSHOULDはRCODE=2(サーバ失敗)応答で応じます。
7.5. Dynamic Update
7.5. ダイナミック・アップデート
A zone signed using NSEC3 may accept dynamic updates [RFC2136]. However, NSEC3 introduces some special considerations for dynamic updates.
NSEC3を使用することでサインされたゾーンはダイナミックなアップデート[RFC2136]を受け入れるかもしれません。 しかしながら、NSEC3はダイナミックなアップデートのためにいくつかの特別な問題を紹介します。
Adding and removing names in a zone MUST account for the creation or removal of empty non-terminals.
ゾーンで名前を加えて、取り除くと、人影のない非端末の創造か取り外しが理由を与えなければなりません。
o When removing a name with a corresponding NSEC3 RR, any NSEC3 RRs
corresponding to empty non-terminals created by that name MUST be
removed. Note that more than one name may be asserting the
existence of a particular empty non-terminal.
o 対応するNSEC3 RRの名前を取り除くとき、その名前によって作成された非端末を空にするために対応するどんなNSEC3 RRsも取り外さなければなりません。 1つ以上の名前が特定の人影のない非端末の存在について断言しているかもしれないことに注意してください。
Laurie, et al. Standards Track [Page 21] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[21ページ]RFC5155NSEC3 March 2008
o When adding a name that requires adding an NSEC3 RR, NSEC3 RRs
MUST also be added for any empty non-terminals that are created.
That is, if there is not an existing NSEC3 RR matching an empty
non-terminal, it must be created and added.
o また、NSEC3 RRを加えるのを必要とする名前を加えるとき、作成されるどんな人影のない非端末にもNSEC3 RRsを加えなければなりません。 すなわち、人影のない非端末に合っている既存のNSEC3 RRがなければ、それを作成されて、加えなければなりません。
The presence of Opt-Out in a zone means that some additions or delegations of names will not require changes to the NSEC3 RRs in a zone.
ゾーンでの外のOptの存在は、名前のいくつかの追加か代表団がゾーンのNSEC3 RRsへの変化を必要としないことを意味します。
o When removing a delegation RRSet, if that delegation does not have
a matching NSEC3 RR, then it was opted out. In this case, nothing
further needs to be done.
o RRSet、代表団を取り除くとき、その代表団に合っているNSEC3 RRがないなら、それは抜けました。 この場合、何も、さらにする必要がありません。
o When adding a delegation RRSet, if the "next closer" name of the
delegation is covered by an existing Opt-Out NSEC3 RR, then the
delegation MAY be added without modifying the NSEC3 RRs in the
zone.
o 代表団RRSetを加えるとき、「次に、より近い」という代表団の名前が既存の外のOpt NSEC3 RRでカバーされているなら、ゾーンでNSEC3 RRsを変更しないで、代表団は加えられるかもしれません。
The presence of Opt-Out in a zone means that when adding or removing NSEC3 RRs, the value of the Opt-Out flag that should be set in new or modified NSEC3 RRs is ambiguous. Servers SHOULD follow this set of basic rules to resolve the ambiguity.
ゾーンでの外のOptの存在は、NSEC3 RRsを加えるか、または取り外すとき、新しいか変更されたNSEC3 RRsに設定されるべきである外のOpt旗の値があいまいであることを意味します。 サーバSHOULDは、あいまいさを取り除くためにこのセットの基本的なルールに従います。
The central concept to these rules is that the state of the Opt-Out flag of the covering NSEC3 RR is preserved.
これらの規則への主要な概念は覆いNSEC3 RRの外のOpt旗の状態が保持されるということです。
o When removing an NSEC3 RR, the value of the Opt-Out flag for the
previous NSEC3 RR (the one whose next hashed owner name is
modified) should not be changed.
o NSEC3 RRを取り外すとき、前のNSEC3 RR(次の論じ尽くされた所有者名が変更されているもの)のための外のOpt旗の値を変えるべきではありません。
o When adding an NSEC3 RR, the value of the Opt-Out flag is set to
the value of the Opt-Out flag of the NSEC3 RR that previously
covered the owner name of the NSEC3 RR. That is, the now previous
NSEC3 RR.
o NSEC3 RRを加えるとき、外のOpt旗の値は以前に所有者名(NSEC3 RR)をカバーしたNSEC3 RRの外のOpt旗の値に設定されます。 すなわち、現在前の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.
問題のゾーンが外のOpt旗の使用と一致していると(ゾーンのすなわちすべてのNSEC3 RRsには、旗のための同じ値があります)、これらの規則はその一貫性を保有するでしょう。 ゾーンが旗(すなわち、Opt部分的に出ているゾーン)の使用で一貫していないと、これらの規則は外のOpt旗で役に立つ同じパターンを保有しないでしょう。
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.
その使用のための論理的様式があれば外のOpt旗を部分的に使用するゾーンにおいて、サーバに関するローカルの方針を使用することによって、パターンを維持できるでしょう。
Laurie, et al. Standards Track [Page 22] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[22ページ]RFC5155NSEC3 March 2008
8. Validator Considerations
8. Validator問題
8.1. Responses with Unknown Hash Types
8.1. 未知の細切れ肉料理タイプとの応答
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.
validatorは未知の細切れ肉料理タイプがあるNSEC3 RRsを無視しなければなりません。 この実際的な結果は一般に、そのようなNSEC3 RRsだけを含む応答がにせであると考えられるということです。
8.2. Verifying NSEC3 RRs
8.2. NSEC3 RRsについて確かめます。
A validator MUST ignore NSEC3 RRs with a Flag fields value other than zero or one.
validatorはゼロか1を除いたFlag分野価値があるNSEC3 RRsを無視しなければなりません。
A validator MAY treat a response as bogus if the response contains NSEC3 RRs that contain different values for hash algorithm, iterations, or salt from each other for that zone.
応答が互いからの細切れ肉料理アルゴリズムのための異価、繰り返し、または塩をそのゾーンに含むNSEC3 RRsを含んでいるなら、validatorはにせであるとして応答を扱うかもしれません。
8.3. Closest Encloser Proof
8.3. 最も近いEncloser証拠
In order to verify a closest encloser proof, the validator MUST find the longest name, X, such that
X、最も近いencloser証拠について確かめるために、validatorは最も長い名前を見つけなければならなくて、そのようなものはそれです。
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.
o しかし、名前1がXより長い間ラベルする、(先祖を静める、等しい、--QNAME) 応答における現在のNSEC3 RRで、覆われています。
One possible algorithm for verifying this proof is as follows:
この証拠について確かめるための1つの可能なアルゴリズムは以下の通りです:
1. Set SNAME=QNAME. Clear the flag.
1. SNAME=QNAMEを設定してください。 旗をきれいにしてください。
2. Check whether SNAME exists:
2. SNAMEが存在するかどうかチェックしてください:
* If there is no NSEC3 RR in the response that matches SNAME
(i.e., an NSEC3 RR whose owner name is the same as the hash of
SNAME, prepended as a single label to the zone name), clear
the flag.
* SNAME(すなわち、所有者名が単一のラベルとしてゾーン名にprependedされたSNAMEの細切れ肉料理と同じであるNSEC3 RR)に合っている応答にNSEC3 RRが全くなければ、旗をきれいにしてください。
* If there is an NSEC3 RR in the response that covers SNAME, set
the flag.
* SNAMEを覆う応答にNSEC3 RRがあれば、旗を設定してください。
* If there is a matching NSEC3 RR in the response and the flag
was set, then the proof is complete, and SNAME is the closest
encloser.
* 応答には合っているNSEC3 RRがあって、旗が設定されたなら、証拠は完全です、そして、SNAMEは最も近いencloserです。
Laurie, et al. Standards Track [Page 23] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[23ページ]RFC5155NSEC3 March 2008
* If there is a matching NSEC3 RR in the response, but the flag
is not set, then the response is bogus.
* 応答には合っているNSEC3 RRがありますが、旗が設定されないなら、応答はにせです。
3. Truncate SNAME by one label from the left, go to step 2.
3. 1個のラベルで左のSNAMEに先端を切らせてください、そして、ステップ2に行ってください。
Once the closest encloser has been discovered, the validator MUST check that the NSEC3 RR that has the closest encloser as the original owner name is from the proper zone. The DNAME type bit must not be set and the NS type bit may only be set if the SOA type bit is set. If this is not the case, it would be an indication that an attacker is using them to falsely deny the existence of RRs for which the server is not authoritative.
最も近いencloserがいったん発見されると、validatorは、最初の所有者名として最も近いencloserを持っているNSEC3 RRが適切なゾーンから来ているのをチェックしなければなりません。 DNAMEタイプビットを設定してはいけません、そして、SOAタイプビットが設定される場合にだけ、NSタイプビットは設定されるかもしれません。 これがそうでないなら、それは攻撃者が間違ってサーバが正式でないRRsの存在を否定するのにそれらを使用しているという指示でしょう。
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の先祖が最も近いencloserであると立証することによってXが存在しないと立証することを意味します。
8.4. Validating Name Error Responses
8.4. 名前誤り応答を有効にします。
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).
validatorは応答における現在のQNAMEのための最も近いencloser証拠があって、最も近いencloserにワイルドカードを覆うNSEC3 RRがあることを確かめなければなりません(すなわち、名前は最も近いencloserにアスタリスクラベルをprependingすることによって、形成されました)。
8.5. Validating No Data Responses, QTYPE is not DS
8.5. Data Responsesを全く有効にしないで、QTYPEはDSではありません。
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.
validatorはQNAMEに合っているNSEC3 RRが存在していて、QTYPEとCNAMEタイプの両方がType Bit Maps分野で用意ができていないことを確かめなければなりません。
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が人影のないType Bit Maps分野を持っているケースをカバーすることに注意してください。
8.6. Validating No Data Responses, QTYPE is DS
8.6. Data Responsesを全く有効にしないで、QTYPEはDSです。
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 MUST NOTはType Bit Maps分野に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がなければ、validatorは、最も近いQNAMEに、証明可能なencloser証拠が応答で存在していることを確かめなければなりません、そして、「次に、より近い」という名前をカバーするNSEC3 RRが噛み付かれた状態でOptを取り除くのはセットしました。
Laurie, et al. Standards Track [Page 24] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[24ページ]RFC5155NSEC3 March 2008
8.7. Validating Wildcard No Data Responses
8.7. ワイルドカードいいえデータ応答を有効にします。
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.
validatorは、QNAMEのために最も近いencloser証拠について確かめなければならなくて、NSEC3 RRが最も近いencloserにアスタリスクラベルをprependingすることによって発生というワイルドカード名に合っている応答で存在しているのがわからなければなりません。 その上、中のセットがNSEC3 RRに合っているワイルドカードであったならQTYPEとCNAME MUST NOTの両方に対応するビット。
8.8. Validating Wildcard Answer Responses
8.8. ワイルドカード答え応答を有効にします。
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.
応答における確かめられたワイルドカード答えRRSetはQNAMEのために(候補)最も近いencloserをvalidatorに提供します。 この最も近い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.
Validatorsは、「次に、より近い」という名前を応答における現在のQNAMEにカバーするNSEC3 RRがあることを確かめなければなりません。 これは、QNAME自身が存在しないで、正しいワイルドカードが応答を発生させるのに使用されたと立証します。
8.9. Validating Referrals to Unsigned Subzones
8.9. 紹介を無記名のSubzonesに有効にします。
The delegation name in a referral is the owner name of the NS RRSet present in the authority section of the referral response.
紹介における代表団名は所有者名(紹介応答の権威部の現在のNS RRSet)です。
If there is an NSEC3 RR present in the response that matches the delegation name, then the validator MUST ensure that the NS bit is set and that the DS bit is not set in the Type Bit Maps field of the NSEC3 RR. The validator MUST also ensure that the NSEC3 RR is from the correct (i.e., parent) zone. This is done by ensuring that the SOA bit is not set in the Type Bit Maps field of this NSEC3 RR.
代表団名に合っている応答における現在のNSEC3 RRがあれば、validatorは、NSビットが設定されて、DSビットはNSEC3 RRのType Bit Maps分野に設定されないのを確実にしなければなりません。 また、validatorは、NSEC3 RRが正しい(すなわち、親)ゾーンから来ているのを確実にしなければなりません。 SOAビットがこのNSEC3 RRのType Bit Maps分野に設定されないのを確実にすることによって、これをします。
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.
DNAMEビットがないかどうかNSEC3 RRのType Bit Maps分野でチェックする必要は全くないようにNSビットの存在が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もなければ、validatorは代表団名のために最も近い証明可能なencloser証拠について確かめなければなりません。 validatorは、外のOptビットが「次に、より近い」という名前を代表団名にカバーするNSEC3 RRに設定されることを確かめなければなりません。
Laurie, et al. Standards Track [Page 25] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[25ページ]RFC5155NSEC3 March 2008
9. Resolver Considerations
9. レゾルバ問題
9.1. NSEC3 Resource Record Caching
9.1. NSEC3リソース記録キャッシュ
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 RRsを検索できなければなりません。 多くの場合、DNSSEC[RFC4035]では、名前で応答で戻るために正しいNSEC RRを見つけるのは可能です(例えば、紹介を返すとき、NSEC RRには、代表団と同じ所有者名がいつもあるでしょう)。 この仕様で、それは本当にならないでしょう、そして、キャッシュは適切なNSEC3 RR(s)という名前について計算できないでしょう。 実現は、NSEC3 RRsをキャッシュして、検索するのに新しい方法を使用する必要があるかもしれません。
9.2. Use of the AD Bit
9.2. ADビットの使用
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が外のOptの噛み付いているセットを持っているencloser証拠応答を返すとき、[RFC4035]によって定義されるADビットを設定してはいけません。
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.
この規則はこの最も近いencloser証拠が実際に何を立証するかに基づいています: 外のOpt NSEC3 RRでカバーされている名前は不安定な代表団として存在するかもしれません。 そういうものとして、すべてではなく、含む中で最も近くそのようなencloser証拠応答におけるデータが暗号で確かめられてしまうだろうので、ADビットを設定できません。
10. Special Considerations
10. 特別な問題
10.1. Domain Name Length Restrictions
10.1. ドメイン名長さの制限
Zones signed using this specification have additional domain name length restrictions imposed upon them. In particular, zones with names that, when converted into hashed owner names exceed the 255 octet length limit imposed by [RFC1035], cannot use this specification.
この仕様を使用することでサインされたゾーンで、追加ドメイン名長さの制限をそれらに課します。 特に論じ尽くされた所有者に変換されて、名前が[RFC1035]によって課された255八重奏長さの限界を超えている場合この仕様を使用できない名前があるゾーン。
The actual maximum length of a domain name in a particular zone depends on both the length of the zone name (versus the whole domain name) and the particular hash function used.
特定のゾーンのドメイン名の実際の最大の長さはゾーン名(全体のドメイン名に対する)の長さと特定のハッシュ関数が使用した両方に依存します。
As an example, SHA-1 produces a hash of 160 bits. The base-32 encoding of 160 bits results in 32 characters. The 32 characters are prepended to the name of the zone as a single label, which includes a length field of a single octet. The maximum length of the zone name, when using SHA-1, is 222 octets (255 - 33).
例として、SHA-1は160ビットの細切れ肉料理を生産します。 160ビットのベース-32コード化は32のキャラクタをもたらします。 32のキャラクタが単一のラベルとしてゾーンの名前にprependedされます。(それは、ただ一つの八重奏の長さの分野を含んでいます)。 SHA-1を使用するとき、ゾーン名の最大の長さは222の八重奏(255--33)です。
Laurie, et al. Standards Track [Page 26] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[26ページ]RFC5155NSEC3 March 2008
10.2. DNAME at the Zone Apex
10.2. ゾーンの頂点のDNAME
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がゾーンの頂点であるなら、NSEC3があるでしょう、そして、RRSIGタイプはNSEC3を許容するためにN.This仕様最新版の子孫にDNAME仕様を提示します、そして、RRSIGはDNAMEの存在にかかわらず頂点で頂点の子孫でタイプします。
10.3. Iterations
10.3. 繰り返し
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.
また、明らかに、繰り返しの数はゾーン所有者のvalidatorのゾーンから応答について確かめる費用と同様にゾーンにサインして、役立つ費用に影響します。 したがって、私たちは繰り返しの数に上限を課します。 これは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.
ゾーン所有者は与えられた主要なサイズのための繰り返しに以下のテーブルに示されるより高い値を使用してはいけません。 より高い値が不安定な状態でレゾルバは応答を扱うかもしれません、validatorが、NSEC3 RRの上の署名が正しいことを確かめた後に。
+----------+------------+
| Key Size | Iterations |
+----------+------------+
| 1024 | 150 |
| 2048 | 500 |
| 4096 | 2,500 |
+----------+------------+
+----------+------------+ | 主要なサイズ| 繰り返し| +----------+------------+ | 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計算の費用とサイズのキーのためのRSA検証の費用の間の比率の近似に1024ビット(150〜1)、2048ビット(500〜1)、および4096ビット(2500〜1)基づいています。
Laurie, et al. Standards Track [Page 27] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[27ページ]RFC5155NSEC3 March 2008
The ratio between SHA-1 calculation and DSA verification is higher (1500 to 1 for keys of size 1024). A higher iteration count degrades performance, while DSA verification is already more expensive than RSA for the same key size. Therefore the values in the table MUST be used independent of the key algorithm.
SHA-1計算とDSA検証の間の比率は、より高いです(サイズ1024のキーのための1500〜1)。 より高い繰り返しカウントが性能を下げますが、同じ主要なサイズには、DSA検証はRSAより既に高価です。 したがって、主要なアルゴリズムの如何にかかわらずテーブルの値を使用しなければなりません。
10.4. Transitioning a Signed Zone from NSEC to NSEC3
10.4. 移行しているaはnsecからNSEC3までゾーンにサインしました。
When transitioning an already signed and trusted zone to this specification, care must be taken to prevent client validation failures during the process.
移行して、この仕様、注意への既にサインされて、信じられたゾーンが取らなければならないとき、取って、過程の間、クライアント合法化失敗を防いでください。
The basic procedure is as follows:
基本的な手順は以下の通りです:
1. Transition all DNSKEYs to DNSKEYs using the algorithm aliases
described in Section 2. The actual method for safely and
securely changing the DNSKEY RRSet of the zone is outside the
scope of this specification. However, the end result MUST be
that all DS RRs in the parent use the specified algorithm
aliases.
1. セクション2で説明されたアルゴリズム別名を使用するDNSKEYsへの変遷DNSKEYs。 この仕様の範囲の外に安全にしっかりとゾーンのDNSKEY RRSetを変えるための実際の方法があります。 しかしながら、結末は親のすべてのDS RRsが指定されたアルゴリズム別名を使用するということであるに違いありません。
After this transition is complete, all NSEC3-unaware clients will
treat the zone as insecure. At this point, the authoritative
server still returns negative and wildcard responses that contain
NSEC RRs.
この変遷が完全になった後に、すべてのNSEC3気づかないクライアントが不安定であるとしてゾーンを扱うでしょう。 ここに、正式のサーバはまだNSEC RRsを含む否定的、そして、ワイルドカード応答を返しています。
2. Add signed NSEC3 RRs to the zone, either incrementally or all at
once. If adding incrementally, then the last RRSet added MUST be
the NSEC3PARAM RRSet.
2. サインされたNSEC3 RRsをゾーンに増加してか一気に追加してください。 増加して加えるなら、RRSetが加えた最終はNSEC3PARAM RRSetであるに違いありません。
3. Upon the addition of the NSEC3PARAM RRSet, the server switches to
serving negative and wildcard responses with NSEC3 RRs according
to this specification.
3. NSEC3PARAM RRSetの添加のときに、サーバはこの仕様通りに否定的、そして、ワイルドカード応答にNSEC3 RRsを供給するのに切り替わります。
4. Remove the NSEC RRs either incrementally or all at once.
4. NSEC RRsを増加してか一気に取り外してください。
10.5. Transitioning a Signed Zone from NSEC3 to NSEC
10.5. 移行しているaはNSEC3からnsecまでゾーンにサインしました。
To safely transition back to a DNSSEC [RFC4035] signed zone, simply reverse the procedure above:
安全にDNSSEC[RFC4035]のサインされたゾーンに移行して戻るには、以下の上で単に手順を逆にしてください。
1. Add NSEC RRs incrementally or all at once.
1. NSEC RRsを増加してか一気に加えてください。
2. Remove the NSEC3PARAM RRSet. This will signal the server to use
the NSEC RRs for negative and wildcard responses.
2. NSEC3PARAM RRSetを取り外してください。 これは、否定的、そして、ワイルドカード応答にNSEC RRsを使用するようにサーバに合図するでしょう。
3. Remove the NSEC3 RRs either incrementally or all at once.
3. NSEC3 RRsを増加してか一気に取り外してください。
Laurie, et al. Standards Track [Page 28] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[28ページ]RFC5155NSEC3 March 2008
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気づかないクライアントが安全な状態でゾーンを扱うでしょう。
11. IANA Considerations
11. IANA問題
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形式は細切れ肉料理アルゴリズムパラメタを含んでいますが、このドキュメントは、安全に1つのNSEC3細切れ肉料理アルゴリズムから別のものに移行するために特定のメカニズムを定義しません。 また、NSEC3との使用のための新しい細切れ肉料理アルゴリズムを指定するとき、変遷メカニズムを定義しなければなりません。
This document updates the IANA registry "DOMAIN NAME SYSTEM PARAMETERS" (http://www.iana.org/assignments/dns-parameters) in sub- registry "TYPES", by defining two new types. Section 3 defines the NSEC3 RR type 50. Section 4 defines the NSEC3PARAM RR type 51.
このドキュメントは2つの新しいタイプを定義することによって、サブ登録「タイプ」でIANA登録「ドメインネームシステムパラメタ」( http://www.iana.org/assignments/dns-parameters )をアップデートします。 セクション3はNSEC3 RRタイプ50を定義します。 セクション4はNSEC3PARAM RRタイプ51を定義します。
This document updates the IANA registry "DNS SECURITY ALGORITHM NUMBERS -- per [RFC4035]" (http://www.iana.org/assignments/dns-sec-alg-numbers). Section 2 defines the aliases DSA-NSEC3-SHA1 (6) and RSASHA1-NSEC3-SHA1 (7) for respectively existing registrations DSA and RSASHA1 in combination with NSEC3 hash algorithm SHA1.
このドキュメントはIANA登録「[RFC4035]あたりのDNS SECURITY ALGORITHM NUMBERS」( http://www.iana.org/assignments/dns-sec-alg-numbers )をアップデートします。 セクション2はNSEC3細切れ肉料理アルゴリズムSHA1と組み合わせてそれぞれ既存の登録証明書のDSAとRSASHA1のために別名のDSA-NSEC3-SHA1(6)とRSASHA1-NSEC3-SHA1(7)を定義します。
Since these algorithm numbers are aliases for existing DNSKEY algorithm numbers, the flags that exist for the original algorithm are valid for the alias algorithm.
これらのアルゴリズム番号が既存のDNSKEYアルゴリズム番号のための別名であるので、別名アルゴリズムに、オリジナルのアルゴリズムのために存在する旗は有効です。
This document creates a new IANA registry for NSEC3 flags. This registry is named "DNSSEC NSEC3 Flags". The initial contents of this registry are:
このドキュメントはNSEC3旗のための新しいIANA登録を作成します。 この登録は「DNSSEC NSEC3旗」と命名されます。 この登録の初期の内容は以下の通りです。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| | | | | | | |Opt|
| | | | | | | |Out|
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | | | | | | | |選んでください。| | | | | | | | |アウト| +---+---+---+---+---+---+---+---+
bit 7 is the Opt-Out flag.
ビット7は外のOpt旗です。
bits 0 - 6 are available for assignment.
ビット0--6は課題に有効です。
Assignment of additional NSEC3 Flags in this registry requires IETF Standards Action [RFC2434].
この登録の追加NSEC3 Flagsの課題はIETF Standards Action[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旗」と命名されます。 この登録の初期の内容は以下の通りです。
Laurie, et al. Standards Track [Page 29] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[29ページ]RFC5155NSEC3 March 2008
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| | | | | | | | 0 |
+---+---+---+---+---+---+---+---+
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 Flagsの課題はIETF Standards Action[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はReservedです。
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 Standards Action[RFC2434]を必要とします。
12. Security Considerations
12. セキュリティ問題
12.1. Hashing Considerations
12.1. 問題を論じ尽くします。
12.1.1. Dictionary Attacks
12.1.1. 辞書攻撃
The NSEC3 RRs are still susceptible to dictionary attacks (i.e., the attacker retrieves all the NSEC3 RRs, then calculates the hashes of all likely domain names, comparing against the hashes found in the NSEC3 RRs, and thus enumerating the zone). These are substantially more expensive than enumerating the original NSEC RRs would have been, and in any case, such an attack could also be used directly against the name server itself by performing queries for all likely names, though this would obviously be more detectable. The expense of this off-line attack can be chosen by setting the number of iterations in the NSEC3 RR.
NSEC3 RRsはまだ辞書攻撃に影響されやすいです。(すなわち、攻撃者がすべてのNSEC3 RRsを検索する、その時計算する、論じ尽くす、比較されるすべてのありそうなドメイン名をNSEC3 RRsで見つけられて、その結果、ゾーンを列挙しながら論じ尽くす、) これらはオリジナルのNSEC RRsを数え上げるだろうより実質的に高価です、そして、どのような場合でも、また、直接ネームサーバ自体に対してすべてのありそうな名前に質問を実行することによって、そのような攻撃は使用できるでしょう、これが明らかにより検出可能でしょうが。 繰り返しの数をNSEC3 RRにはめ込むことによって、このオフライン攻撃の費用を選ぶことができます。
Zones are also susceptible to a pre-calculated dictionary attack -- that is, a list of hashes for all likely names is computed once, then NSEC3 RR is scanned periodically and compared against the precomputed hashes. This attack is prevented by changing the salt on a regular basis.
すべてに関して、ありそうな名前が一度計算されて、次に、NSEC3 RRと定期的にスキャンされて、比較されます。aが、また、ゾーンもあらかじめ計算された辞書攻撃()に影響されやすいと記載する、論じ尽くす、前計算は論じ尽くします。 この攻撃は、定期的に塩を変えることによって、防がれます。
Laurie, et al. Standards Track [Page 30] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[30ページ]RFC5155NSEC3 March 2008
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.
塩のSHOULDは攻撃者が塩の値を予期できないように、長さ少なくとも64ビットで予測できないで、ゾーンが発行される前に辞書の次のセットを計算します。
12.1.2. Collisions
12.1.2. 衝突
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が既に、抵抗力があった状態で暗号のハッシュ関数が2番目のプレイメージであるという推定に依存することに注意してください、これらのハッシュ関数が署名とDS RRsを発生して、有効にするのに使用されるので。
12.1.3. Transitioning to a New Hash Algorithm
12.1.3. 新しい細切れ肉料理アルゴリズムに移行します。
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形式は細切れ肉料理アルゴリズムパラメタを含んでいますが、このドキュメントは、安全に1つのNSEC3細切れ肉料理アルゴリズムから別のものに移行するために特定のメカニズムを定義しません。 また、NSEC3との使用のための新しい細切れ肉料理アルゴリズムを指定するとき、変遷メカニズムを定義しなければなりません。 唯一の実用的でおいしい変遷メカニズムが不安定な州、または、NSEC3の代わりにNSEC記録を使用する州への中間的変遷を必要とするのは、可能です。
12.1.4. Using High Iteration Values
12.1.4. 高い繰り返し値を使用します。
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.
高い繰り返し値が不安定な状態でvalidatorsがNSEC3 RRsを含む応答を扱うはずであるので、高い繰り返し値がゾーンにあるちょうど1サインされたNSEC3 RRの存在は可能なダウングレード攻撃を攻撃者に提供します。
The attack is simply to remove any existing NSEC3 RRs from a response, and replace or add a single (or multiple) NSEC3 RR that uses a high iterations value to the response. Validators will then be forced to treat the response as insecure. This attack would be effective only when all of following conditions are met:
攻撃は、単に高い繰り返し値を使用する独身(または、倍数)のNSEC3 RRを応答に応答からどんな既存のNSEC3 RRsも取り外して、取り替えるか、または加えることです。 そして、Validatorsは不安定であるとしてやむを得ず応答を扱うでしょう。 次の状態のすべてが会われるときだけ、この攻撃は有効でしょう:
o There is at least one signed NSEC3 RR that uses a high iterations
value present in the zone.
o ゾーンの現在の高い繰り返し値を使用する少なくとも1サインされたNSEC3 RRがあります。
o The attacker has access to one or more of these NSEC3 RRs. This
is trivially true when the NSEC3 RRs with high iteration values
are being returned in typical responses, but may also be true if
the attacker can access the zone via AXFR or IXFR queries, or any
other methodology.
o 攻撃者はこれらのNSEC3 RRsの1つ以上に近づく手段を持っています。 典型的反応で高い繰り返し値があるNSEC3 RRsを返しているとき、また、AXFR、IXFR質問、またはいかなる他の方法論でも攻撃者がゾーンにアクセスできるなら本当であるかもしれないのを除いて、これは些細なことに本当です。
Laurie, et al. Standards Track [Page 31] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[31ページ]RFC5155NSEC3 March 2008
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.
また、大きい数の繰り返しを使用すると、追加サービスの否定の機会はサーバに対して取り入れられます、サーバが、数個が否定的であるかワイルドカード応答単位で論じ尽くすと見込まなければならないので。
12.2. Opt-Out Considerations
12.2. 問題を抜けさせてください。
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.
Opt出ているFlag(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 無記名の名前(存在か否かに関係なく)があるリソース記録は無記名のゾーンでRRsと同じ脆弱性に苦しみます。 これらの脆弱性はさらに詳細に[RFC3833]で説明されます(セクション2.3(「名前推論」とセクション2.6)が「ドメイン名の否定を認証した」と特に述べてください)。
o Resource records with signed names have the same security whether
or not Opt-Out is used.
o サインされた名前があるリソース記録には、外のOptが使用されているか否かに関係なく、同じセキュリティがあります。
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.
外のOptのあるなしにかかわらず不安定な代表団が攻撃者によってundetectablyに変更されるかもしれないことに注意してください。 これのために、安全に外のOptを使用するとき、第一の違いは外のOpt 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).
特に、これは、悪意がある実体が無記名の名前でRRsを挿入するか、または削除できるかもしれないことを意味します。 これらのRRsは通常NS RRsですが、また、これはサインされたワイルドカード拡大を含んでいます(ワイルドカードRR自身がサインされますが、拡張名前は無記名の名前です)。
Note that being able to add a delegation is functionally equivalent to being able to add any RR type: an attacker merely has to forge a delegation to name server under his/her control and place whatever RRs needed at the subzone apex.
どんなRRもタイプすると言い足すことができるのに代表団を加えることができるのが機能上同等であることに注意してください: RRsが「副-ゾーン」の頂点で何を必要としたとしても、攻撃者は単にその人のコントロールとところの下のネームサーバに代表団を鍛造しなければなりません。
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.
特定の場合では、この問題が重要な警備上の問題を提示していないかもしれない間、一般に、軽くそれを棄却するべきではありません。 したがって、強く、外のOptをあるRECOMMENDEDが節約して使ったということです。 ゾーン調印は、特に、外でOptを使用するのにSHOULD NOTデフォルトをツーリングして、全く外のOptを支持しないのを選ぶかもしれません。
Laurie, et al. Standards Track [Page 32] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[32ページ]RFC5155NSEC3 March 2008
12.3. Other Considerations
12.3. 他の問題
Walking the NSEC3 RRs will reveal the total number of RRs in the zone (plus empty non-terminals), and also what types there are. This could be mitigated by adding dummy entries, but certainly an upper limit can always be found.
NSEC3 RRsを押して行くのは、ゾーン(プラスの人影のない非端末)のRRsの総数を明らかにして、また、タイプがそこの者であることを明らかにするでしょう。 ダミーのエントリーを加えることによって、これを緩和できるでしょうが、確かに、いつも上限を見つけることができます。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.
Vixie、P.、トムソン、S.、Rekhter、Y.、およびJ.が縛った[RFC2136]、「ドメインネームシステムにおけるダイナミックなアップデート(DNSアップデート)」、RFC2136(1997年4月)。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2181] ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、1997年7月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2308] アンドリュース、M.、「DNS質問(DNS NCACHE)の否定的キャッシュ」、RFC2308、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問題部に書くためのガイドライン」BCP26、RFC2434(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問題」、BCP42、RFC2929、2000年9月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
Record (RR) Types", RFC 3597, September 2003.
[RFC3597]グスタファソン、A.、「未知のDNSリソース記録(RR)タイプの取り扱い」、RFC3597、2003年9月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D.,
and S. Rose, "DNS Security Introduction and
Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D.,
and S. Rose, "Resource Records for the DNS Security
Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.が上昇したと「リソースはDNSセキュリティ拡張子のために記録します」、RFC4034、2005年3月。
Laurie, et al. Standards Track [Page 33] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[33ページ]RFC5155NSEC3 March 2008
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D.,
and S. Rose, "Protocol Modifications for the DNS
Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends(R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、RFC4035、2005年3月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson、2006年10月のS.、「Base16、Base32、およびBase64データEncodings」RFC4648。
13.2. Informative References
13.2. 有益な参照
[DNSEXT-NO] Josefsson, S., "Authenticating Denial of Existence
in DNS with Minimum Disclosure", Work in Progress,
July 2000.
[DNSEXT-いいえ] Josefsson(「最小の公開があるDNSで存在の否定を認証する」S.)は進歩、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名前リダイレクション」、RFC2672、1999年8月。
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898,
September 2000.
[RFC2898]Kaliski、B.、「PKCS#5:」 パスワードベースの暗号仕様バージョン2インチ、RFC2898、2000年9月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the
Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833] アトキンスとD.とR.Austein、「ドメインネームシステム(DNS)の脅威分析」、RFC3833、2004年8月。
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain
Name System", RFC 4592, July 2006.
[RFC4592] ルイス、E.、「ドメインネームシステムにおけるワイルドカードの役割」、RFC4592、2006年7月。
[RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS
Security (DNSSEC) Opt-In", RFC 4956, July 2007.
[RFC4956] ArendsとR.とKosters、M.とD.Blacka、「DNSセキュリティ(DNSSEC)オプトイン」、RFC4956、2007年7月。
Laurie, et al. Standards Track [Page 34] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[34ページ]RFC5155NSEC3 March 2008
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 RRsを示しているゾーンです。 また、細切れ肉料理アルゴリズムにテストベクトルとしてそれらを使用できます。
The overall TTL and class are specified in the SOA RR, and are subsequently omitted for clarity.
総合的なTTLとクラスは、SOA RRで指定されて、次に、明快ために省略されます。
The zone is preceded by a list that contains the hashes of the original ownernames.
それが含むリストがゾーンに先行する、論じ尽くす、オリジナルの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.の例)は35mthgpgcu1qg68fab165klnsnk3dpvlと等しいです。 H(ai.example)はgjeqe526plbf1g8mklp59enfd789njgiと等しいです。 H(ns1.example)は2t7b4g4vsa5smi47k61mv5bv1a22bojrと等しいです。 H(ns2.example)はq04jkcevqvmu85r014c7dkba38o0ji5rと等しいです。 H(w.の例)はk8udemvp1j2f7eg6jebps17vp3n8i58hと等しいです。 H(*.w.例)はr53bq7cc2uvmubfu5ocmm6pers9tk9enと等しいです。 H(x.w.例)はb4um86eghhds6nea196smvmlo4ors995と等しいです。 H(y.w.例)はji6neoaepv8b5o6k4ev33abha8ht9fgcと等しいです。 H(x.のy.w.例)は2vptu5timamqttgl4luu9kg21e0aor3sと等しいです。 H(xx.example)はt644ebqk9bibcna874givr6joj62mlhvと等しいです。 H(2t7b4g4vsa5smi47k61mv5bv1a22bojr.example)。 = kohar7mbb8dc2ce8a9qvl8hon4k53uhiの例。 3600IN SOA ns1.example bugs.x.w.例。 1 3600 300( 3600000 3600 )RRSIG SOA7 1 3600 20150420235959 20051021000000( 40430の例。 Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd VI2LmKusbZsT0Q=) NS ns1.example。 NS ns2.example。 RRSIGナノ秒7 1 3600 20150420235959 20051021000000( 40430の例。 PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv CnMXjtz6SyObxA=) MX1xx.example。 RRSIG Mx7 1 3600 20150420235959 20051021000000( 40430の例。 GgQ1A9xs47k42VPvpL/a1BWUz/6XsnHkjotw 9So8MQtZtl2wJBsnOQsaoHrRCrRbyriEl/GZ n9Mto/Kx+wBo+w=) DNSKEY256 3 7AwEAAaetidLzsKWUt4swWR8yu0wPHPiUi8LU(sAD0QPWU+wzt89epO6tHzkMBVDkC7qphQO2h TY4hHn9npWFRw5BYubE=)
Laurie, et al. Standards Track [Page 35] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[35ページ]RFC5155NSEC3 March 2008
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 )
DNSKEY257 3 7AwEAAcUlFV1vhmqx6NSOUOq2R/dsR7Xm3upJ(j7IommWSpJABVfW8Q0rOvXdM6kzt+TAu92L9 AbsUdblMFin8CVF3n4s=)RRSIG DNSKEY7 1 3600 20150420235959( 20051021000000 12708の例。 AuU4juU9RaxescSmStrQks3Gh9FblGBlVU31 uzMZ/U/FpsUb8aC6QZS+sTsJXnLnz7flGOsm MGQZf3bH+QsCtg=) NSEC3PARAM1 0 12aabbccdd RRSIG NSEC3PARAM7 1 3600 20150420235959( 20051021000000 40430の例。 C1Gl8tPZNtnjlrYWDeeUV/sGLCyy/IHie2re rN05XSA3Pq0U3+4VvGWYWdUMfflOdxqnXHwJ TLQsjlkynhG6Cg=) 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example。 NSEC3 1 1 12aabbccdd(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.127RRSIG A7 2 3600 20150420235959 20051021000000(40430の例h6c++bzhRuWWt2bykN6mjaTNBcXNq5UuL5Ed K+iDP4eY8I0kSiKaCjg3tC1SQkeloMeub2GW k8p6xHMPZumXlw=)NSEC3 1 1 12aabbccdd(2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG)RRSIG NSEC3 7 2 3600 20150420235959 20051021000000( 40430の例。 OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq NI6mRk/r1dOSUw=) 2vptu5timamqttgl4luu9kg21e0aor3s.の例。 NSEC3 1 1 12aabbccdd(35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG)RRSIG NSEC3 7 2 3600 20150420235959 20051021000000( 40430の例。 KL1V2oFYghNV0Hm7Tf2vpJjM6l+0g1JCcVYG VfI0lKrhPmTsOA96cLEACgo1x8I7kApJX+ob TuktZ+sdsZPY1w=) 35mthgpgcu1qg68fab165klnsnk3dpvl.example。 NSEC3 1 1 12aabbccdd(b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG)
Laurie, et al. Standards Track [Page 36] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[36ページ]RFC5155NSEC3 March 2008
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.の例。 NS ns1.a.の例。 NS ns2.a.の例。 DS58470 5 1(3079F1593EBAD6DC121E202A8B766A6A4837206C)RRSIG DS7 2 3600 20150420235959 20051021000000( 40430の例。 XacFcQVHLVzdoc45EJhN616zQ4mEXtE8FzUh M2KWjfy1VfRKD9r1MeVGwwoukOKgJxBPFsWo o722vZ4UZ2dIdA=) ns1.a.の例。 192.0.2.5ns2.a.の例。 192.0 .2 .6 ai.example。 A192.0.2.9RRSIG A7 2 3600 20150420235959 20051021000000(40430の例hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+rznEn8sQ64UdqA=)HINFO「KLH-10インチ「ITS」RRSIG HINFO7 2 3600 20150420235959 20051021000000」( 40430の例。 Yi42uOq43eyO6qXHNvwwfFnIustWgV5urFcx enkLvs6pKRh00VBjODmf3Z4nMO7IOl6nHSQ1 v0wLHpEZG7Xj2w=) AAAA2001:db8:0: 0:0:0:f00:baa9 RRSIG AAAA7 2 3600 20150420235959 20051021000000( 40430の例。 LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG cHueLuXkMjBArQ=) b4um86eghhds6nea196smvmlo4ors995.example。 NSEC3 1 1 12aabbccdd(gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG)RRSIG NSEC3 7 2 3600 20150420235959 20051021000000( 40430の例。 ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh 5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3 pOv0TSTyiTxIZg=) c. 例。 NS ns1.c.の例。 NS ns2.c.の例ns1.c.の例。 192.0.2.7ns2.c.の例。 192.0 .2 .8 gjeqe526plbf1g8mklp59enfd789njgi.example。 NSEC3 1 1 12aabbccdd(ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA RRSIG)
Laurie, et al. Standards Track [Page 37] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[37ページ]RFC5155NSEC3 March 2008
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 12aabbccdd(k8udemvp1j2f7eg6jebps17vp3n8i58h)RRSIG NSEC3 7 2 3600 20150420235959 20051021000000(40430の例gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7 2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0 MpzVSKfTwx4uYA=)k8udemvp1j2f7eg6jebps17vp3n8i58h.の例。 NSEC3 1 1 12aabbccdd(kohar7mbb8dc2ce8a9qvl8hon4k53uhi)RRSIG NSEC3 7 2 3600 20150420235959 20051021000000( 40430の例。 FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt Otx7w9WfcIg62A=) kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example。 NSEC3 1 1 12aabbccdd(q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG)RRSIG NSEC3 7 2 3600 20150420235959 20051021000000( 40430の例。 VrDXs2uVW21N08SyQIz88zml+y4ZCInTwgDr 6zz43yAg+LFERjOrj3Ojct51ac7Dp4eZbf9F QJazmASFKGxGXg=) ns1.example。 192.0.2.1RRSIG A7 2 3600 20150420235959 20051021000000(40430の例bu6kx73n6XEunoVGuRfAgY7EF/AJqHy7hj0j kiqJjB0dOrx3wuz9SaBeGfqWIdn/uta3SavN 4FRvZR9SCFHF5Q=)ns2.example。 192.0.2.2RRSIG A7 2 3600 20150420235959 20051021000000(40430の例ktQ3TqE0CfRfki0Rb/Ip5BM0VnxelbuejCC4 zpLbFKA/7eD7UNAwxMgxJPtbdST+syjYSJaj 4IHfeX6n8vfoGA=)q04jkcevqvmu85r014c7dkba38o0ji5r.の例。 NSEC3 1 1 12aabbccdd(r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG)RRSIG NSEC3 7 2 3600 20150420235959 20051021000000(40430の例hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3 ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN NlkxWcLsIlMmUg=)
Laurie, et al. Standards Track [Page 38] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[38ページ]RFC5155NSEC3 March 2008
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 12aabbccdd(t644ebqk9bibcna874givr6joj62mlhv MX RRSIG)RRSIG NSEC3 7 2 3600 20150420235959 20051021000000(40430の例aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+HF1FWKW7RIJdtQ=)t644ebqk9bibcna874givr6joj62mlhv.example。 NSEC3 1 1 12aabbccdd(0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA RRSIG)RRSIG NSEC3 7 2 3600 20150420235959 20051021000000( 40430の例。 RAjGECB8P7O+F4Pa4Dx3tC0M+Z3KmlLKImca fb9XWwx+NWUNz7NBEDBQHivIyKPVDkChcePI X1xPl1ATNa+8Dw=) *.w.の例。 MX1ai.example。 RRSIG Mx7 2 3600 20150420235959 20051021000000( 40430の例。 CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb 9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM ivEBP6+4KS3ldA== ) x. w. 例。 MX1xx.example。 RRSIG Mx7 3 3600 20150420235959 20051021000000( 40430の例。 IrK3tq/tHFIBF0scHiE/1IwMAvckS/55hAVv QyxTFbkAdDloP3NbZzu+yoSsr3b3OX6qbBpY 7WCtwwekLKRAwQ=) x. y. w. 例。 MX1xx.example。 RRSIG Mx7 4 3600 20150420235959 20051021000000( 40430の例。 MqSt5HqJIN8+SLlzTOImrh5h9Xa6gDvAW/Gn nbdPc6Z7nXvCpLPJj/5lCwx3VuzVOjkbvXze 8/8Ccl2Zn2hbug=) xx.example。 A192.0.2.10RRSIG A7 2 3600 20150420235959 20051021000000( 40430の例。 T35hBWEZ017VC5u2c4OriKyVn/Pu+fVK4AlX YOxJ6iQylfV2HQIKjv6b7DzINB3aF/wjJqgX pQvhq+Ac6+ZiFg=) HINFO、「KLH-10インチは「RRSIG HINFO7 2 3600 20150420235959 20051021000000を-何20インチも上回っています」。( 40430の例。 KimG+rDd+7VA1zRsu0ITNAQUTRlpnsmqWrih FRnU+bRa93v2e5oFNFYCs3Rqgv62K93N7AhW 6Jfqj/8NzWjvKg=) AAAA2001:db8:0: 0:0:0:f00:baaa
Laurie, et al. Standards Track [Page 39] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[39ページ]RFC5155NSEC3 March 2008
RRSIG AAAA 7 2 3600 20150420235959 20051021000000 (
40430 example.
IXBcXORITNwd8h3gNwyxtYFvAupS/CYWufVe
uBUX0O25ivBCULjZjpDxFSxfohb/KA7YRdxE
NzYfMItpILl/Xw== )
RRSIG AAAA7 2 3600 20150420235959 20051021000000( 40430の例。 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.
このセクションの例は、Appendix 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 RRsは名前が存在していなくて、広げられるべきであったワイルドカードがないRRがあると立証します。
;; Header: QR AA DO RCODE=3 ;; ;; Question a.c.x.w.example. IN A
;; ヘッダー: QR AAはRCODE=3をします。 ;; 交流のx.w.例に質問してください。 Aで
;; Answer ;; (empty)
;; 答えてください。 (空)です。
;; Authority
;; 権威
example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
3600000 3600 )
example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
40430 example.
Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
VI2LmKusbZsT0Q== )
例。 SOA ns1.example bugs.x.w.例。 1 3600年の300( 3600000 3600 )例。 RRSIG SOA7 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.例)をカバーするNSEC3 RR。 H(c.のx.w.例)は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 12aabbccdd(2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG)0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example。 RRSIG NSEC3 7 2 3600( 20150420235959 20051021000000 40430の例。 OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762 BOCXJZMnpuwhpA== )
Laurie, et al. Standards Track [Page 40] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[40ページ]RFC5155NSEC3 March 2008
;; NSEC3 RR that matches the closest encloser (x.w.example) ;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
;; 最も近いencloser(x.w.例)に合っているNSEC3 RR。 H(x.w.例)は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 12aabbccdd(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.例)にワイルドカードを覆うNSEC3 RR。 H(*.x.w.例)は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 12aabbccdd(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.
質問は要求されたデータが存在していなくて、またワイルドカード拡大が全く適用されないと立証する3NSEC3 RRsを返しました。 否定応答は、NSEC3 RRsについて確かめることによって、認証されます。 対応するRRSIGsは、NSEC3 RRsがアルゴリズム7とキー・タグ40430で「例」DNSKEYによってサインされるのを示します。 レゾルバは、この答えを認証するために対応するDNSKEY RRを必要とします。
One of the owner names of the NSEC3 RRs matches the closest encloser. One of the NSEC3 RRs prove that there exists no longer name. One of the NSEC3 RRs prove that there exists no wildcard RRSets that should have been expanded. The closest encloser can be found by applying the algorithm in Section 8.3.
所有者名(NSEC3 RRs)の1つは最も近いencloserに合っています。 NSEC3 RRsの1つは、名前がもう存在しないと立証します。 NSEC3 RRsの1つは、広げられるべきであったワイルドカードがないRRSetsが存在すると立証します。 セクション8.3でアルゴリズムを適用することによって、最も近いencloserを見つけることができます。
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.例'が'b4um86eghhds6nea196smvmlo4ors995'に論じ尽くす名前で。 これは、最も近いencloserであるかもしれないことを示します。 'その'c.x.w.の例'と'*.x.w.例'を立証するために、存在するな、そうしないて、これらの名前が論じ尽くされる、それぞれ'、0va5bpr2ou0vk0lbqeeljri88laipsfhと''92pqneegtaue7pjatc3l3qnk738c6v5m'。 1番目と最後のNSEC3 RRsは、これらの論じ尽くされた所有者名が存在しないと立証します。
Laurie, et al. Standards Track [Page 41] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[41ページ]RFC5155NSEC3 March 2008
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は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.例。 1 3600年の300( 3600000 3600 )例。 RRSIG SOA7 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 12aabbccdd(2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG)2t7b4g4vsa5smi47k61mv5bv1a22bojr.example。 RRSIG NSEC3 7 2 3600( 20150420235959 20051021000000 40430の例。 OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq 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"に)、唯一の要求されたRRタイプは、存在していなくて(タイプMXはNSEC3 RRのタイプコードリストで欠けています)、またCNAME(また、タイプCNAMEもNSEC3 RRのタイプコードリストで欠けている)ではありませんでした。
Laurie, et al. Standards Track [Page 42] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[42ページ]RFC5155NSEC3 March 2008
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はRCODE=0をします。 ;; y.w.例に質問してください。 Aで
;; Answer ;; (empty)
;; 答えてください。 (空)です。
;; Authority
example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
3600000 3600 )
example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
40430 example.
Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
VI2LmKusbZsT0Q== )
;; 権威の例。 SOA ns1.example bugs.x.w.例。 1 3600年の300( 3600000 3600 )例。 RRSIG SOA7 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を合わせて、Aタイプビットが設定されないのを示します。
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 12aabbccdd(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を返しました。(「y.w.例」、論じ尽くす、"ji6neoaepv8b5o6k4ev33abha8ht9fgc"に)、要求されたRRタイプだけが存在していません(タイプAはNSEC3 RRのType Bit Maps分野で欠けています)。 これがNSECsを使用する空の非端末証拠と異なってどんなData Errorとも同じでないことに注意してください。 この例は、完全になるように唯一言及されます。
Laurie, et al. Standards Track [Page 43] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[43ページ]RFC5155NSEC3 March 2008
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 RRsは、この代表団のための何もサインされなかったと立証します。 無記名の代表団が存在するという証拠が全くありません。
;; Header: QR DO RCODE=0 ;; ;; Question mc.c.example. IN MX
;; ヘッダー: QRはRCODE=0をします。 ;; mc.c.の例に質問してください。 Mxで
;; Answer ;; (empty)
;; 答えてください。 (空)です。
;; Authority
c.example. NS ns1.c.example.
NS ns2.c.example.
;; 権威c.の例。 NS ns1.c.の例。 NS ns2.c.の例。
;; NSEC3 RR that covers the "next closer" name (c.example) ;; H(c.example) = 4g6p9u5gvfshp30pqecj98b3maqbn1ck
;; 「次に、より近い」という名前(c.の例)をカバーするNSEC3 RR。 H(c.の例)は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 12aabbccdd(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 12aabbccdd(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.の例。 192.0.2.7ns2.c.の例。 A192.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"
質問は無記名の「c.の例」に紹介を返しました。帯状になってください。 応答は「c.の例」の細切れ肉料理以来の「例」である「c.の例」の最も近い証明可能なencloserを含んでいます。
Laurie, et al. Standards Track [Page 44] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[44ページ]RFC5155NSEC3 March 2008
("4g6p9u5gvfshp30pqecj98b3maqbn1ck") is covered by the first NSEC3 RR
and its Opt-Out bit is set.
("4g6p9u5gvfshp30pqecj98b3maqbn1ck")は最初のNSEC3 RRで覆われています、そして、外のOptビットは設定されます。
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 RRSetでのラベルカウントは、ワイルドカードRRSetがこの応答を起こすために広げられたのを示します、そして、NSEC3 RRは「次に、より近い」という名前が全くゾーンに存在しないと立証します。
;; Header: QR AA DO RCODE=0 ;; ;; Question a.z.w.example. IN MX
;; ヘッダー: QR AAはRCODE=0をします。 ;; a.のz.w.例に質問してください。 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.例に答えてください。 MX1ai.example a. z. w. 例。 RRSIG Mx7 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ナノ秒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.例)をカバーするNSEC3 RR。 H(z.w.例)は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.の例。 NSEC3 1 1 12aabbccdd(r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG)q04jkcevqvmu85r014c7dkba38o0ji5r.の例。 RRSIG NSEC3 7 2 3600(20150420235959 20051021000000 40430の例hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3 ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN NlkxWcLsIlMmUg=)
Laurie, et al. Standards Track [Page 45] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[45ページ]RFC5155NSEC3 March 2008
;; 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 A7 2 3600 20150420235959 20051021000000(40430の例hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+rznEn8sQ64UdqA=)ai.example。 AAAA2001:db8:0: 0:0:0:f00:baa9 ai.example。 RRSIG AAAA7 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応答であるように答え部はRRSetが広げたワイルドカードを含みます。 2のRRSIG Labels分野価値は、答えがワイルドカード拡大の結果であることを示します、「a.のz.w.例」名が4個のラベルを含むとき。 また、これは、最も近いencloserに合っているNSEC3 RRの必要は存在しているので全くないのをその「w.の例」に示します。
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 RRsは合っているワイルドカード名には要求されたタイプの少しのRRsもなくて、またどんなより近いマッチもゾーンに存在しないと立証します。
;; Header: QR AA DO RCODE=0 ;; ;; Question a.z.w.example. IN AAAA
;; ヘッダー: QR AAはRCODE=0をします。 ;; a.のz.w.例に質問してください。 AAAAで
;; Answer ;; (empty)
;; 答えてください。 (空)です。
;; Authority
example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
3600000 3600 )
example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
40430 example.
Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
VI2LmKusbZsT0Q== )
;; 権威の例。 SOA ns1.example bugs.x.w.例。 1 3600年の300( 3600000 3600 )例。 RRSIG SOA7 1 3600 20150420235959 20051021000000( 40430の例。 Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd VI2LmKusbZsT0Q=)
Laurie, et al. Standards Track [Page 46] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[46ページ]RFC5155NSEC3 March 2008
;; NSEC3 RR that matches the closest encloser (w.example) ;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
;; 最も近いencloser(w.の例)に合っているNSEC3 RR。 H(w.の例)はk8udemvp1j2f7eg6jebps17vp3n8i58hと等しいです。
k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
k8udemvp1j2f7eg6jebps17vp3n8i58h.example. RRSIG NSEC3 7 2 3600 (
20150420235959 20051021000000 40430 example.
FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK
S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt
Otx7w9WfcIg62A== )
k8udemvp1j2f7eg6jebps17vp3n8i58h.の例。 NSEC3 1 1 12aabbccdd(kohar7mbb8dc2ce8a9qvl8hon4k53uhi)k8udemvp1j2f7eg6jebps17vp3n8i58h.の例。 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.例)をカバーするNSEC3 RR。 H(z.w.例)は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.の例。 NSEC3 1 1 12aabbccdd(r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG)q04jkcevqvmu85r014c7dkba38o0ji5r.の例。 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.例)は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 12aabbccdd(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.
質問は要求されたデータが存在していなくて、ワイルドカードがないRRが適用すると立証するNSEC3 RRsを返しました。
Laurie, et al. Standards Track [Page 47] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[47ページ]RFC5155NSEC3 March 2008
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は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.例。 1 3600年の300( 3600000 3600 )例。 RRSIG SOA7 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 12aabbccdd(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はSOA RRの存在を示します、このNSEC3 RRが親のゾーンカットからあるのではなく、子供の頂点から来ているのを示して。 親サーバ(この場合、ルートサーバーである)に「例」DS RRSetのための質問を送るべきです。
Appendix C. Special Considerations
付録のC.の特別な問題
The following paragraphs clarify specific behavior and explain special considerations for implementations.
以下のパラグラフで、特異的行動をはっきりさせて、実現のために特別な問題がわかります。
Laurie, et al. Standards Track [Page 48] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[48ページ]RFC5155NSEC3 March 2008
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.
最初の所有者を増大させると、塩で、増加を論じ尽くす前に、プレ発生しているハッシュ値の辞書の費用は命名されます。 塩のあらゆるかけらのために、前計算された辞書の費用は倍増します(それぞれの可能な塩の値に結合された各単語のためのエントリーがあるに違いないので)。 2^2040に費用を掛けて、NSEC3 RRは塩の最大2040個のかけら(255の八重奏)を使用できます。 これは塩を変えるたびに攻撃者が実際にはそうしなければならなくて、recomputeが辞書であることを意味します。
Including a salt, regardless of size, does not affect the cost of constructing NSEC3 RRs. It does increase the size of the NSEC3 RR.
サイズにかかわらず塩を含んでいるのはNSEC3 RRsを組み立てる費用に影響しません。 それはNSEC3 RRのサイズを増加させます。
There MUST be at least one complete set of NSEC3 RRs for the zone using the same salt value.
同じ塩の値を使用するゾーンへのNSEC3 RRsの完全な少なくとも1セットがあるに違いありません。
The salt SHOULD be changed periodically to prevent pre-computation using a single salt. It is RECOMMENDED that the salt be changed for every re-signing.
SHOULDに塩味を付けさせてください。変えて、単一の塩を使用することで定期的にプレ計算を防いでください。 あらゆる再契約単位で塩を変えるのは、RECOMMENDEDです。
Note that this could cause a resolver to see RRs with different salt values for the same zone. This is harmless, since each RR stands alone (that is, it denies the set of owner names whose hashes, using the salt in the NSEC3 RR, fall between the two hashes in the NSEC3 RR) -- it is only the server that needs a complete set of NSEC3 RRs with the same salt in order to be able to answer every possible query.
レゾルバがこれで異なった塩の値があるRRsを同じゾーンに見ることができたことに注意してください。 これは無害です、各RRが単独で立つので。(それがそう、所有者のセットがだれのものを命名することを否定する、論じ尽くす、NSEC3 RRで塩を使用することでの間に2が中でNSEC3 RRを論じ尽くす秋) --あらゆる可能な質問に唯一の答えるのは、できるために同じ塩でNSEC3 RRsの完全なセットを必要とするサーバです。
There is no prohibition with having NSEC3 RRs with different salts within the same zone. However, in order for authoritative servers to be able to consistently find covering NSEC3 RRs, the authoritative server MUST choose a single set of parameters (algorithm, salt, and iterations) to use when selecting NSEC3 RRs.
同じゾーンの中に異なった塩がある状態でNSEC3 RRsを持つ禁止が全くありません。 しかしながら、正式のサーバが一貫して覆いNSEC3 RRsを見つけることができるように、正式のサーバはNSEC3 RRsを選択するとき使用する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.
異なったメッセージに同じハッシュ値があるとき、細切れ肉料理衝突は起こります。 ただ一つの衝突の2機会における1を与えるのに必要であるドメイン名の予想された数はnビット(すなわち、SHA-1のための2^80)の長さの細切れ肉料理のためのおよそ2^(n/2)です。 この確率は非常に低いのですが、攻撃が細切れ肉料理を使用する場合、可能な衝突を避けて、評価との以下のパラグラフ取引は衝突を破損します。
Laurie, et al. Standards Track [Page 49] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[49ページ]RFC5155NSEC3 March 2008
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 RRsの世代の間、ハッシュ値は推定上ユニークです。 衝突発生の(アカデミック)の場合では、代替の塩を選ばなければなりません、そして、すべてのハッシュ値を作り直さなければなりません。
C.2.2. Second Preimage Requirement Analysis
C.2.2。 第2Preimage要件分析
A cryptographic hash function has a second-preimage resistance property. The second-preimage resistance property means that it is computationally infeasible to find another message with the same hash value as a given message, i.e., given preimage X, to find a second preimage X' != X such that hash(X) = hash(X'). The work factor for finding a second preimage is of the order of 2^160 for SHA-1. To mount an attack using an existing NSEC3 RR, an adversary needs to find a second preimage.
暗号のハッシュ関数に、2番目-「前-イメージ」抵抗の特性があります。 'preimage Xを考えて、2番目-「前-イメージ」抵抗の特性が、'第2のpreimage Xが=Xであることがわかるためにすなわち、与えられたメッセージと同じハッシュ値で別のメッセージを見つけるのが計算上実行不可能であることを意味するので、細切れ肉料理(X)は細切れ肉料理(X')と等しいです。 2番目の「前-イメージ」を見つけるためのワーク・ファクタはSHA-1のための2^160の注文のものです。 既存のNSEC3 RRを使用することで攻撃を開始するために、敵は、2番目の「前-イメージ」を見つける必要があります。
Assuming an adversary is capable of mounting such an extreme attack, the actual damage is that a response message can be generated that claims that a certain QNAME (i.e., the second pre-image) does exist, while in reality QNAME does not exist (a false positive), which will either cause a security-aware resolver to re-query for the non- existent name, or to fail the initial query. Note that the adversary can't mount this attack on an existing name, but only on a name that the adversary can't choose and that does not yet exist.
敵がそのような極端な攻撃を仕掛けることができると仮定して、実質的損害賠償金はあるQNAME(すなわち、2番目のプレイメージ)が存在すると主張する応答メッセージが発生できるということです、ほんとうはQNAME(再質問するセキュリティ意識しているレゾルバが非目下の名前か初期の質問に失敗することを引き起こす)は存在していませんが(無病誤診)。 敵が既存の名前、しかし、単に敵が選ぶことができない名前に対するまだ存在していないこの攻撃を仕掛けることができないことに注意してください。
Laurie, et al. Standards Track [Page 50] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[50ページ]RFC5155NSEC3 March 2008
Authors' Addresses
作者のアドレス
Ben Laurie Nominet 17 Perryn Road London W3 7LR England
ベンローリーNominet17Perryn道路ロンドンW3 7LRイギリス
Phone: +44 20 8735 0686 EMail: ben@links.org
以下に電話をしてください。 +44 20 8735 0686はメールされます: ben@links.org
Geoffrey Sisson Nominet Minerva House Edmund Halley Road Oxford Science Park Oxford OX4 4DQ UNITED KINGDOM
ジェフリー・シスン・Nominetミネルバ・下院エドモンド・ハレー・RoadオックスフォードサイエンスパークオックスフォードOX4 4DQイギリス
Phone: +44 1865 332211 EMail: geoff-s@panix.com
以下に電話をしてください。 +44 1865 332211はメールされます: geoff-s@panix.com
Roy Arends Nominet Minerva House Edmund Halley Road Oxford Science Park Oxford OX4 4DQ UNITED KINGDOM
ロイ・Arends Nominetミネルバ・下院エドモンド・ハレー・RoadオックスフォードサイエンスパークオックスフォードOX4 4DQイギリス
Phone: +44 1865 332211 EMail: roy@nominet.org.uk
以下に電話をしてください。 +44 1865 332211はメールされます: roy@nominet.org.uk
David Blacka VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US
デヴィッドBlackaベリサインInc.21355屋根の頂円のヴァージニア20166ダレス(米国)
Phone: +1 703 948 3200 EMail: davidb@verisign.com
以下に電話をしてください。 +1 3200年の703 948メール: davidb@verisign.com
Laurie, et al. Standards Track [Page 51] RFC 5155 NSEC3 March 2008
ローリー、他 標準化過程[51ページ]RFC5155NSEC3 March 2008
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Laurie, et al. Standards Track [Page 52]
ローリー、他 標準化過程[52ページ]
一覧
スポンサーリンク
