[要約] RFC 7129は、DNSにおける認証済みの存在否定を扱ったものであり、DNSセキュリティの向上を目的としています。
Independent Submission R. Gieben
Request for Comments: 7129 Google
Category: Informational W. Mekking
ISSN: 2070-1721 NLnet Labs
February 2014
Authenticated Denial of Existence in the DNS
DNSでの認証済み存在拒否
Abstract
概要
Authenticated denial of existence allows a resolver to validate that a certain domain name does not exist. It is also used to signal that a domain name exists but does not have the specific resource record (RR) type you were asking for. When returning a negative DNS Security Extensions (DNSSEC) response, a name server usually includes up to two NSEC records. With NSEC version 3 (NSEC3), this amount is three.
認証された存在拒否により、リゾルバーは特定のドメイン名が存在しないことを検証できます。また、ドメイン名は存在するが、要求していた特定のリソースレコード（RR）タイプがないことを示すためにも使用されます。否定的なDNS Security Extensions（DNSSEC）応答を返す場合、ネームサーバーには通常、最大2つのNSECレコードが含まれます。 NSECバージョン3（NSEC3）では、この量は3です。
This document provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial-of-existence responses.
このドキュメントでは、認証された存在拒否応答を提供するためにDNSSECが使用するNSECおよびNSEC3メカニズムに関する追加の背景解説といくつかのコンテキストを提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7129.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7129で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. Denial of Existence .............................................4
2.1. NXDOMAIN Responses .........................................4
2.2. NODATA Responses ...........................................5
3. Secure Denial of Existence ......................................6
3.1. NXT ........................................................7
3.2. NSEC .......................................................7
3.3. NODATA Responses ...........................................9
3.4. Drawbacks of NSEC .........................................10
4. Experimental and Deprecated Mechanisms: NO, NSEC2, and DNSNR ...11
5. NSEC3 ..........................................................12
5.1. Opt-Out ...................................................14
5.2. Loading an NSEC3 Zone .....................................15
5.3. Wildcards in the DNS ......................................15
5.4. CNAME Records .............................................18
5.5. The Closest Encloser NSEC3 Record .........................19
5.6. Three to Tango ............................................24
6. Security Considerations ........................................25
7. Acknowledgments ................................................25
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................26
Appendix A. Online Signing: Minimally Covering NSEC Records .......28
Appendix B. Online Signing: NSEC3 White Lies ......................29
Appendix C. List of Hashed Owner Names ............................29
DNSSEC can be somewhat of a complicated matter, and there are certain areas of the specification that are more difficult to comprehend than others. One such area is "authenticated denial of existence".
DNSSECはやや複雑な問題になる可能性があり、仕様の中には、他のものよりも理解するのが難しい特定の領域があります。そのような分野の1つが「認証された存在の拒否」です。
Denial of existence is a mechanism that informs a resolver that a certain domain name does not exist. It is also used to signal that a domain name exists but does not have the specific RR type you were asking for.
存在の拒否は、特定のドメイン名が存在しないことをリゾルバに通知するメカニズムです。また、ドメイン名は存在するが、要求していた特定のRRタイプがないことを示すためにも使用されます。
The first is referred to as a nonexistent domain (NXDOMAIN) ([RFC2308], Section 2.1) and the latter as a NODATA ([RFC2308], Section 2.2) response. Both are also known as negative responses.
前者は存在しないドメイン（NXDOMAIN）（[RFC2308]、セクション2.1）と呼ばれ、後者はNODATA（[RFC2308]、セクション2.2）応答と呼ばれます。どちらも否定的な応答として知られています。
Authenticated denial of existence uses cryptography to sign the negative response. However, if there is no answer, what is it that needs to be signed? To further complicate this matter, there is the desire to pre-generate negative responses that are applicable for all queries for nonexistent names in the signed zone. See Section 3 for the details.
認証された存在拒否では、暗号を使用して否定応答に署名します。しかし、答えがない場合、署名する必要があるのは何ですか？この問題をさらに複雑にするために、署名済みゾーンに存在しない名前に対するすべてのクエリに適用できる否定応答を事前に生成したいという要望があります。詳細については、セクション3を参照してください。
In this document, we will explain how authenticated denial of existence works. We begin by explaining the current technique in the DNS and work our way up to DNSSEC. We explain the first steps taken in DNSSEC and describe how NSEC and NSEC3 work. The NXT, NO, NSEC2, and DNSNR records also briefly make their appearance, as they have paved the way for NSEC and NSEC3.
このドキュメントでは、認証された存在の拒否がどのように機能するかを説明します。最初にDNSの現在の手法を説明し、DNSSECまで進みます。 DNSSECで行われる最初のステップを説明し、NSECとNSEC3がどのように機能するかを説明します。 NXT、NO、NSEC2、およびDNSNRレコードも、NSECおよびNSEC3への道を開いたため、簡単に登場します。
To complete the picture, we also need to explain DNS wildcards as these complicate matters, especially when combined with CNAME records.
詳細を説明するには、DNSワイルドカードについても説明する必要があります。これは、特にCNAMEレコードと組み合わせる場合に、これらの問題が複雑になるためです。
Note: In this document, domain names in zone file examples will have a trailing dot, but in the running text they will not. This text is written for people who have a fair understanding of DNSSEC. The following RFCs are not required reading, but they help in understanding the problem space. o [RFC5155] -- DNS Security (DNSSEC) Hashed Authenticated Denial of Existence;
注：このドキュメントでは、ゾーンファイルの例のドメイン名には末尾にドットがありますが、実行中のテキストにはありません。このテキストは、DNSSECを十分に理解している人向けに書かれています。以下のRFCは読む必要はありませんが、問題の領域を理解するのに役立ちます。 o [RFC5155]-DNSセキュリティ（DNSSEC）ハッシュ認証済み存在拒否。
o [RFC4592] -- The Role of Wildcards in the Domain Name System.
o [RFC4592]-ドメインネームシステムにおけるワイルドカードの役割。
And, these provide some general DNSSEC information.
そして、これらはいくつかの一般的なDNSSEC情報を提供します。
o [RFC4033], [RFC4034], and [RFC4035] -- DNSSEC specifications;
o [RFC4033]、[RFC4034]、および[RFC4035]-DNSSEC仕様。
o [RFC4956] -- DNS Security (DNSSEC) Opt-In. This RFC has an Experimental status but is a good read.
o [RFC4956]-DNSセキュリティ（DNSSEC）オプトイン。このRFCには試験運用ステータスがありますが、よく読んでください。
These three documents give some background information on the NSEC3 development.
これら3つのドキュメントは、NSEC3開発に関する背景情報を提供します。
o The NO record [DNSEXT];
o NOレコード[DNSEXT];
o The NSEC2 record [DNSEXT-NSEC2];
o NSEC2レコード[DNSEXT-NSEC2];
o The DNSNR record [DNSNR-RR].
o DNSNRレコード[DNSNR-RR]。
We start with the basics and take a look at NXDOMAIN handling in the DNS. To make it more visible, we are going to use a small DNS zone with three names ("example.org", "a.example.org", and "d.example.org") and four types (SOA, NS, A, and TXT). For brevity, the class is not shown (defaults to IN) and the SOA record is shortened, resulting in the following zone file:
基本から始めて、DNSでのNXDOMAIN処理を見てみましょう。わかりやすくするために、3つの名前（ "example.org"、 "a.example.org"、および "d.example.org"）と4つのタイプ（SOA、NS、 A、およびTXT）。簡潔にするために、クラスは表示されず（デフォルトはIN）、SOAレコードが短縮され、次のゾーンファイルになります。
example.org. SOA ( ... ) example.org. NS a.example.org. a.example.org. A 192.0.2.1 TXT "a record" d.example.org. A 192.0.2.1 TXT "d record"
example.org。 SOA（...）example.org。 NS a.example.org。 a.example.org。 192.0.2.1 TXT「レコード」d.example.org。 192.0.2.1 TXT "dレコード"
Figure 1: The Unsigned "example.org" Zone
図1：未署名の「example.org」ゾーン
If a resolver asks the name server serving this zone for the TXT type belonging to "a.example.org", it sends the following question: "a.example.org TXT".
リゾルバーがこのゾーンにサービスを提供するネームサーバーに「a.example.org」に属するTXTタイプを要求すると、「a.example.org TXT」という質問が送信されます。
The name server looks in its zone data and generates an answer. In this case, a positive one: "Yes, it exists and this is the data", resulting in this reply:
ネームサーバーは、ゾーンデータを調べて回答を生成します。この場合、肯定的なもの：「はい、それは存在し、これはデータです」の結果、次の応答が返されます。
;; status: NOERROR, id: 28203
;; ANSWER SECTION: a.example.org. TXT "a record"
;;回答セクション：a.example.org。 TXT「レコード」
;; AUTHORITY SECTION: example.org. NS a.example.org.
;;権限セクション：example.org。 NS a.example.org。
The "status: NOERROR" signals that everything is OK, and the "id" is an integer used to match questions and answers. In the ANSWER section, we find our answer. The AUTHORITY section holds the names of the name servers that have information concerning the "example.org" zone. Note that including this information is optional.
「ステータス：NOERROR」はすべてが正常であることを示し、「id」は質問と回答の照合に使用される整数です。回答のセクションで、答えを見つけます。 AUTHORITYセクションは、 "example.org"ゾーンに関する情報を持つネームサーバーの名前を保持します。この情報を含めることはオプションであることに注意してください。
If a resolver asks for "b.example.org TXT", it gets an answer that this name does not exist:
リゾルバーが「b.example.org TXT」を要求すると、この名前が存在しないという回答が得られます。
;; status: NXDOMAIN, id: 7042
;; AUTHORITY SECTION: example.org. SOA ( ... )
;;権限セクション：example.org。 SOA（...）
In this case, we do not get an ANSWER section, and the status is set to NXDOMAIN. From this, the resolver concludes that "b.example.org" does not exist. The AUTHORITY section holds the SOA record of "example.org" that the resolver can use to cache the negative response.
この場合、ANSWERセクションは取得されず、ステータスはNXDOMAINに設定されます。このことから、リゾルバは「b.example.org」が存在しないと結論付けています。 AUTHORITYセクションには、リゾルバーが否定応答をキャッシュするために使用できる「example.org」のSOAレコードが保持されています。
It is important to realize that NXDOMAIN is not the only type of does-not-exist response. A name may exist, but the type you are asking for may not. This occurrence of nonexistence is called a NODATA response. Let us ask our name server for "a.example.org AAAA" and look at the answer:
NXDOMAINが存在しない応答の唯一のタイプではないことを認識することが重要です。名前は存在するかもしれませんが、あなたが求めているタイプは存在しないかもしれません。この非存在の発生は、NODATA応答と呼ばれます。ネームサーバーに「a.example.org AAAA」を要求して、答えを見てみましょう。
;; status: NOERROR, id: 7944
;; AUTHORITY SECTION: example.org. SOA ( ... )
;;権限セクション：example.org。 SOA（...）
The status NOERROR shows that the "a.example.org" name exists, but the reply does not contain an ANSWER section. This differentiates a NODATA response from an NXDOMAIN response; the rest of the packet is very similar. The resolver has to put these pieces of information together and conclude that "a.example.org" exists, but it does not have a "AAAA" record.
ステータスNOERRORは、「a.example.org」の名前は存在するが、応答にANSWERセクションが含まれていないことを示しています。これにより、NODATA応答とNXDOMAIN応答が区別されます。パケットの残りの部分は非常に似ています。リゾルバーはこれらの情報を組み合わせて、「a.example.org」が存在すると結論付ける必要がありますが、「AAAA」レコードがありません。
The above has to be translated to the security-aware world of DNSSEC. But, there are a few principles DNSSEC brings to the table:
上記は、セキュリティを意識したDNSSECの世界に翻訳する必要があります。しかし、DNSSECがもたらすいくつかの原則があります。
1. A name server is free to compute the answer and signature(s) on the fly, but the protocol is written with a "first sign, then load" attitude in mind. It is rather asymmetrical, but a lot of the design in DNSSEC stems from fact that you need to accommodate authenticated denial of existence. If the DNS did not have NXDOMAIN, DNSSEC would be a lot simpler, but a lot less useful!
1. ネームサーバーは回答と署名をその場で自由に計算できますが、プロトコルは「最初の署名、次に読み込み」という考え方で作成されています。これはかなり非対称ですが、DNSSECの設計の多くは、認証された存在の拒否に対応する必要があるという事実に基づいています。 DNSにNXDOMAINがなかった場合、DNSSECはかなり単純になりますが、あまり役に立ちません。
2. The DNS packet header is not signed. This means that a "status: NXDOMAIN" cannot be trusted. In fact, the entire header may be forged, including the AD bit (AD stands for Authentic Data; see [RFC3655]), which may give some food for thought;
2. DNSパケットヘッダーは署名されていません。つまり、「status：NXDOMAIN」は信頼できません。実際、ADビット（ADはAuthentic Dataを表します。[RFC3655]を参照）を含め、ヘッダー全体が偽造されている可能性があり、これにより検討の余地があります。
3. DNS wildcards and CNAME records complicate matters significantly. See more about this later in Sections 5.3 and 5.4.
3. DNSワイルドカードとCNAMEレコードは問題を非常に複雑にします。これについては、セクション5.3および5.4で詳しく説明します。
The first principle implies that all denial-of-existence answers need to be precomputed, but it is impossible to precompute (all conceivable) nonexistence answers.
最初の原則は、すべての存在拒否の回答を事前に計算する必要があることを意味しますが、（考えられるすべての）存在しない回答を事前に計算することは不可能です。
A generic denial record that can be used in all denial-of-existence proofs is not an option: such a record is susceptible to replay attacks. When you are querying a name server for any record that actually exists, a man in the middle could replay that generic denial record that is unlimited in its scope, and it would be impossible to tell whether the response was genuine or spoofed. In other words, the generic record can be replayed to falsely deny _all_ possible responses.
すべての存在拒否の証明で使用できる一般的な拒否レコードはオプションではありません。そのようなレコードはリプレイ攻撃を受けやすいです。ネームサーバーに実際に存在するレコードを照会する場合、中間の人がその範囲が無制限のその一般的な拒否レコードを再生する可能性があり、応答が本物であるか偽装されているかを判別することは不可能です。つまり、汎用レコードを再生して、考えられるすべての応答を誤って拒否することができます。
We could also use the QNAME in the answer and sign that, essentially signing an NXDOMAIN response. While this approach could have worked technically, it is incompatible with offline signing.
回答でQNAMEを使用して署名することもでき、基本的にはNXDOMAIN応答に署名します。このアプローチは技術的には機能したかもしれませんが、オフライン署名と互換性がありません。
The way this has been solved is by introducing a record that defines an interval between two existing names. Or, to put it another way, it defines the holes (nonexisting names) in the zone. This record can be signed beforehand and given to the resolver. Appendices A and B describe online signing techniques that are compatible with this scheme.
これを解決する方法は、2つの既存の名前の間隔を定義するレコードを導入することです。または、言い換えると、ゾーンに穴（存在しない名前）を定義します。このレコードは、事前に署名してリゾルバに渡すことができます。付録AおよびBでは、このスキームと互換性のあるオンライン署名手法について説明しています。
Given all these troubles, why didn't the designers of DNSSEC go for the easy route and allow for online signing? Well, at that time (pre 2000), online signing was not feasible with the then-current hardware. Keep in mind that the larger servers get between 2000 and 6000 queries per second (qps), with peaks up to 20,000 qps or more. Scaling signature generation to these kind of levels is always a challenge. Another issue was (and is) key management. For online signing to work, _each_ authoritative name server needs access to the private key(s). This is considered a security risk. Hence, the protocol is required not to rely on on-line signing.
これらすべての問題を考慮して、DNSSECの設計者が簡単な方法でオンライン署名を許可しなかったのはなぜですか？まあ、当時（2000年以前）、オンライン署名は当時のハードウェアでは実現できませんでした。大規模なサーバーでは、1秒あたり2000〜6000クエリ（qps）が得られ、ピークは最大20,000 qps以上になることに注意してください。署名生成をこれらの種類のレベルにスケーリングすることは常に課題です。もう1つの問題は、キー管理でした（現在もそうです）。オンライン署名を機能させるには、_each_権威ネームサーバーが秘密鍵にアクセスできる必要があります。これはセキュリティリスクと見なされます。したがって、プロトコルはオンライン署名に依存しないようにする必要があります。
The road to the current solution (NSEC/NSEC3) was long. It started with the NXT (next) record. The NO (not existing) record was introduced, but it never made it into an RFC. Later on, NXT was superseded by the NSEC (next secure) record. From there, it went through NSEC2/DNSNR to finally reach NSEC3 (Next SECure version 3) in RFC 5155.
現在のソリューション（NSEC / NSEC3）への道のりは長いものでした。それはNXT（次の）レコードで始まりました。 NO（存在しない）レコードが導入されましたが、RFCにはなりませんでした。その後、NXTはNSEC（次のセキュア）レコードに置き換えられました。そこから、NSEC2 / DNSNRを通過して、最終的にRFC 5155のNSEC3（次のSECureバージョン3）に到達しました。
The first attempt to specify authenticated denial of existence was NXT ([RFC2535]). Section 5.1 of RFC 2535 introduces the record:
認証された存在拒否を指定する最初の試みは、NXT（[RFC2535]）でした。 RFC 2535のセクション5.1はレコードを紹介します：
The NXT resource record is used to securely indicate that RRs with an owner name in a certain name interval do not exist in a zone and to indicate what RR types are present for an existing name.
NXTリソースレコードは、特定の名前間隔で所有者名を持つRRがゾーンに存在しないことを安全に示し、既存の名前に存在するRRタイプを示すために使用されます。
By specifying what you do have, you implicitly tell what you don't have. NXT is superseded by NSEC. In the next section, we explain how NSEC (and thus NXT) works.
持っているものを指定することで、持っていないものを暗黙的に伝えます。 NXTはNSECに置き換えられました。次のセクションでは、NSEC（およびNXT）の仕組みについて説明します。
In [RFC3755], all the DNSSEC types were given new names: SIG was renamed RRSIG, KEY became DNSKEY, and NXT was renamed NSEC, and a minor issue was fixed in the process, namely the type bitmap was redefined to allow more than 127 types to be listed ([RFC2535], Section 5.2).
[RFC3755]では、すべてのDNSSECタイプに新しい名前が付けられました。SIGはRRSIGに、KEYはDNSKEYに、NXTはNSECに名前が変更され、プロセスで小さな問題が修正されました。つまり、タイプビットマップが再定義され、127を超えるリストするタイプ（[RFC2535]、セクション5.2）。
Just as NXT, NSEC is used to describe an interval between names: it indirectly tells a resolver which names do not exist in a zone.
NXTと同様に、NSECは名前の間隔を記述するために使用されます。これは、ゾーンに存在しない名前をリゾルバーに間接的に通知します。
For this to work, we need our "example.org" zone to be sorted in canonical order ([RFC4034], Section 6.1), and then create the NSECs. We add three NSEC records, one for each name, and each one covers a certain interval. The last NSEC record points back to the first as required by RFC 4034 and depicted in Figure 2.
これを機能させるには、「example.org」ゾーンを正規の順序（[RFC4034]、セクション6.1）でソートしてから、NSECを作成する必要があります。名前ごとに1つずつ、3つのNSECレコードを追加し、それぞれが特定の間隔をカバーします。最後のNSECレコードは、RFC 4034で要求され、図2に示されているように、最初のレコードを最初にポイントしています。
1. The first NSEC covers the interval between "example.org" and "a.example.org";
1. 最初のNSECは、「example.org」と「a.example.org」の間の間隔をカバーしています。
2. The second NSEC covers "a.example.org" to "d.example.org";
2. 2番目のNSECは「a.example.org」から「d.example.org」までをカバーしています。
3. The third NSEC points back to "example.org" and covers "d.example.org" to "example.org" (i.e., the end of the zone).
3. 3番目のNSECは「example.org」をポイントし、「d.example.org」から「example.org」（つまり、ゾーンの終わり）をカバーします。
As we have defined the intervals and put those in resource records, we now have something that can be signed.
間隔を定義し、それらをリソースレコードに配置したので、署名できるものができました。
example.org
**
+-- ** <--+
(1) / . . \ (3)
/ . . \
| . . |
v . . |
** (2) **
a.example.org ** ---------> ** d.example.org
Figure 2: The NSEC records of "example.org". The arrows represent NSEC records, starting from the apex.
図2：「example.org」のNSECレコード。矢印は頂点から始まるNSECレコードを表します。
This signed zone is loaded into the name server. It looks like this:
この署名済みゾーンはネームサーバーに読み込まれます。次のようになります。
example.org. SOA ( ... ) DNSKEY ( ... ) NS a.example.org. NSEC a.example.org. NS SOA RRSIG NSEC DNSKEY RRSIG(NS) ( ... ) RRSIG(SOA) ( ... ) RRSIG(NSEC) ( ... ) RRSIG(DNSKEY) ( ... ) a.example.org. A 192.0.2.1 TXT "a record" NSEC d.example.org. A TXT RRSIG NSEC RRSIG(A) ( ... ) RRSIG(TXT) ( ... ) RRSIG(NSEC) ( ... ) d.example.org. A 192.0.2.1 TXT "d record" NSEC example.org. A TXT RRSIG NSEC RRSIG(A) ( ... ) RRSIG(TXT) ( ... ) RRSIG(NSEC) ( ... )
example.org。 SOA（...）DNSKEY（...）NS a.example.org。 NSEC a.example.org。 NS SOA RRSIG NSEC DNSKEY RRSIG（NS）（...）RRSIG（SOA）（...）RRSIG（NSEC）（...）RRSIG（DNSKEY）（...）a.example.org。 192.0.2.1 TXT "a record" NSEC d.example.org。 A TXT RRSIG NSEC RRSIG（A）（...）RRSIG（TXT）（...）RRSIG（NSEC）（...）d.example.org。 192.0.2.1 TXT "dレコード" NSEC example.org。 A TXT RRSIG NSEC RRSIG（A）（...）RRSIG（TXT）（...）RRSIG（NSEC）（...）
Figure 3: The signed and sorted "example.org" zone with the added NSEC records (and signatures). For brevity, the class is not shown (defaults to IN) and the SOA, DNSKEY, and RRSIG records are shortened.
図3：NSECレコード（および署名）が追加された、署名およびソートされた「example.org」ゾーン簡潔にするため、クラスは表示されず（デフォルトはIN）、SOA、DNSKEY、およびRRSIGレコードは短縮されています。
If a DNSSEC-aware resolver asks for "b.example.org", it gets back a "status: NXDOMAIN" packet, which by itself is meaningless (remember that the DNS packet header is not signed and thus can be forged). To be able to securely detect that "b" does not exist, there must also be a signed NSEC record that covers the name space where "b" lives.
DNSSEC対応のリゾルバーが「b.example.org」を要求すると、それ自体では意味がない「status：NXDOMAIN」パケットが返されます（DNSパケットヘッダーは署名されていないため、偽造できることに注意してください）。 「b」が存在しないことを安全に検出できるようにするには、「b」が存在する名前空間をカバーする署名済みNSECレコードも必要です。
The record:
記録：
a.example.org. NSEC d.example.org. A TXT RRSIG NSEC
a.example.org。 NSEC d.example.org。 TXT RRSIG NSEC
does precisely that: "b" should come after "a", but the next owner name is "d.example.org", so "b" does not exist.
「b」は「a」の後に来る必要がありますが、次の所有者名は「d.example.org」であるため、「b」は存在しません。
Only by making that calculation is a resolver able to conclude that the name "b" does not exist. If the signature of the NSEC record is valid, "b" is proven not to exist. We have authenticated denial of existence. A similar NSEC record needs to be included to deny wildcard expansion, see Section 5.3.
その計算を行うことによってのみ、名前「b」が存在しないと結論付けることができるリゾルバーになります。 NSECレコードの署名が有効な場合、「b」は存在しないことが証明されます。存在拒否を認証しました。ワイルドカードの展開を拒否するには、同様のNSECレコードを含める必要があります。セクション5.3を参照してください。
Note that a man in the middle may still replay this NXDOMAIN response when you're querying for, say, "c.example.org". But, it would not do any harm since it is provable that this is the proper response to the query.
たとえば「c.example.org」を照会しているときに、途中の男がこのNXDOMAIN応答を再生する場合があることに注意してください。ただし、これがクエリに対する適切な応答であることが証明されているため、害はありません。
NSEC records are also used in NODATA responses. In that case, we need to look more closely at the type bitmap. The type bitmap in an NSEC record tells which types are defined for a name. If we look at the NSEC record of "a.example.org", we see the following types in the bitmap: A, TXT, NSEC, and RRSIG. So, for the name "a", this indicates we must have an A, TXT, NSEC, and RRSIG record in the zone.
NSECレコードは、NODATA応答でも使用されます。その場合は、タイプビットマップをさらに詳しく調べる必要があります。 NSECレコードのタイプビットマップは、名前にどのタイプが定義されているかを示します。 「a.example.org」のNSECレコードを見ると、ビットマップにA、TXT、NSEC、およびRRSIGのタイプが表示されています。したがって、「a」という名前の場合、これはゾーンにA、TXT、NSEC、およびRRSIGレコードが必要であることを示しています。
With the type bitmap of the NSEC record, a resolver can establish that a name is there, but the type is not. For example, if a resolver asks for "a.example.org AAAA", the reply that comes back is:
NSECレコードのタイプビットマップを使用すると、リゾルバーは名前が存在することを確立できますが、タイプは存在しません。たとえば、リゾルバが「a.example.org AAAA」を要求した場合、返される応答は次のとおりです。
;; status: NOERROR, id: 44638
;; AUTHORITY SECTION: example.org. SOA ( ... ) example.org. RRSIG(SOA) ( ... ) a.example.org. NSEC d.example.org. A TXT RRSIG NSEC a.example.org. RRSIG(NSEC) ( ... ) The resolver should check the AUTHORITY section and conclude that:
;;権限セクション：example.org。 SOA（...）example.org。 RRSIG（SOA）（...）a.example.org。 NSEC d.example.org。 TXT RRSIG NSEC a.example.org。 RRSIG（NSEC）（...）リゾルバーはAUTHORITYセクションを確認し、次のように結論付けます。
(1) "a.example.org" exists (because of the NSEC with that owner name); and
（1）「a.example.org」が存在する（その所有者名のNSECのため）。そして
(2) the type (AAAA) does not exist as it is not listed in the type bitmap.
（2）タイプ（AAAA）はタイプビットマップにリストされていないため、存在しません。
The techniques used by NSEC form the basics of authenticated denial of existence in DNSSEC.
NSECで使用される手法は、DNSSECでの認証された存在拒否の基本を形成します。
There were two issues with NSEC (and NXT). The first is that it allows for zone walking. NSEC records point from one name to another; in our example: "example.org" points to "a.example.org", which points to "d.example.org", which points back to "example.org". So, we can reconstruct the entire "example.org" zone, thus defeating attempts to administratively block zone transfers ([RFC2065], Section 5.5).
NSEC（およびNXT）には2つの問題がありました。 1つ目は、ゾーンウォーキングが可能なことです。 NSECレコードは、ある名前から別の名前を指します。この例では、「example.org」は「a.example.org」を指し、「d.example.org」は「example.org」を指します。したがって、「example.org」ゾーン全体を再構築できるため、ゾーン転送を管理上ブロックする試みを無効にすることができます（[RFC2065]、セクション5.5）。
The second issue is that when a large, delegation-centric ([RFC5155], Section 1.1) zone deploys DNSSEC, every name in the zone gets an NSEC plus RRSIG. So, this leads to a huge increase in the zone size (when signed). This would in turn mean that operators of such zones who are deploying DNSSEC face up-front costs. This could hinder DNSSEC adoption.
2番目の問題は、大規模な委任中心の（[RFC5155]、セクション1.1）ゾーンがDNSSECを展開すると、ゾーン内のすべての名前にNSECとRRSIGが付与されることです。したがって、これによりゾーンサイズが大幅に増加します（署名時）。これは、DNSSECを展開しているそのようなゾーンのオペレーターが初期費用に直面することを意味します。これはDNSSECの採用を妨げる可能性があります。
These two issues eventually lead to NSEC3, which:
これら2つの問題により、最終的にNSEC3が発生します。
o Adds a way to garble the owner names thus thwarting zone walking;
o 所有者名を文字化けする方法を追加して、ゾーンの歩行を阻止します。
o Makes it possible to skip names for the next owner name. This feature is called Opt-Out (see Section 5.1). It means not all names in your zone get an NSEC3 plus ditto signature, making it possible to "grow into" your DNSSEC deployment.
o 次の所有者名の名前をスキップできるようにします。この機能はオプトアウトと呼ばれます（セクション5.1を参照）。これは、ゾーン内のすべての名前がNSEC3プラスディットシグネチャを取得するわけではないことを意味し、DNSSEC展開を「拡張」できるようにします。
Note that there are other ways to mitigate zone walking. RFC 4470 [RFC4470] prevents zone walking by introducing minimally covering NSEC records. This technique is described in Appendix A.
ゾーンウォーキングを軽減する方法は他にもあることに注意してください。 RFC 4470 [RFC4470]は、最小限のカバーNSECレコードを導入することにより、ゾーンウォーキングを防止します。この手法については、付録Aで説明しています。
Before we delve into NSEC3, let us first take a look at its predecessors: NO, NSEC2, and DNSNR.
NSEC3について詳しく説明する前に、まずその前身であるNO、NSEC2、DNSNRを見てみましょう。
Long before NSEC was defined, the NO record was introduced. It was the first record to use the idea of hashed owner names to fix the issue of zone walking that was present with the NXT record. It also fixed the type bitmap issue of the NXT record, but not in a space-efficient way. At that time (around 2000), zone walking was not considered important enough to warrant the new record. People were also worried that DNSSEC deployment would be hindered by developing an alternate means of denial of existence. Thus, the effort was shelved and NXT remained.
NSECが定義されるずっと前に、NOレコードが導入されました。ハッシュ化された所有者名のアイデアを使用して、NXTレコードに存在していたゾーンウォーキングの問題を修正した最初のレコードでした。また、NXTレコードのタイプビットマップの問題も修正されましたが、スペース効率が良くありませんでした。当時（2000年頃）、ゾーンウォーキングは新しいレコードを保証するほど重要であるとは考えられていませんでした。人々は、DNSSECの展開が別の存在拒否手段を開発することによって妨げられることも心配していました。したがって、努力は棚上げされ、NXTは残りました。
When the new DNSSEC specification [RFC4034] was written, people were still not convinced that zone walking was a problem that should be solved. So, NSEC saw the light and inherited the two issues from NXT.
新しいDNSSEC仕様[RFC4034]が書かれたとき、人々はゾーンウォーキングが解決すべき問題であるとまだ確信していませんでした。したがって、NSECは光を見て、NXTから2つの問題を継承しました。
Several years after, NSEC2 was introduced as a way to solve the two issues of NSEC. The NSEC2 document [DNSEXT-NSEC2] contains the following paragraph:
数年後、NSECは、NSECの2つの問題を解決する方法として導入されました。 NSEC2ドキュメント[DNSEXT-NSEC2]には、次の段落が含まれています。
This document proposes an alternate scheme which hides owner names while permitting authenticated denial of existence of non-existent names. The scheme uses two new RR types: NSEC2 and EXIST.
このドキュメントは、存在しない名前の存在の認証された拒否を許可しながら、所有者名を隠す代替スキームを提案します。このスキームでは、NSEC2とEXISTという2つの新しいRRタイプを使用します。
When an authenticated denial-of-existence scheme starts to talk about EXIST records, it is worth paying extra attention. The EXIST record was defined as a record without RDATA that would be used to signal the presence of a domain name. From [DNSEXT-NSEC2]:
認証された存在拒否スキームがEXISTレコードについて話し始めるときは、特に注意を払う価値があります。 EXISTレコードは、ドメイン名の存在を示すために使用されるRDATAのないレコードとして定義されました。 [DNSEXT-NSEC2]から：
In order to prove the nonexistence of a record that might be covered by a wildcard, it is necessary to prove the existence of its closest encloser. This record does that. Its owner is the closest encloser. It has no RDATA. If there is another RR that proves the existence of the closest encloser, this SHOULD be used instead of an EXIST record.
ワイルドカードでカバーされている可能性のあるレコードが存在しないことを証明するには、最も近いエンクローサーの存在を証明する必要があります。このレコードはそれを行います。その所有者は最も近い封入者です。 RDATAはありません。最も近いエンクローサーの存在を証明する別のRRがある場合、EXISTレコードの代わりにこれを使用する必要があります（SHOULD）。
The introduction of this record led to questions about what wildcards actually mean (especially in the context of DNSSEC). It is probably not a coincidence that "The Role of Wildcards in the Domain Name System" [RFC4592] was standardized before NSEC3 was.
このレコードの導入により、ワイルドカードが実際に何を意味するのか（特にDNSSECのコンテキストでは）疑問が生じました。 「ドメインネームシステムにおけるワイルドカードの役割」[RFC4592]がNSEC3の前に標準化されたのはおそらく偶然ではありません。
NSEC2 solved the zone-walking issue by hashing (with SHA1 and a salt) the "next owner name" in the record, thereby making it useless for zone walking. But, it did not have Opt-Out.
NSEC2は、レコードの「次の所有者名」を（SHA1とソルトを使用して）ハッシュすることにより、ゾーンウォーキングの問題を解決しました。ただし、オプトアウトはありませんでした。
The DNSNR record was another attempt that used hashed names to foil zone walking, and it also introduced the concept of opting out (called "Authoritative Only Flag"), which limited the use of DNSNR in delegation-centric zones.
DNSNRレコードは、ハッシュされた名前を使用してゾーンウォーキングを無効にするもう1つの試みであり、委任中心のゾーンでのDNSNRの使用を制限するオプトアウトの概念（「権限のみのフラグ」と呼ばれる）も導入しました。
All of these proposals didn't make it, but they did provide valuable insights. To summarize:
これらの提案はすべて成功しませんでしたが、貴重な洞察を提供しました。要約する：
o The NO record introduced hashing, but this idea lingered in the background for a long time;
o NOレコードはハッシュを導入しましたが、このアイデアは長い間バックグラウンドに残っていました。
o The NSEC2 record made it clear that wildcards were not completely understood;
o NSEC2の記録により、ワイルドカードが完全には理解されていないことが明らかになりました。
o The DNSNR record used a new flag field in the RDATA to signal Opt-Out.
o DNSNRレコードは、オプトアウトを通知するためにRDATAの新しいフラグフィールドを使用しました。
From the experience gained with NSEC2 and DNSNR, NSEC3 was forged. It incorporates both Opt-Out and the hashing of names. NSEC3 solves any issues people might have with NSEC, but it introduces some additional complexity.
NSEC2とDNSNRで得られた経験から、NSEC3は偽造されました。オプトアウトと名前のハッシュの両方が組み込まれています。 NSEC3は、NSECで発生する可能性のあるすべての問題を解決しますが、さらに複雑さをもたらします。
NSEC3 did not supersede NSEC; they are both defined for DNSSEC. So, DNSSEC is blessed with two different means to perform authenticated denial of existence: NSEC and NSEC3. In NSEC3, every name is hashed, including the owner name. This means that the NSEC3 chain is sorted in hash order, instead of canonical order. Because the owner names are hashed, the next owner name for "example.org" is unlikely to be "a.example.org". Because the next owner name is hashed, zone walking becomes more difficult.
NSEC3はNSECに取って代わりませんでした。どちらもDNSSECに対して定義されています。したがって、DNSSECは、NSECとNSEC3の認証された存在の拒否を実行する2つの異なる手段に恵まれています。 NSEC3では、所有者名を含むすべての名前がハッシュされます。これは、NSEC3チェーンが正規の順序ではなくハッシュの順序でソートされることを意味します。所有者名はハッシュ化されているため、「example.org」の次の所有者名は「a.example.org」ではない可能性があります。次の所有者名がハッシュ化されるため、ゾーンウォーキングがより困難になります。
To make it even more difficult to retrieve the original names, the hashing can be repeated several times, each time taking the previous hash as input. To prevent the reuse of pre-generated hash values between zones, a (per-zone) salt can also be added. In the NSEC3 for "example.org", we have hashed the names thrice ([RFC5155], Section 5) and used the salt "DEAD". Let's look at a typical NSEC3 record:
元の名前を取得するのをさらに困難にするために、ハッシュを数回繰り返すことができ、そのたびに前のハッシュを入力として使用します。ゾーン間で事前に生成されたハッシュ値の再利用を防ぐために、（ゾーンごとの）ソルトを追加することもできます。 「example.org」のNSEC3では、名前を3回ハッシュし（[RFC5155]、セクション5）、ソルト「DEAD」を使用しました。典型的なNSEC3レコードを見てみましょう。
15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( NSEC3 1 0 2 DEAD A6EDKB6V8VL5OL8JNQQLT74QMJ7HEB84 NS SOA RRSIG DNSKEY NSEC3PARAM )
15bg9l6359f5ch23e34ddua6n1rihl9h.example.org。 （NSEC3 1 0 2 DEAD A6EDKB6V8VL5OL8JNQQLT74QMJ7HEB84 NS SOA RRSIG DNSKEY NSEC3PARAM）
On the first line, we see the hashed owner name: "15bg9l6359f5ch23e34ddua6n1rihl9h.example.org"; this is the hashed name of the fully qualified domain name (FQDN) "example.org" encoded as Base32 [RFC4648]. Note that even though we hashed "example.org", the zone's name is added to make it look like a domain name again. In our zone, the basic format is "Base32(SHA1(FQDN)).example.org".
1行目には、ハッシュ化された所有者名が表示されます。「15bg9l6359f5ch23e34ddua6n1rihl9h.example.org」;これは、Base32 [RFC4648]としてエンコードされた完全修飾ドメイン名（FQDN） "example.org"のハッシュ名です。 「example.org」をハッシュしたとしても、ゾーンの名前が追加され、ドメイン名のように見えることに注意してください。私たちのゾーンでは、基本的なフォーマットは「Base32（SHA1（FQDN））。example.org」です。
The next hashed owner name "A6EDKB6V8VL5OL8JNQQLT74QMJ7HEB84" (line 2) is the hashed version of "d.example.org", represented as Base32. Note that "d.example.org" is used as the next owner name because in the hash ordering, its hash comes after the hash of the zone's apex. Also, note that ".example.org" is not added to the next hashed owner name, as this name always falls in the current zone.
次のハッシュ化された所有者名「A6EDKB6V8VL5OL8JNQQLT74QMJ7HEB84」（2行目）は、Base32として表される「d.example.org」のハッシュ化されたバージョンです。 「d.example.org」が次の所有者名として使用されることに注意してください。これは、ハッシュの順序付けでは、そのハッシュがゾーンの頂点のハッシュの後に来るためです。また、次のハッシュ化された所有者名には常に「.example.org」が追加されないことに注意してください。この名前は常に現在のゾーンに含まれるためです。
The "1 0 2 DEAD" segment of the NSEC3 states:
NSEC3の「1 0 2 DEAD」セグメントは次のように述べています。
o Hash Algorithm = 1 (SHA1 is the default; no other hash algorithms are currently defined for use in NSEC3; see Section 3.1.1 of [RFC5155]);
o ハッシュアルゴリズム= 1（SHA1がデフォルトです。現在、NSEC3で使用する他のハッシュアルゴリズムは定義されていません。[RFC5155]のセクション3.1.1を参照してください）;
o Opt-Out = 0 (disabled; see Section 6 of [RFC5155]);
o オプトアウト= 0（無効。[RFC5155]のセクション6を参照）。
o Hash Iterations = 2 (this yields three iterations, as a zero value is already one iteration; see Section 3.1.3 of [RFC5155]);
o ハッシュ反復= 2（ゼロ値はすでに1回の反復であるため、3回の反復が生成されます。[RFC5155]のセクション3.1.3を参照してください）;
o Salt = "DEAD" (see Section 3.1.5 of [RFC5155].
o Salt = "DEAD"（[RFC5155]のセクション3.1.5を参照）。
At the end, we see the type bitmap, which is identical to NSEC's bitmap, that lists the types present at the original owner name. Note that the type NSEC3 is absent from the list in the example above. This is due to the fact that the original owner name ("example.org") does not have the NSEC3 type. It only exists for the hashed name.
最後に、タイプビットマップが表示されます。これは、NSECのビットマップと同じで、元の所有者名に存在するタイプをリストしています。上記の例のリストには、タイプNSEC3がないことに注意してください。これは、元の所有者名（「example.org」）にNSEC3タイプがないためです。ハッシュされた名前に対してのみ存在します。
Names like "1.h.example.org" hash to one label in NSEC3 and "1.h.example.org" becomes: "117gercprcjgg8j04ev1ndrk8d1jt14k.example.org" when used as an owner name. This is an important observation. By hashing the names, you lose the depth of a zone -- hashing introduces a flat space of names, as opposed to NSEC.
「1.h.example.org」のような名前は、NSEC3の1つのラベルにハッシュされ、「1.h.example.org」は、所有者名として使用すると「117gercprcjgg8j04ev1ndrk8d1jt14k.example.org」になります。これは重要な観察です。名前をハッシュすると、ゾーンの深さが失われます。ハッシュにより、NSECとは対照的に、フラットな名前のスペースが導入されます。
The name used above ("1.h.example.org") creates an empty non-terminal. Empty non-terminals are domain names that have no RRs associated with them and exist only because they have one or more subdomains that do ([RFC5155], Section 1.3). The record:
上記で使用された名前（「1.h.example.org」）は、空の非端末を作成します。空の非端末とは、RRが関連付けられていないドメイン名で、1つ以上のサブドメインがあるためにのみ存在します（[RFC5155]、セクション1.3）。記録：
1.h.example.org. TXT "1.h record"
1.h.example.org。 TXT "1.hレコード"
creates two names:
2つの名前を作成します。
1. "1.h.example.org" that has the type: TXT;
1. タイプが「TXT」である「1.h.example.org」
2. "h.example.org", which has no types. This is the empty non-terminal.
2. タイプのない「h.example.org」。これは空の非終端です。
An empty non-terminal will get an NSEC3 record but not an NSEC record. In Section 5.5, how the resolver uses these NSEC3 records to validate the denial-of-existence proofs is shown.
空の非端末はNSEC3レコードを取得しますが、NSECレコードは取得しません。セクション5.5で、リゾルバーがこれらのNSEC3レコードを使用して存在拒否の証明を検証する方法を示します。
Note that NSEC3 might not always be useful. For example, highly structured zones, like the reverse zones ip6.arpa and in-addr.arpa, can be walked even with NSEC3 due to their structure. Also, the names in small, trivial zones can be easily guessed. In these cases, it does not help to defend against zone walking, but it does add the computational load on authoritative servers and validators.
NSEC3が常に役立つとは限らないことに注意してください。たとえば、逆ゾーンip6.arpaやin-addr.arpaなどの高度に構造化されたゾーンは、NSEC3でも構造が原因で歩くことができます。また、小さくてささいなゾーンの名前は簡単に推測できます。このような場合、ゾーンウォーキングを防ぐことはできませんが、権限のあるサーバーとバリデーターに計算負荷を追加します。
Hashing mitigates the zone-walking issue of NSEC. The other issue, the high costs of securing a delegation to an insecure zone, is tackled with Opt-Out. When using Opt-Out, names that are an insecure delegation (and empty non-terminals that are only derived from insecure delegations) don't require an NSEC3 record. For each insecure delegation, the zone size can be decreased (compared with a fully signed zone without using Opt-Out) with at least two records: one NSEC3 record and one corresponding RRSIG record. If the insecure delegation would introduce empty non-terminals, even more records can be omitted from the zone.
ハッシュは、NSECのゾーンウォーキング問題を軽減します。もう1つの問題である、デリゲートを安全でないゾーンに確保するための高コストは、オプトアウトで対処されます。オプトアウトを使用する場合、安全でない委任である名前（および安全でない委任からのみ派生する空の非端末）は、NSEC3レコードを必要としません。安全でない委任ごとに、少なくとも2つのレコード（1つのNSEC3レコードと1つの対応するRRSIGレコード）を使用して、ゾーンサイズを減らすことができます（オプトアウトを使用しない完全署名ゾーンと比較して）。安全でない委任によって空の非端末が導入される場合は、さらに多くのレコードをゾーンから除外できます。
Opt-Out NSEC3 records are not able to prove or deny the existence of the insecure delegations. In other words, those delegations do not benefit from the cryptographic security that DNSSEC provides.
オプトアウトNSEC3レコードは、安全でない委任の存在を証明または拒否できません。つまり、これらの委任は、DNSSECが提供する暗号化セキュリティの恩恵を受けていません。
A recently discovered corner case (see RFC Errata ID 3441 [Err3441]) shows that not only those delegations remain insecure but also the empty non-terminal space that is derived from those delegations.
最近発見されたコーナーケース（RFC Errata ID 3441 [Err3441]を参照）は、これらの委任が安全でないままであるだけでなく、それらの委任から派生した空の非終端スペースも示している。
Because the names in this empty non-terminal space do exist according to the definition in [RFC4592], the server should respond to queries for these names with a NODATA response. However, the validator requires an NSEC3 record proving the NODATA response ([RFC5155], Section 8.5):
この空の非終端スペースの名前は[RFC4592]の定義に従って存在するため、サーバーはこれらの名前のクエリにNODATA応答で応答する必要があります。ただし、バリデーターには、NODATA応答を証明するNSEC3レコードが必要です（[RFC5155]、セクション8.5）。
The validator MUST verify that an NSEC3 RR that matches QNAME is present and that both the QTYPE and the CNAME type are not set in its Type Bit Maps field.
バリデーターは、QNAMEと一致するNSEC3 RRが存在し、QTYPEとCNAMEタイプの両方がそのタイプビットマップフィールドに設定されていないことを確認する必要があります。
A way to resolve this contradiction in the specification is to always provide empty non-terminals with an NSEC3 record, even if it is only derived from an insecure delegation.
仕様でこの矛盾を解決する方法は、たとえそれが安全でない委任からのみ派生したとしても、常にNSEC3レコードを持つ空の非端末を提供することです。
Whenever an authoritative server receives a query for a non-existing record, it has to hash the incoming query name to determine into which interval between two existing hashes it falls. To do that, it needs to know the zone's specific NSEC3 parameters (hash iterations and salt).
権限のあるサーバーは、存在しないレコードに対するクエリを受信するたびに、受信したクエリ名をハッシュして、既存の2つのハッシュ間のどの間隔に分類するかを決定する必要があります。そのためには、ゾーン固有のNSEC3パラメータ（ハッシュの反復とソルト）を知っている必要があります。
One way to learn them is to scan the zone during loading for NSEC3 records and glean the NSEC3 parameters from them. However, it would need to make sure that there is at least one complete set of NSEC3 records for the zone using the same parameters. Therefore, it would need to inspect all NSEC3 records.
それらを学習する1つの方法は、NSEC3レコードのロード中にゾーンをスキャンし、それらからNSEC3パラメータを収集することです。ただし、同じパラメーターを使用して、ゾーンのNSEC3レコードの完全なセットが少なくとも1つあることを確認する必要があります。したがって、すべてのNSEC3レコードを検査する必要があります。
A more graceful solution was designed. The solution was to create a new record, NSEC3PARAM, which must be placed at the apex of the zone. Its role is to provide a fixed place where an authoritative name server can directly see the NSEC3 parameters used, and by putting it in the zone, it allows for easy transfer to the secondaries.
より優雅なソリューションが設計されました。解決策は、ゾーンの頂点に配置する必要のある新しいレコードNSEC3PARAMを作成することでした。その役割は、権威ネームサーバーが使用されているNSEC3パラメータを直接確認できる固定された場所を提供することであり、ゾーンに配置することで、セカンダリへの転送を容易にします。
So far, we have only talked about denial of existence in negative responses. However, denial of existence may also occur in positive responses, i.e., where the ANSWER section of the response is not empty. This can happen because of wildcards.
これまで、否定的な応答での存在の否定についてのみ話しました。ただし、存在の拒否は、肯定的な応答、つまり応答のANSWERセクションが空でない場合にも発生する可能性があります。これは、ワイルドカードが原因で発生する可能性があります。
Wildcards have been part of the DNS since the first DNS RFCs. They allow to define all names for a certain type in one go. In our "example.org" zone, we could, for instance, add a wildcard record:
ワイルドカードは、最初のDNS RFC以来DNSの一部でした。彼らは一度に特定のタイプのすべての名前を定義することができます。 「example.org」ゾーンでは、たとえば、ワイルドカードレコードを追加できます。
*.example.org. TXT "wildcard record"
* .example.org。 TXT「ワイルドカードレコード」
For completeness, our (unsigned) zone now looks like this:
完全を期すために、（署名されていない）ゾーンは次のようになります。
example.org. SOA ( ... ) example.org. NS a.example.org. *.example.org. TXT "wildcard record" a.example.org. A 192.0.2.1 TXT "a record" d.example.org. A 192.0.2.1 TXT "d record"
example.org。 SOA（...）example.org。 NS a.example.org。 * .example.org。 TXT「ワイルドカードレコード」a.example.org。 192.0.2.1 TXT「レコード」d.example.org。 192.0.2.1 TXT "dレコード"
Figure 4: The example.org Zone with a Wildcard Record If a resolver asks for "z.example.org TXT", the name server will respond with an expanded wildcard instead of an NXDOMAIN:
図4：ワイルドカードレコードのあるexample.orgゾーンリゾルバーが「z.example.org TXT」を要求すると、ネームサーバーはNXDOMAINではなく、拡張されたワイルドカードで応答します。
;; status: NOERROR, id: 13658
;; ANSWER SECTION: z.example.org. TXT "wildcard record"
;;回答セクション：z.example.org。 TXT「ワイルドカードレコード」
Note, however, that the resolver cannot detect that this answer came from a wildcard. It just sees the answer as is. How will this answer look with DNSSEC?
ただし、リゾルバーはこの回答がワイルドカードからのものであることを検出できないことに注意してください。答えはそのままです。この答えはDNSSECでどのように見えますか？
;; status: NOERROR, id: 51790
;; ANSWER SECTION: z.example.org. TXT "wildcard record" z.example.org. RRSIG(TXT) ( ... )
;;回答セクション：z.example.org。 TXT「ワイルドカードレコード」z.example.org。 RRSIG（TXT）（...）
;; AUTHORITY SECTION: d.example.org. NSEC example.org. A TXT RRSIG NSEC d.example.org. RRSIG(NSEC) ( ... )
;;権限セクション：d.example.org。 NSEC example.org。 TXT RRSIG NSEC d.example.org。 RRSIG（NSEC）（...）
Figure 5: A Response with an Expanded Wildcard and DNSSEC
図5：ワイルドカードとDNSSECを拡張した応答
The RRSIG of the "z.example.org" TXT record indicates there is a wildcard configured. The RDATA of the signature lists a label count, [RFC4034], Section 3.1.3., of two (not visible in the figure above), but the owner name of the signature has three labels. This mismatch indicates there is a wildcard "*.example.org" configured.
"z.example.org" TXTレコードのRRSIGは、ワイルドカードが構成されていることを示しています。署名のRDATAには、ラベル数[RFC4034]、セクション3.1.3。の2つがリストされています（上の図には表示されていません）が、署名の所有者名には3つのラベルがあります。この不一致は、ワイルドカード「* .example.org」が構成されていることを示しています。
An astute reader may notice that it appears as if a "z.example.org" RRSIG(TXT) is created out of thin air. This is not the case. The signature for "z.example.org" does not exist. The signature you are seeing is the one for "*.example.org", which does exist; only the owner name is switched to "z.example.org". So, even with wildcards, no signatures have to be created on the fly.
賢明な読者は、「z.example.org」のRRSIG（TXT）が薄い空気から作成されているように見えることに気付くでしょう。これはそうではありません。 「z.example.org」の署名は存在しません。表示されている署名は、存在する「* .example.org」の署名です。所有者名のみが「z.example.org」に切り替えられます。そのため、ワイルドカードを使用しても、その場で署名を作成する必要はありません。
The DNSSEC standard mandates that an NSEC (or NSEC3) is included in such responses. If it wasn't, an attacker could mount a replay attack and poison the cache with false data. Suppose that the resolver has asked for "a.example.org TXT". An attacker could modify the packet in such way that it looks like the response was generated through wildcard expansion, even though a record exists for "a.example.org TXT".
DNSSEC標準は、NSEC（またはNSEC3）がそのような応答に含まれることを義務付けています。そうでない場合、攻撃者はリプレイ攻撃を開始し、偽のデータでキャッシュを汚染する可能性があります。リゾルバーが「a.example.org TXT」を要求したとします。攻撃者は、「a.example.org TXT」のレコードが存在していても、ワイルドカード拡張を介して応答が生成されたようにパケットを変更する可能性があります。
The tweaking simply consists of adjusting the ANSWER section to:
微調整は、ANSWERセクションを次のように調整するだけです。
;; status: NOERROR, id: 31827
;; ANSWER SECTION: a.example.org. TXT "wildcard record" a.example.org. RRSIG(TXT) ( ... )
;;回答セクション：a.example.org。 TXT「ワイルドカードレコード」a.example.org。 RRSIG（TXT）（...）
Figure 6: A Forged Response without the Expanded Wildcard
図6：ワイルドカードを展開しない偽造レスポンス
Note the subtle difference from Figure 5 in the owner name. In this response, we see a "a.example.org TXT" record for which a record with different RDATA (see Figure 4) exists in the zone.
所有者名の図5との微妙な違いに注意してください。この応答では、ゾーンに異なるRDATA（図4を参照）のレコードが存在する「a.example.org TXT」レコードが表示されます。
That would be a perfectly valid answer if we would not require the inclusion of an NSEC or NSEC3 record in the wildcard answer response. The resolver believes that "a.example.org TXT" is a wildcard record, and the real record is obscured. This is bad and defeats all the security DNSSEC can deliver. Because of this, the NSEC or NSEC3 must be present.
ワイルドカード回答応答にNSECまたはNSEC3レコードを含める必要がない場合、これは完全に有効な回答になります。リゾルバーは、「a.example.org TXT」はワイルドカードレコードであると信じており、実際のレコードは隠されています。これは悪いことであり、DNSSECが提供できるすべてのセキュリティを無効にします。このため、NSECまたはNSEC3が存在する必要があります。
Another way of putting this is that DNSSEC is there to ensure the name server has followed the steps as outlined in [RFC1034], Section 4.3.2 for looking up names in the zone. It explicitly lists wildcard lookup as one of these steps (3c), so with DNSSEC this must be communicated to the resolver: hence, the NSEC or NSEC3 record.
別の言い方をすると、DNSSECは、ネームサーバーが[RFC1034]のセクション4.3.2で説明されているゾーン内の名前を検索するための手順に従っていることを確認するために存在します。ワイルドカード検索をこれらの手順（3c）の1つとして明示的にリストしているため、DNSSECでは、これをリゾルバー（つまり、NSECまたはNSEC3レコード）に通知する必要があります。
So far, the maximum number of NSEC records a response will have is two: one for the denial of existence and another for the wildcard. We say maximum because sometimes a single NSEC can prove both. With NSEC3, this is three (as to why, we will explain in the next section).
これまでのところ、応答が持つNSECレコードの最大数は2つです。1つは存在の拒否、もう1つはワイルドカードです。最大とは、単一のNSECが両方を証明できる場合があるためです。 NSEC3では、これは3つです（理由については、次のセクションで説明します）。
When we take CNAME wildcard records into account, we can have more NSEC or NSEC3 records. For every wildcard expansion, we need to prove that the expansion was allowed. Let's add some CNAME wildcard records to our zone:
CNAMEワイルドカードレコードを考慮すると、より多くのNSECまたはNSEC3レコードを持つことができます。すべてのワイルドカード拡張について、拡張が許可されたことを証明する必要があります。 CNAMEワイルドカードレコードをゾーンに追加してみましょう。
example.org. SOA ( ... ) example.org. NS a.example.org. *.example.org. TXT "wildcard record" a.example.org. A 192.0.2.1 TXT "a record" *.a.example.org. CNAME w.b *.b.example.org. CNAME w.c *.c.example.org. A 192.0.2.1 d.example.org. A 192.0.2.1 TXT "d record" w.example.org. CNAME w.a
example.org。 SOA（...）example.org。 NS a.example.org。 * .example.org。 TXT「ワイルドカードレコード」a.example.org。 192.0.2.1 TXT "a record" * .a.example.org。 CNAME w.b * .b.example.org。 CNAME w.c * .c.example.org。 192.0.2.1 d.example.org。 192.0.2.1 TXT "dレコード" w.example.org。 CNAME w.a
Figure 7: A Wildcard CNAME Chain Added to the "example.org" Zone A query for "w.example.org A" will result in the following response:
図7：「example.org」ゾーンに追加されたワイルドカードCNAMEチェーン「w.example.org A」に対するクエリは、次の応答になります。
;; status: NOERROR, id: 4307
;; ANSWER SECTION: w.example.org. CNAME w.a.example.org. w.example.org. RRSIG(CNAME) ( ... ) w.a.example.org. CNAME w.b.example.org. w.a.example.org. RRSIG(CNAME) ( ... ) w.b.example.org. CNAME w.c.example.org. w.b.example.org. RRSIG(CNAME) ( ... ) w.c.example.org. A 192.0.2.1 w.c.example.org. RRSIG(A) ( ... )
;;回答セクション：w.example.org。 CNAME w.a.example.org。 w.example.org。 RRSIG（CNAME）（...）w.a.example.org。 CNAME w.b.example.org。 w.a.example.org。 RRSIG（CNAME）（...）w.b.example.org。 CNAME w.c.example.org。 w.b.example.org。 RRSIG（CNAME）（...）w.c.example.org。 192.0.2.1 w.c.example.org。 RRSIG（A）（...）
;; AUTHORITY SECTION:
*.a.example.org. NSEC *.b.example.org. CNAME RRSIG NSEC
*.a.example.org. RRSIG(NSEC) ( ... )
*.b.example.org. NSEC *.c.example.org. CNAME RRSIG NSEC
*.b.example.org. RRSIG(NSEC) ( ... )
*.c.example.org. NSEC d.example.org. A RRSIG NSEC
*.c.example.org. RRSIG(NSEC) ( ... )
The NSEC record "*.a.example.org" proves that wildcard expansion to "w.a.example.org" was appropriate: "w.a." falls in the gap "*.a" to "*.b". Similarly, the NSEC record "*.b.example.org" proves that there was no direct match for "w.b.example.org" and "*.c.example.org" denies the direct match for "w.c.example.org".
NSECレコード「* .a.example.org」は、「w.a.example.org」へのワイルドカード拡張が適切であったことを証明します：「w.a」 「* .a」から「* .b」までのギャップに該当します。同様に、NSECレコード「* .b.example.org」は、「w.b.example.org」に直接一致するものがなかったことを証明し、「*。c.example.org」は「w.c.example.org」に直接一致することを拒否します。
DNAME records and wildcard names should not be used as reiterated in [RFC6672], Section 3.3.
DNAMEレコードとワイルドカード名は、[RFC6672]のセクション3.3で繰り返されるように使用しないでください。
We can have one or more NSEC3 records that deny the existence of the requested name and one NSEC3 record that denies wildcard synthesis. What do we miss?
要求された名前の存在を拒否する1つ以上のNSEC3レコードと、ワイルドカード合成を拒否する1つのNSEC3レコードを含めることができます。私たちは何を逃していますか？
The short answer is that due to the hashing in NSEC3, you lose the depth of your zone and everything is hashed into a flat plane. To make up for this loss of information, you need an extra record.
簡単に言えば、NSEC3でのハッシュにより、ゾーンの深さが失われ、すべてが平面にハッシュされます。この情報の損失を埋め合わせるには、追加の記録が必要です。
To understand NSEC3, we will need two definitions:
NSEC3を理解するには、2つの定義が必要です。
Closest encloser: Introduced in [RFC4592] as:
最も近いエンクロージャ：[RFC 4592]で次のように導入：
The closest encloser is the node in the zone's tree of existing domain names that has the most labels matching the query name (consecutively, counting from the root label downward).
最も近いエンクローサーは、ゾーンのツリー内の既存のドメイン名のノードであり、クエリ名に一致するラベルが最も多くなっています（ルートラベルから下に向かって数えます）。
In our example, if the query name is "x.2.example.org", then "example.org" is the "closest encloser";
この例では、クエリ名が「x.2.example.org」の場合、「example.org」が「最も近いエンクローサー」です。
Next closer name: Introduced in [RFC5155], this is the closest encloser with one more label added to the left. So, if "example.org" is the closest encloser for the query name "x.2.example.org", "2.example.org" is the "next closer name".
次のより近い名前：[RFC5155]で導入された、これは1つ以上のラベルが左側に追加された最も近いエンクロージャーです。したがって、「example.org」がクエリ名「x.2.example.org」に最も近いエンクローサーである場合、「2.example.org」は「次の近い名前」です。
An NSEC3 "closest encloser proof" consists of:
NSEC3「最も近い同封者証明」は、以下で構成されています。
1. An NSEC3 record that *matches* the "closest encloser". This means the unhashed owner name of the record is the closest encloser. This bit of information tells a resolver: "The name you are asking for does not exist; the closest I have is this".
1. 「最も近いエンクロジャー」に*一致する* NSEC3レコード。これは、レコードのハッシュされていない所有者名が最も近いエンクローサーであることを意味します。この少しの情報はリゾルバに伝えます：「あなたが求めている名前は存在しません;私が持っている最も近いものはこれです」。
2. An NSEC3 record that *covers* the "next closer name". This means it defines an interval in which the "next closer name" falls. This tells the resolver: "The next closer name falls in this interval, and therefore the name in your question does not exist. In fact, the closest encloser is indeed the closest I have".
2. 「次のより近い名前」を*カバー*するNSEC3レコード。これは、「次に近い名前」が分類される間隔を定義することを意味します。これはリゾルバに指示します。「次に近い名前がこの間隔に含まれるため、質問の名前は存在しません。実際、最も近いエンクローサーは実際に最も近いエンクローサーです」。
These two records already deny the existence of the requested name, so we do not need an NSEC3 record that covers the actual queried name. By denying the existence of the next closer name, you also deny the existence of the queried name.
これらの2つのレコードは、要求された名前の存在をすでに拒否しているため、実際に照会された名前をカバーするNSEC3レコードは必要ありません。次に近い名前の存在を拒否することにより、照会された名前の存在も拒否します。
Note that with NSEC, the existence of all empty non-terminals between the two names are denied, hence it implicitly contains the closest encloser.
NSECでは、2つの名前の間のすべての空の非端末の存在が拒否されるため、暗黙的に最も近いエンクローサーが含まれていることに注意してください。
For a given query name, there is one (and only one) place where wildcard expansion is possible. This is the "source of synthesis" and is defined ([RFC4592], Sections 2.1.1 and 3.3.1) as:
指定されたクエリ名について、ワイルドカード展開が可能な場所は1つだけです。これは「合成のソース」であり、次のように定義されています（[RFC4592]、セクション2.1.1および3.3.1）。
<asterisk label>.<closest encloser>
In other words, to deny wildcard synthesis, the resolver needs to know the hash of the source of synthesis. Since it does not know beforehand what the closest encloser of the query name is, it must be provided in the answer.
つまり、ワイルドカード合成を拒否するには、リゾルバーは合成のソースのハッシュを知っている必要があります。クエリ名の最も近いエンクローサーが何であるかは事前にわからないので、回答で提供する必要があります。
Take the following example. We have a zone with two TXT records to it. The records added are "1.h.example.org" and "3.3.example.org". It is signed with NSEC3, resulting in the following unsigned zone:
次の例を見てください。 2つのTXTレコードを持つゾーンがあります。追加されたレコードは「1.h.example.org」と「3.3.example.org」です。 NSEC3で署名されているため、次の未署名ゾーンになります。
example.org. SOA ( ... ) example.org. NS a.example.org. 1.h.example.org. TXT "1.h record" 3.3.example.org. TXT "3.3 record"
example.org。 SOA（...）example.org。 NS a.example.org。 1.h.example.org。 TXT "1.hレコード" 3.3.example.org。 TXT「3.3レコード」
Figure 8: The TXT records in example.org. These records create two empty non-terminals: h.example.org and 3.example.org.
図8：example.orgのTXTレコード。これらのレコードは、h.example.orgと3.example.orgの2つの空の非端末を作成します。
The resolver asks the following: "x.2.example.org TXT". This leads to an NXDOMAIN response from the server, which contains three NSEC3 records. A list of hashed owner names can be found in Appendix C. Also, see Figure 9; the numbers in that figure correspond with the following NSEC3 records:
リゾルバーは、「x.2.example.org TXT」を要求します。これは、3つのNSEC3レコードを含むサーバーからのNXDOMAIN応答につながります。ハッシュ化された所有者名のリストは、付録Cにあります。また、図9を参照してください。この図の番号は、次のNSEC3レコードに対応しています。
15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( NSEC3 1 0 2 DEAD 1AVVQN74SG75UKFVF25DGCETHGQ638EK NS SOA RRSIG DNSKEY NSEC3PARAM )
15bg9l6359f5ch23e34ddua6n1rihl9h.example.org。 （NSEC3 1 0 2 DEAD 1AVVQN74SG75UKFVF25DGCETHGQ638EK NS SOA RRSIG DNSKEY NSEC3PARAM）
1avvqn74sg75ukfvf25dgcethgq638ek.example.org. ( NSEC3 1 0 2 DEAD 75B9ID679QQOV6LDFHD8OCSHSSSB6JVQ )
1avvqn74sg75ukfvf25dgcethgq638ek.example.org。 （NSEC3 1 0 2 DEAD 75B9ID679QQOV6LDFHD8OCSHSSSB6JVQ）
75b9id679qqov6ldfhd8ocshsssb6jvq.example.org. ( NSEC3 1 0 2 DEAD 8555T7QEGAU7PJTKSNBCHG4TD2M0JNPJ TXT RRSIG )
75b9id679qqov6ldfhd8ocshsssb6jvq.example.org。 （NSEC3 1 0 2 DEAD 8555T7QEGAU7PJTKSNBCHG4TD2M0JNPJ TXT RRSIG）
If we would follow the NSEC approach, the resolver is only interested in one thing. Does the hash of "x.2.example.org" fall in any of the intervals of the NSEC3 records it got?
NSECのアプローチに従う場合、リゾルバーは1つのことにのみ関心があります。 「x.2.example.org」のハッシュは、取得したNSEC3レコードの間隔のいずれかに該当しますか？
example.org
**
+-- ** . . . . . . . . . . .
(1) / . ^ . .
/ . | . .
| . | . .
v . | . .
** | (2) ** ++
h.example.org ** ----+----> ** 3.example.org ++ 2.example.org
. / . | .
. / (5) . | (3) .
. / . | .
. / . v .
1.h.example.org ** ** ++
** <--------- ** 3.3.example.org ++ x.2.example.org
(4)
Figure 9: "x.2.example.org" does not exist. The five arrows represent the NSEC3 records; the ones numbered (1), (2), and (3) are the NSEC3s returned in our answer. "2.example.org" is covered by (3) and "x.2.example.org" is covered by (4).
図9：「x.2.example.org」は存在しません。 5つの矢印はNSEC3レコードを表します。 （1）、（2）、（3）の番号が付いたものは、回答で返されたNSEC3です。 「2.example.org」は（3）でカバーされ、「x.2.example.org」は（4）でカバーされます。
The hash of "x.2.example.org" is "ndtu6dste50pr4a1f2qvr1v31g00i2i1". Checking this hash on the first NSEC3 yields that it does not fall in between the interval: "15bg9l6359f5ch23e34ddua6n1rihl9h" to "1avvqn74sg75ukfvf25dgcethgq638ek". For the second NSEC3, the answer is also negative: the hash sorts outside the interval described by "1avvqn74sg75ukfvf25dgcethgq638ek" and "75b9id679qqov6ldfhd8ocshsssb6jvq". And, the third NSEC3, with interval "75b9id679qqov6ldfhd8ocshsssb6jvq" to "8555t7qegau7pjtksnbchg4td2m0jnpj" also isn't of any help.
「x.2.example.org」のハッシュは「ndtu6dste50pr4a1f2qvr1v31g00i2i1」です。最初のNSEC3でこのハッシュをチェックすると、「15bg9l6359f5ch23e34ddua6n1rihl9h」から「1avvqn74sg75ukfvf25dgcethgq638ek」までの間に収まらないことがわかります。 2番目のNSEC3の場合も、答えは否定的です。ハッシュは、「1avvqn74sg75ukfvf25dgcethgq638ek」と「75b9id679qqov6ldfhd8ocshsssb6jvq」によって記述された間隔の外側でソートされます。また、間隔が「75b9id679qqov6ldfhd8ocshsssb6jvq」から「8555t7qegau7pjtksnbchg4td2m0jnpj」の3番目のNSEC3も役に立ちません。
What is a resolver to do? It has been given the maximum amount of NSEC3s and they all seem useless.
レゾルバとは何ですか？ NSEC3の最大数が指定されており、それらはすべて役に立たないようです。
So, this is where the closest encloser proof comes into play. And, for the proof to work, the resolver needs to know what the closest encloser is. There must be an existing ancestor in the zone: a name must exist that is shorter than the query name. The resolver keeps hashing increasingly shorter names from the query name until an owner name of an NSEC3 matches. This owner name is the closest encloser.
したがって、これが最も近いエンクロージャー証明が機能する場所です。そして、証明が機能するためには、リゾルバーは最も近いエンクローサーが何であるかを知る必要があります。ゾーンには既存の祖先が存在する必要があります。クエリ名よりも短い名前が存在している必要があります。リゾルバーは、NSEC3の所有者名が一致するまで、クエリ名から次第に短い名前をハッシュし続けます。この所有者名は最も近い封入者です。
When the resolver has found the closest encloser, the next step is to construct the next closer name. This is the closest encloser with the last chopped label from the query name prepended to it: "<last chopped label>.<closest encloser>". The hash of this name should be covered by the interval set in any of the NSEC3 records.
リゾルバーが最も近いエンクローサーを見つけたら、次のステップは、次に近い名前を作成することです。これは、クエリ名の最後の切り刻まれたラベルが前に付加された最も近いエンクローサーです： "<最後の刻まれたラベル>。<closestの囲み文字>"この名前のハッシュは、NSEC3レコードのいずれかに設定された間隔でカバーされる必要があります。
Then, the resolver needs to check the presence of a wildcard. It creates the wildcard name by prepending the asterisk label to the closest encloser, "*.<closest encloser>", and uses the hash of that.
次に、リゾルバーはワイルドカードの存在を確認する必要があります。これは、アスタリスクラベルを最も近い囲み文字 "*。<closest encloser>"の前に付けることでワイルドカード名を作成し、そのハッシュを使用します。
Going back to our example, the resolver must first detect the NSEC3 that matches the closest encloser. It does this by chopping up the query name, hashing each instance (with the same number of iterations and hash as the zone it is querying), and comparing that to the answers given. So, it has the following hashes to work with:
この例に戻ると、リゾルバーは最初に最も近いエンクローサーに一致するNSEC3を検出する必要があります。これは、クエリ名を切り刻み、各インスタンスをハッシュし（反復の数と、クエリを実行しているゾーンと同じハッシュ）、それを指定された回答と比較します。したがって、次のハッシュで動作します。
x.2.example.org: "ndtu6dste50pr4a1f2qvr1v31g00i2i1", last chopped
label: "<empty>";
2.example.org: "7t70drg4ekc28v93q7gnbleopa7vlp6q", last chopped label: "x";
2.example.org： "7t70drg4ekc28v93q7gnbleopa7vlp6q"、最後に切り刻まれたラベル： "x";
example.org: "15bg9l6359f5ch23e34ddua6n1rihl9h", last chopped label: "2".
example.org：「15bg9l6359f5ch23e34ddua6n1rihl9h」、最後に切り刻まれたラベル：「2」。
Of these hashes, only one matches the owner name of one of the NSEC3 records: "15bg9l6359f5ch23e34ddua6n1rihl9h". This must be the closest encloser (unhashed: "example.org"). That's the main purpose of that NSEC3 record: tell the resolver what the closest encloser is.
これらのハッシュのうち、NSEC3レコードのいずれかの所有者名に一致するのは1つだけです：「15bg9l6359f5ch23e34ddua6n1rihl9h」。これは最も近いエンクローサーでなければなりません（ハッシュ化されていない： "example.org"）。それがそのNSEC3レコードの主な目的です。最も近いエンクローサーが何であるかをリゾルバーに伝えます。
When using Opt-Out, it is possible that the actual closest encloser to the QNAME does not have an NSEC3 record. If so, we will have to do with the closest provable encloser, which is the closest enclosing authoritative name that does have an NSEC3 record. In the worst case, this is the NSEC3 record corresponding to the apex; this name must always have an NSEC3 record.
オプトアウトを使用する場合、QNAMEに実際に最も近いエンクロジャーにNSEC3レコードがない可能性があります。もしそうなら、NSEC3レコードを持っている最も近い囲んでいる正式な名前である、最も近い証明可能な囲いを使用する必要があります。最悪の場合、これは頂点に対応するNSEC3レコードです。この名前には常にNSEC3レコードが必要です。
With the closest (provable) encloser, the resolver constructs the next closer, which in this case is: "2.example.org"; "2" is the last label chopped when "example.org" is the closest encloser. The hash of this name should be covered in any of the other NSEC3s. And, it is -- "7t70drg4ekc28v93q7gnbleopa7vlp6q" falls in the interval set by "75b9id679qqov6ldfhd8ocshsssb6jvq" and "8555t7qegau7pjtksnbchg4td2m0jnpj" (this is our second NSEC3).
最も近い（証明可能な）エンクローサーを使用すると、リゾルバーは次のクローザー（この場合は "2.example.org"）を作成します。 「2」は、「example.org」が最も近いエンクローサーであるときに切り刻まれた最後のラベルです。この名前のハッシュは、他のすべてのNSEC3でカバーされている必要があります。そして、「7t70drg4ekc28v93q7gnbleopa7vlp6q」は、「75b9id679qqov6ldfhd8ocshsssb6jvq」と「8555t7qegau7pjtksnbchg4td2m0jnpj」（これは2番目のNSECです）によって設定された間隔に該当します。
So, what does the resolver learn from this?
それで、リゾルバはこれから何を学びますか？
o "example.org" exists;
o 「example.org」が存在します。
o "2.example.org" does not exist.
o 「2.example.org」は存在しません。
And, if "2.example.org" does not exist, there is also no direct match for "x.2.example.org". The last step is to deny the existence of the source of synthesis to prove that no wildcard expansion was possible.
また、「2.example.org」が存在しない場合、「x.2.example.org」に直接一致するものもありません。最後のステップは、合成のソースの存在を否定して、ワイルドカード拡張が不可能であることを証明することです。
The resolver hashes "*.example.org" to "22670trplhsr72pqqmedltg1kdqeolb7" and checks that it is covered. In this case, by the last NSEC3 (see Figure 9), the hash falls in the interval set by "1avvqn74sg75ukfvf25dgcethgq638ek" and "75b9id679qqov6ldfhd8ocshsssb6jvq". This means there is no wildcard record directly below the closest encloser, and "x.2.example.org" definitely does not exist.
リゾルバーは「* .example.org」を「22670trplhsr72pqqmedltg1kdqeolb7」にハッシュし、それがカバーされていることを確認します。この場合、最後のNSEC3（図9を参照）までに、ハッシュは「1avvqn74sg75ukfvf25dgcethgq638ek」および「75b9id679qqov6ldfhd8ocshsssb6jvq」によって設定された間隔に含まれます。これは、最も近いエンクローサーのすぐ下にワイルドカードレコードがなく、「x.2.example.org」が存在しないことを意味します。
When we have validated the signatures, we have reached our goal: authenticated denial of existence.
署名を検証したところ、認証済みの存在拒否という目標に到達しました。
One extra NSEC3 record plus an additional signature may seem like a lot just to deny the existence of the wildcard record, but we cannot leave it out. If the standard would not mandate the closest encloser NSEC3 record but instead required two NSEC3 records -- one to deny the query name and one to deny the wildcard record -- an attacker could fool the resolver that the source of synthesis does not exist, while it in fact does.
1つの追加のNSEC3レコードと追加の署名は、ワイルドカードレコードの存在を拒否するためだけに多くのように思えるかもしれませんが、省略はできません。標準が最も近いエンクローサーNSEC3レコードを義務付けず、代わりに2つのNSEC3レコード（クエリ名を拒否するレコードとワイルドカードレコードを拒否するレコード）が必要な場合、攻撃者は合成のソースが存在しないリゾルバーをだますことができますが、実際にはそうです。
Suppose the wildcard record does exist, so our unsigned zone looks like this:
ワイルドカードレコードが存在すると仮定すると、署名されていないゾーンは次のようになります。
example.org. SOA ( ... ) example.org. NS a.example.org. *.example.org. TXT "wildcard record" 1.h.example.org. TXT "1.h record" 3.3.example.org. TXT "3.3 record"
example.org。 SOA（...）example.org。 NS a.example.org。 * .example.org。 TXT "ワイルドカードレコード" 1.h.example.org。 TXT "1.hレコード" 3.3.example.org。 TXT「3.3レコード」
The query "x.2.example.org TXT" should now be answered with:
クエリ「x.2.example.org TXT」は、次のように応答する必要があります。
x.2.example.org. TXT "wildcard record"
x.2.example.org。 TXT「ワイルドカードレコード」
An attacker can deny this wildcard expansion by calculating the hash for the wildcard name "*.2.example.org" and searching for an NSEC3 record that covers that hash. The hash of "*.2.example.org" is "fbq73bfkjlrkdoqs27k5qf81aqqd7hho". Looking through the NSEC3 records in our zone, we see that the NSEC3 record of "3.3" covers this hash:
攻撃者は、ワイルドカード名「* .2.example.org」のハッシュを計算し、そのハッシュをカバーするNSEC3レコードを検索することにより、このワイルドカードの展開を拒否できます。 「* .2.example.org」のハッシュは「fbq73bfkjlrkdoqs27k5qf81aqqd7hho」です。ゾーンのNSEC3レコードを見ると、「3.3」のNSEC3レコードがこのハッシュをカバーしていることがわかります。
8555t7qegau7pjtksnbchg4td2m0jnpj.example.org. ( NSEC3 1 0 2 DEAD 15BG9L6359F5CH23E34DDUA6N1RIHL9H TXT RRSIG )
8555t7qegau7pjtksnbchg4td2m0jnpj.example.org。 （NSEC3 1 0 2 DEAD 15BG9L6359F5CH23E34DDUA6N1RIHL9H TXT RRSIG）
This record also covers the query name "x.2.example.org" ("ndtu6dste50pr4a1f2qvr1v31g00i2i1").
このレコードには、クエリ名 "x.2.example.org"（ "ndtu6dste50pr4a1f2qvr1v31g00i2i1"）も含まれます。
Now an attacker adds this NSEC3 record to the AUTHORITY section of the reply to deny both "x.2.example.org" and any wildcard expansion. The net result is that the resolver determines that "x.2.example.org" does not exist, while in fact it should have been synthesized via wildcard expansion. With the NSEC3 matching the closest encloser "example.org", the resolver can be sure that the wildcard expansion should occur at "*.example.org" and nowhere else.
攻撃者はこのNSEC3レコードを応答のAUTHORITYセクションに追加して、「x.2.example.org」とワイルドカード拡張の両方を拒否します。最終結果は、「x.2.example.org」が存在しないとリゾルバーが判断するということですが、実際にはワイルドカード拡張によって合成されているはずです。 NSEC3が最も近いエンクローサー「example.org」と一致しているため、リゾルバーは、ワイルドカード拡張が「* .example.org」でのみ発生し、他の場所では発生しないことを確認できます。
Coming back to the original question: Why do we need up to three NSEC3 records to deny a requested name? The resolver needs to be explicitly told what the "closest encloser" is, and this takes up a full NSEC3 record. Then, the next closer name needs to be covered in an NSEC3 record. Finally, an NSEC3 must say something about whether wildcard expansion was possible. That makes three to tango.
元の質問に戻ります：要求された名前を拒否するために最大3つのNSEC3レコードが必要なのはなぜですか？リゾルバーは、「最も近いエンクローサー」が何であるかを明示的に通知する必要があり、これは完全なNSEC3レコードを占有します。次に、次に近い名前をNSEC3レコードでカバーする必要があります。最後に、NSEC3はワイルドカード拡張が可能であったかどうかについて何かを言わなければなりません。これでタンゴは3つになります。
DNSSEC does not protect against denial-of-service attacks, nor does it provide confidentiality. For more general security considerations related to DNSSEC, please see [RFC4033], [RFC4034], [RFC4035], and [RFC5155].
DNSSECは、サービス拒否攻撃から保護することも、機密性を提供することもありません。 DNSSECに関連するより一般的なセキュリティの考慮事項については、[RFC4033]、[RFC4034]、[RFC4035]、および[RFC5155]を参照してください。
These RFCs are concise about why certain design choices have been made in the area of authenticated denial of existence. Implementations that do not correctly handle this aspect of DNSSEC create a severe hole in the security DNSSEC adds. This is specifically troublesome for secure delegations. If an attacker is able to deny the existence of a Delegation Signer (DS) record, the resolver cannot establish a chain of trust, and the resolver has to fall back to insecure DNS for the remainder of the query resolution.
これらのRFCは、認証された存在の拒否の領域で特定の設計上の選択が行われた理由について簡潔です。 DNSSECのこの側面を正しく処理しない実装は、DNSSECが追加するセキュリティに重大な穴を作成します。これは、安全な委任では特に厄介です。攻撃者が委任署名者（DS）レコードの存在を拒否できる場合、リゾルバーは信頼のチェーンを確立できず、残りのクエリ解決のために、安全でないDNSにフォールバックする必要があります。
This document aims to fill this "documentation gap" and provide would-be implementors and other interested parties with enough background knowledge to better understand authenticated denial of existence.
このドキュメントは、この「ドキュメントのギャップ」を埋め、認証された存在の否定をよりよく理解するための十分な背景知識を実装者や他の関係者に提供することを目的としています。
This document would not be possible without the help of Ed Lewis, Roy Arends, Wouter Wijngaards, Olaf Kolkman, Carsten Strotmann, Jan-Piet Mens, Peter van Dijk, Marco Davids, Esther Makaay, Antoin Verschuren, Lukas Wunner, Joe Abley, Ralf Weber, Geoff Huston, Dave Lawrence, Tony Finch, and Mark Andrews. Also valuable was the source code of Unbound ("validator/val_nsec3.c") [Unbound].
このドキュメントは、エドルイス、ロイアーレンズ、ウーターウィンガード、オラフコルクマン、カルステンストロットマン、ジャンピートメンズ、ピーターファンダイク、マルコデイビッド、エスターマカアイ、アントインヴェルシュレン、ルーカスヴンナー、ジョーアブリー、ラルフの協力なしでは実現できません。ウェーバー、ジェフ・ヒューストン、デイブ・ローレンス、トニー・フィンチ、マーク・アンドリュース。 Unboundのソースコード（ "validator / val_nsec3.c"）[Unbound]も貴重でした。
Extensive feedback for early versions of this document was received from Karst Koymans.
このドキュメントの初期バージョンに対する広範なフィードバックは、Karst Koymansから受け取りました。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[RFC2065] Eastlake、D。およびC. Kaufman、「ドメインネームシステムセキュリティ拡張機能」、RFC 2065、1997年1月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308]アンドリュースM。、「DNSクエリのネガティブキャッシング（DNS NCACHE）」、RFC 2308、1998年3月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのプロトコル変更」、RFC 4035、2005年3月。
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006.
[RFC4592]ルイス、E。、「ドメインネームシステムにおけるワイルドカードの役割」、RFC 4592、2006年7月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
[RFC5155] Laurie、B.、Sisson、G.、Arends、R。、およびD. Blacka、「DNS Security（DNSSEC）Hashed Authenticated Denial of Existence」、RFC 5155、2008年3月。
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, June 2012.
[RFC6672] Rose、S。およびW. Wijngaards、「DNSでのDNAMEリダイレクション」、RFC 6672、2012年6月。
[DNSEXT-NSEC2] Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format", Work in Progress, October 2004.
[DNSEXT-NSEC2] Laurie、B。、「DNSSEC NSEC2 Owner and RDATA Format」、Work in Progress、2004年10月。
[DNSEXT] Josefsson, S., "Authenticating denial of existence in DNS with minimum disclosure", Work in Progress, November 2000.
[DNSEXT] Josefsson、S.、「最小限の開示でDNSにおける存在の認証を拒否」、Work in Progress、2000年11月。
[DNSNR-RR] Arends, R., "DNSSEC Non-Repudiation Resource Record", Work in Progress, June 2004.
[DNSNR-RR] Arends、R。、「DNSSEC Non-repudiation Resource Record」、作業中、2004年6月。
[Err3441] RFC Errata, Errata ID 3441, RFC 5155, <http://www.rfc-editor.org>.
[Err3441] RFC Errata、Errata ID 3441、RFC 5155、<http://www.rfc-editor.org>。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake、D。、「ドメインネームシステムのセキュリティ拡張機能」、RFC 2535、1999年3月。
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS Authenticated Data (AD) bit", RFC 3655, November 2003.
[RFC3655] Wellington、B.およびO. Gudmundsson、「Redefinition of DNS Authenticated Data（AD）bit」、RFC 3655、2003年11月。
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004.
[RFC3755] Weiler、S.、「レガシーリゾルバーの委任署名者（DS）の互換性」、RFC 3755、2004年5月。
[RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records and DNSSEC On-line Signing", RFC 4470, April 2006.
[RFC4470] Weiler、S。およびJ. Ihren、「NSECレコードとDNSSECオンライン署名を最小限にカバー」、RFC 4470、2006年4月。
[RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security (DNSSEC) Opt-In", RFC 4956, July 2007.
[RFC4956] Arends、R.、Kosters、M。、およびD. Blacka、「DNS Security（DNSSEC）Opt-In」、RFC 4956、2007年7月。
[Unbound] NLnet Labs, "Unbound: a validating, recursive, and caching DNS resolver", 2006, <http://unbound.net>.
[Unbound] NLnet Labs、「Unbound：検証、再帰、およびキャッシュDNSリゾルバー」、2006、<http://unbound.net>。
[phreebird] Kaminsky, D., "Phreebird: a DNSSEC proxy", January 2011, <http://dankaminsky.com/phreebird/>.
[phreebird]カミンスキー、D。、「Phreebird：DNSSECプロキシ」、2011年1月、<http://dankaminsky.com/phreebird/>。
Appendix A. Online Signing: Minimally Covering NSEC Records
付録A.オンライン署名：NSECレコードを最小限にカバー
An NSEC record lists the next existing name in a zone and thus makes it trivial to retrieve all the names from the zone. This can also be done with NSEC3, but an adversary will then retrieve all the hashed names. With DNSSEC online signing, zone walking can be prevented by faking the next owner name.
NSECレコードはゾーン内の次の既存の名前をリストするため、ゾーンからすべての名前を取得するのは簡単です。これはNSEC3でも実行できますが、攻撃者はすべてのハッシュされた名前を取得します。 DNSSECオンライン署名を使用すると、次の所有者名を偽装することでゾーンウォーキングを防ぐことができます。
To prevent retrieval of the next owner name with NSEC, a different, non-existing (according to the existence rules in [RFC4592], Section 2.2) name is used. However, not just any name can be used because a validator may make assumptions about the size of the span the NSEC record covers. The span must be large enough to cover the QNAME but not too large that it covers existing names.
NSECによる次の所有者名の取得を防ぐために、（[RFC4592]のセクション2.2の存在規則に従って）異なる、存在しない名前が使用されます。ただし、バリデーターはNSECレコードがカバーするスパンのサイズを想定している場合があるため、任意の名前だけを使用できるわけではありません。スパンは、QNAMEをカバーするのに十分な大きさである必要がありますが、既存の名前をカバーするほど大きくてはいけません。
[RFC4470] introduces a scheme for generating minimally covering NSEC records. These records use a next owner name that is lexically closer to the NSEC owner name than the actual next owner name, ensuring that no existing names are covered. The next owner name can be derived from the QNAME with the use of so-called epsilon functions.
[RFC4470]は、最小限のカバーNSECレコードを生成するためのスキームを紹介します。これらのレコードは、実際の次の所有者名よりも語彙的にNSEC所有者名に近い次の所有者名を使用し、既存の名前がカバーされないようにします。次の所有者名は、いわゆるイプシロン関数を使用してQNAMEから導出できます。
For example, to deny the existence of "b.example.org" in the zone from Section 3.2, the following NSEC record could have been generated:
たとえば、セクション3.2のゾーンで「b.example.org」の存在を拒否するには、次のNSECレコードを生成できます。
a.example.org. NSEC c.example.org. RRSIG NSEC
a.example.org。 NSEC c.example.org。 RRSIG NSEC
This record also proves that "b.example.org" also does not exist, but an adversary _cannot_ use the next owner name in a zone-walking attack. Note the type bitmap only has the RRSIG and NSEC set because [RFC4470] states:
このレコードは、「b.example.org」も存在しないことを証明していますが、敵はゾーンウォーキング攻撃で次の所有者名を使用できません。 [RFC4470]は次のように述べているため、タイプビットマップにはRRSIGとNSECのみが設定されていることに注意してください。
The generated NSEC record's type bitmap MUST have the RRSIG and NSEC bits set and SHOULD NOT have any other bits set.
生成されたNSECレコードのタイプビットマップは、RRSIGおよびNSECビットが設定されている必要があり、他のビットが設定されているべきではありません（SHOULD NOT）。
This is because the NSEC records may appear at names that did not exist before the zone was signed. In this case, however, "a.example.org" exists with other RR types, and we could have also set the A and TXT types in the bitmap.
これは、NSECレコードが、ゾーンが署名される前に存在しなかった名前で表示される可能性があるためです。ただし、この場合、「a.example.org」は他のRRタイプとともに存在し、ビットマップでAおよびTXTタイプを設定することもできます。
Because DNS ordering is very strict, the span should be shortened to a minimum. In order to do so, the last character in the leftmost label of the NSEC owner name needs to be decremented, and the label must be filled with octets of value 255 until the label length reaches the maximum of 63 octets. The next owner name is the QNAME with a leading label with a single null octet added. This gives the following minimally covering record for "b.example.org": a\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255.example.org. ( NSEC \000.b.example.org. RRSIG NSEC )
DNSの順序は非常に厳しいため、スパンを最小限に短縮する必要があります。そのためには、NSEC所有者名の左端のラベルの最後の文字をデクリメントする必要があり、ラベルの長さが最大63オクテットに達するまで、ラベルに値255のオクテットを入力する必要があります。次の所有者名は、先頭のラベルに単一のヌルオクテットが追加されたQNAMEです。これにより、「b.example.org」の次の最小限の範囲のレコードが得られます。a\ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255 \ 255.example.org。 （NSEC \ 000.b.example.org。RRSIG NSEC）
Appendix B. Online Signing: NSEC3 White Lies
付録B.オンライン署名：NSEC3ホワイトライ
The same principle of minimally covering spans can be applied to NSEC3 records. This mechanism has been dubbed "NSEC3 White Lies" when it was implemented in Phreebird [phreebird]. Here, the NSEC3 owner name is the hash of the QNAME minus one, and the next owner name is the hash of the QNAME plus one.
スパンを最小限にカバーする同じ原理をNSEC3レコードに適用できます。このメカニズムは、Phreebird [phreebird]で実装されたときに「NSEC3 White Lies」と呼ばれていました。ここで、NSEC3所有者名はQNAMEのマイナス1のハッシュであり、次の所有者名はQNAMEプラス1のハッシュです。
The following NSEC3 white lie denies "b.example.org" (recall that this hashes to "iuu8l5lmt76jeltp0bir3tmg4u3uu8e7"):
次のNSEC3白い嘘は「b.example.org」を拒否します（これは「iuu8l5lmt76jeltp0bir3tmg4u3uu8e7」にハッシュされることを思い出してください）：
iuu8l5lmt76jeltp0bir3tmg4u3uu8e6.example.org. ( NSEC3 1 0 2 DEAD IUU815LMT76JELTP0BIR3TMG4U3UU8E8 )
iuu8l5lmt76jeltp0bir3tmg4u3uu8e6.example.org。 （NSEC3 1 0 2 DEAD IUU815LMT76JELTP0BIR3TMG4U3UU8E8）
The type bitmap is empty in this case. If the hash of "b.example.org" - 1 is a collision with an existing name, the bitmap should have been filled with the RR types that exist at that name. This record actually denies the existence of the next closer name (which is conveniently "b.example.org"). Of course, the NSEC3 records to match the closest encloser and the one to deny the wildcard are still required. These can be generated too:
この場合、タイプビットマップは空です。 「b.example.org」のハッシュ-1が既存の名前との衝突である場合、ビットマップはその名前で存在するRRタイプで埋められているはずです。このレコードは、実際には次に近い名前（便宜上「b.example.org」）の存在を拒否します。もちろん、最も近いエンクローサーに一致するNSEC3レコードと、ワイルドカードを拒否するNSEC3レコードが必要です。これらも生成することができます：
# Matching `example.org`: `15bg9l6359f5ch23e34ddua6n1rihl9h` 15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( NSEC3 1 0 2 DEAD 15BG9L6359F5CH23E34DDUA6N1RIHL9I NS SOA RRSIG DNSKEY NSEC3PARAM )
＃ `example.org`に一致：` 15bg9l6359f5ch23e34ddua6n1rihl9h` 15bg9l6359f5ch23e34ddua6n1rihl9h.example.org。 （NSEC3 1 0 2 DEAD 15BG9L6359F5CH23E34DDUA6N1RIHL9I NS SOA RRSIG DNSKEY NSEC3PARAM）
# Covering `*.example.org`: `22670trplhsr72pqqmedltg1kdqeolb7` 22670trplhsr72pqqmedltg1kdqeolb6.example.org.( NSEC3 1 0 2 DEAD 22670TRPLHSR72PQQMEDLTG1KDQEOLB8 )
＃カバーする `* .example.org`：` 22670trplhsr72pqqmedltg1kdqeolb7` 22670trplhsr72pqqmedltg1kdqeolb6.example.org。（NSEC3 1 0 2 DEAD 22670TRPLHSR72PQQMEDLTG1KDQEOLB8）
The following owner names are used in this document. The origin for these names is "example.org".
このドキュメントでは、次の所有者名を使用しています。これらの名前の由来は「example.org」です。
+----------------+-------------------------------------+
| Original Name | Hashed Name |
+----------------+-------------------------------------+
| "a" | "04sknapca5al7qos3km2l9tl3p5okq4c" |
| "1.h" | "117gercprcjgg8j04ev1ndrk8d1jt14k" |
| "@" | "15bg9l6359f5ch23e34ddua6n1rihl9h" |
| "h" | "1avvqn74sg75ukfvf25dgcethgq638ek" |
| "*" | "22670trplhsr72pqqmedltg1kdqeolb7" |
| "3" | "75b9id679qqov6ldfhd8ocshsssb6jvq" |
| "2" | "7t70drg4ekc28v93q7gnbleopa7vlp6q" |
| "3.3" | "8555t7qegau7pjtksnbchg4td2m0jnpj" |
| "d" | "a6edkb6v8vl5ol8jnqqlt74qmj7heb84" |
| "*.2" | "fbq73bfkjlrkdoqs27k5qf81aqqd7hho" |
| "b" | "iuu8l5lmt76jeltp0bir3tmg4u3uu8e7" |
| "x.2" | "ndtu6dste50pr4a1f2qvr1v31g00i2i1" |
+----------------+-------------------------------------+
Table 1: Hashed Owner Names for "example.org" in Hash Order
表1：ハッシュ順での「example.org」のハッシュ化された所有者名
Authors' Addresses
著者のアドレス
R. (Miek) Gieben Google
R.（ミーク）ギーベングーグル
EMail: miek@google.com
W. (Matthijs) Mekking NLnet Labs Science Park 400 Amsterdam 1098 XH NL
W.（Matthijs）Mekking NLnet Labs Science Park 400 Amsterdam 1098 XH NL
EMail: matthijs@nlnetlabs.nl
URI: http://www.nlnetlabs.nl/