Independent Submission R. Gieben
Request for Comments: 7129 Google
Category: Informational W. Mekking
ISSN: 2070-1721 NLnet Labs
February 2014
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安全扩展（DNSSEC）响应时，名称服务器通常最多包含两条NSEC记录。对于NSEC版本3（NSEC3），该金额为三。
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.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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编辑批准发布的文件不适用于任何级别的互联网标准；见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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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
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可能有点复杂，规范的某些方面比其他方面更难理解。其中一个领域是“经认证的否认存在”。
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节），后一个称为节点数据（[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.
这三个文档提供了有关NSEC3开发的一些背景信息。
o The NO record [DNSEXT];
o 无记录[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处理。为了使其更加可见，我们将使用一个小的DNS区域，它有三个名称（“example.org”、“a.example.org”和“d.example.org”）和四种类型（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。A 192.0.2.1 TXT“A记录”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
;; 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.
“status: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
;; 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.
在这种情况下，我们没有得到答案部分，并且状态设置为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
;; 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”名称存在，但回复不包含应答部分。这将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数据包标头未签名。这意味着“状态：NXDOMAIN”不可信。事实上，整个报头可能是伪造的，包括AD位（AD代表真实数据；参见[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.
解决这个问题的方法是引入一个记录，定义两个现有名称之间的间隔。或者，换句话说，它定义了分区中的孔（不存在的名称）。该记录可以事先签名并交给解析器。附录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
考虑到所有这些麻烦，DNSSEC的设计师为什么不采取简单的方式，允许在线签名呢？嗯，在当时（2000年之前），在线签名在当时的硬件条件下是不可行的。请记住，较大的服务器
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.
每秒2000到6000次查询（qps），峰值可达20000次或更多。将签名生成扩展到此类级别始终是一个挑战。另一个问题是（现在也是）密钥管理。要使在线签名正常工作，每个权威名称服务器都需要访问私钥。这被认为是一种安全风险。因此，协议不需要依赖在线签名。
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（下一个）记录开始。没有（不存在）记录被引入，但它从未进入RFC。后来，NXT被NSEC（下一个安全）记录取代。从那里，它通过NSEC2/DNSNR最终到达RFC 5155中的NSEC3（下一个安全版本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。我们添加了三个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. 第二个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. 第三个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
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。NSSOARRSIG NSEC DNSKEY RRSIG（NS）（…）RRSIG（SOA）（…）RRSIG（NSEC）（…）RRSIG（DNSKEY）（…）a.example.org。A 192.0.2.1 TXT“A记录”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”不存在，还必须有一个签名的NSEC记录，覆盖“b”所在的名称空间。
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.Simult.org”时，仍然可以重放这个NxRe域响应。但是，这不会造成任何伤害，因为可以证明这是对查询的正确响应。
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
;; 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) ( ... )
;; 授权部分：example.org。SOA（…）example.org。RRSIG（SOA）（…）a.example.org。NSEC d.example.org。一个TXT RRSIG NSEC A.example.org。RRSIG（NSEC）（…）
The resolver should check the AUTHORITY section and conclude that:
冲突解决者应检查授权部分，并得出以下结论：
(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）有两个问题。首先，它允许区域步行。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.
第二个问题是，当一个大型的、以委派为中心的（[RFC5155]，第1.1节）分区部署DNSSEC时，该分区中的每个名称都会得到一个NSEC加上RRSIG。因此，这会导致区域大小（签名时）大幅增加。这反过来意味着部署DNSSEC的此类区域的运营商将面临前期成本。这可能会阻碍DNSSEC的采用。
These two issues eventually lead to NSEC3, which:
这两个问题最终导致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定义之前，就引入了无记录。这是第一条使用散列所有者名称的思想来解决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继承了这两个问题。
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:
几年后，NSEC2作为解决NSEC两个问题的一种方式被引入。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.
本文档提出了一种替代方案，该方案隐藏所有者名称，同时允许通过身份验证拒绝不存在的名称的存在。该方案使用两种新的RR类型：NSEC2和EXIST。
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记录被定义为不带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证明最近封闭器的存在，则应使用该RR而不是EXIST记录。
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和salt）记录中的“下一个所有者名称”解决了区域漫游问题，从而使其对区域漫游毫无用处。但是，它没有选择退出。
The DNSNR record was another attempt that used hashed names to foil zone walking, and it also introduced the concept of opting out
DNSNR记录是另一种尝试，它使用散列名称来阻止区域行走，它还引入了选择退出的概念
(called "Authoritative Only Flag"), which limited the use of DNSNR in delegation-centric zones.
（称为“仅权威标志”），该标志限制了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 NoRecord引入了散列，但是这个想法在后台停留了很长时间；
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。在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:
为了使检索原始名称更加困难，可以重复多次散列，每次都将前一个散列作为输入。为了防止在区域之间重用预先生成的哈希值，还可以添加（每个区域）salt。在“example.org”的NSEC3中，我们对名称进行了三次散列（[RFC5155]，第5节），并使用了salt“DEAD”。让我们看一个典型的NSEC3记录：
15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( NSEC3 1 0 2 DEAD A6EDKB6V8VL5OL8JNQQLT74QMJ7HEB84 NS SOA RRSIG DNSKEY NSEC3PARAM )
15bg9l6359f5ch23e34ddua6n1rihl9h.example.org。（NSEC3 1 0 2死A6EDKB6V8VL5OL8JNQLT74QMJ7HEB84 NS SOA RRSIG DNSKEY NSEC3参数）
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".
在第一行，我们看到散列的所有者名称：“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.
下一个哈希所有者名称“a6edkb6v8vl5ol8jnqlt74qmj7heb84”（第2行）是“d.example.org”的哈希版本，表示为Base32。请注意，“d.example.org”用作下一个所有者名称，因为在散列排序中，其散列位于区域顶点的散列之后。另外，请注意“.example.org”不会添加到下一个散列的所有者名称中，因为此名称始终位于当前区域中。
The "1 0 2 DEAD" segment of the NSEC3 states:
NSEC3的“1 0 2死”段说明：
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（这会产生三次迭代，因为零值已经是一次迭代；参见[RFC5155]第3.1.3节）；
o Salt = "DEAD" (see Section 3.1.5 of [RFC5155].
o Salt=“死亡”（见[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.h.example.org”在用作所有者名称时变为：“117GERCPCRCJGG8J04EV1NDRK8D1JT14K.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”）创建一个空的非终端。空的非终端是没有与之关联的RRs的域名，并且仅因为它们有一个或多个子域名而存在（[RFC5155]，第1.3节）。记录如下：
1.h.example.org. TXT "1.h record"
1.h.example.org。TXT“1.h记录”
creates two names:
创建两个名称：
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的区域漫游问题。另一个问题，即确保代表团进入不安全区的高昂成本，通过选择退出来解决。使用Opt-Out时，属于不安全委派的名称（以及仅从不安全委派派生的空非终端）不需要NSEC3记录。对于每个不安全的委派，可以使用至少两条记录减小区域大小（与不使用Opt-Out的完全签名区域相比）：一条NSEC3记录和一条相应的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勘误表ID3441[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响应来响应对这些名称的查询。但是，验证器需要NSEC3记录来证明NODATA响应（[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).
每当权威服务器接收到对不存在的记录的查询时，它都必须对传入的查询名称进行散列，以确定它属于两个现有散列之间的间隔。为此，它需要知道区域的特定NSEC3参数（散列迭代和salt）。
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.
了解它们的一种方法是在加载期间扫描区域以查找NSEC3记录，并从中收集NSEC3参数。但是，需要确保使用相同参数的分区至少有一套完整的NSEC3记录。因此，它需要检查所有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.
到目前为止，我们只讨论了否定回答中的否定存在。然而，否定存在也可能发生在肯定回答中，即回答的答案部分不是空的。这可能是因为通配符。
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。A 192.0.2.1 TXT“A记录”d.example.org。192.0.2.1 TXT“d记录”
Figure 4: The example.org Zone with a Wildcard Record
图4：带有通配符记录的example.org区域
If a resolver asks for "z.example.org TXT", the name server will respond with an expanded wildcard instead of an NXDOMAIN:
如果冲突解决程序请求“z.example.org TXT”，名称服务器将使用扩展通配符而不是NXDOMAIN进行响应：
;; status: NOERROR, id: 13658
;; 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
;; 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节，共两个（上图中不可见），但签名的所有者名称有三个标签。此不匹配表示配置了通配符“*.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:
调整仅包括将答案部分调整为：
;; status: NOERROR, id: 31827
;; 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的细微差别。在这个响应中，我们看到一个“a.example.org TXT”记录，其中区域中存在一个具有不同RDATA的记录（见图4）。
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），因此对于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记录数是两个：一个用于拒绝存在，另一个用于通配符。我们之所以说最大值，是因为有时一个NSEC可以证明两者。对于NSEC3，这是三个（至于原因，我们将在下一节中解释）。
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。A 192.0.2.1 TXT“A记录”*.A.example.org。CNAME w.b*.b.example.org。CNAME w.c*.c.example.org。A 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
图7：添加到“example.org”区域的通配符CNAME链
A query for "w.example.org A" will result in the following response:
查询“w.example.org A”将得到以下响应：
;; status: NOERROR, id: 4307
;; 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。A 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) ( ... )
;; 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.
如[RFC6672]第3.3节所述，不应使用DNAME记录和通配符名称。
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?
我们可以有一个或多个拒绝请求名称存在的NSEC3记录和一个拒绝通配符合成的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，我们需要两个定义：
Closest encloser: Introduced in [RFC4592] as:
最近的封闭器：在[RFC4592]中介绍为：
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]中引入，这是最接近的封闭器，在左侧添加了一个标签。因此，如果“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.
这两条记录已经拒绝了请求名称的存在，因此我们不需要覆盖实际查询名称的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，两个名称之间的所有空非端子的存在都被拒绝，因此它隐式包含最近的封闭符。
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:
对于给定的查询名称，有一个（并且只有一个）位置可以进行通配符扩展。这是“合成源”，定义为（[RFC4592]，第2.1.1节和第3.3.1节）：
<asterisk label>.<closest encloser>
<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:
以下面的例子为例。我们有一个有两个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。
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”。这将导致来自服务器的NXDOMAIN响应，其中包含三条NSEC3记录。散列所有者姓名列表见附录C。同样，见图9；该图中的数字与以下NSEC3记录相对应：
15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( NSEC3 1 0 2 DEAD 1AVVQN74SG75UKFVF25DGCETHGQ638EK NS SOA RRSIG DNSKEY NSEC3PARAM )
15bg9l6359f5ch23e34ddua6n1rihl9h.example.org。（NSEC3 1 0 2死1 VVQN74SG75UKFVF25 DGCETHGQ638EK NS SOA RRSIG DNSKEY NSEC3参数）
1avvqn74sg75ukfvf25dgcethgq638ek.example.org. ( NSEC3 1 0 2 DEAD 75B9ID679QQOV6LDFHD8OCSHSSSB6JVQ )
1avvqn74sg75ukfvf25dgcethgq638ek.example.org。（NSEC3 1 0 2死75B9ID679QQQOV6LDHD8OCSHSSSB6JVQ）
75b9id679qqov6ldfhd8ocshsssb6jvq.example.org. ( NSEC3 1 0 2 DEAD 8555T7QEGAU7PJTKSNBCHG4TD2M0JNPJ TXT RRSIG )
75b9id679qqov6ldfhd8ocshsssb6jvq.example.org。（NSEC3 1 0 2死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方法，解析器只对一件事感兴趣。“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)
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”不存在。五个箭头表示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”之间的间隔。对于第二个NSEC3，答案也是否定的：哈希排序超出了“1avvqn74sg75ukfvf25dgcethgq638ek”和“75B9ID679QQQOV6LDHD8OCSHSSSB6JVQ”所描述的间隔。第三个NSEC3的间隔为“75b9id679qqov6ldfhd8ocshsssb6jvq”到“8555t7qegau7pjtksnbchg4td2m0jnpj”，也没有任何帮助。
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.
当解析器找到最近的封闭器时，下一步是构造下一个更接近的名称。这是最接近的封闭符，其前面有查询名称中最后一个切碎的标签：“<last Cutched label><closest Enclosure>”。此名称的哈希值应包含在任何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.
然后，解析器需要检查是否存在通配符。它通过将星号标签前置到最近的封闭符“*.<最近的封闭符>”来创建通配符名称，并使用该名称的哈希值。
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>";
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记录的所有者名称：“15bg9l6359f5ch23e34ddua6n1rihl9h”。这必须是最近的封闭程序（unhashed:“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.
使用Opt-Out时，与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”和“8555T7QEGUGU7PJTKSNBCHG4TD2M0JNPJ”设置的区间内（这是我们的第二个NSEC3）。
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”和“75B9ID679QQQOV6LDFHD8OCSHSSSB6JVQ”设置的间隔内。这意味着在最近的封闭符正下方没有通配符记录，“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.
一个额外的NSEC3记录加上一个额外的签名，可能只是为了否认通配符记录的存在，但我们不能忽略它。如果标准不强制要求最接近的封闭器NSEC3记录，而是要求两个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”的散列是“fbq73bfkjlrkdoqs27k5qf81aqd7hho”。通过查看我们区域中的NSEC3记录，我们发现“3.3”的NSEC3记录包含以下哈希：
8555t7qegau7pjtksnbchg4td2m0jnpj.example.org. ( NSEC3 1 0 2 DEAD 15BG9L6359F5CH23E34DDUA6N1RIHL9H TXT RRSIG )
8555t7qegau7pjtksnbchg4td2m0jnpj.example.org。（NSEC3 1 0 2死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记录添加到回复的授权部分，以拒绝“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.
回到原来的问题：为什么我们最多需要三条NSEC3记录来拒绝请求的名称？需要明确地告诉解析器“最近的封闭器”是什么，这将占用完整的NSEC3记录。然后，需要在NSEC3记录中包含下一个更接近的名称。最后，NSEC3必须说明通配符扩展是否可行。这是探戈的三分之一。
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].
如果没有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和Mark Andrews的帮助，这份文件就不可能完成。Unbound（“validator/val_nsec3.c”）[Unbound]的源代码也很有价值。
Extensive feedback for early versions of this document was received from 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，“域名系统安全扩展”，RFC2065，1997年1月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308]Andrews，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安全扩展的资源记录”，RFC 40342005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006.
[RFC4592]Lewis，E.，“通配符在域名系统中的作用”，RFC4592，2006年7月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，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安全（DNSSEC）哈希认证拒绝存在”，RFC 51552008年3月。
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, June 2012.
[RFC6672]Rose，S.和W.Wijngaards，“DNS中的DNAME重定向”，RFC 66722012年6月。
[DNSEXT-NSEC2] Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format", Work in Progress, October 2004.
[DNSEXT-NSEC2]Laurie，B.，“DNSSEC NSEC2所有者和RDATA格式”，正在进行的工作，2004年10月。
[DNSEXT] Josefsson, S., "Authenticating denial of existence in DNS with minimum disclosure", Work in Progress, November 2000.
[DNSEXT]Josefsson，S.，“以最低限度的披露验证DNS中的拒绝存在”，正在进行的工作，2000年11月。
[DNSNR-RR] Arends, R., "DNSSEC Non-Repudiation Resource Record", Work in Progress, June 2004.
[DNSNR-RR]阿伦兹，R.，“DNSSEC不可否认资源记录”，正在进行的工作，2004年6月。
[Err3441] RFC Errata, Errata ID 3441, RFC 5155, <http://www.rfc-editor.org>.
[Err3441]RFC勘误表，勘误表ID 3441，RFC 5155<http://www.rfc-editor.org>.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake，D.，“域名系统安全扩展”，RFC25351999年3月。
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS Authenticated Data (AD) bit", RFC 3655, November 2003.
[RFC3655]Wellington，B.和O.Gudmundsson，“DNS认证数据（AD）位的重新定义”，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 44702006年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安全（DNSSEC）选择加入”，RFC 49562007年7月。
[Unbound] NLnet Labs, "Unbound: a validating, recursive, and caching DNS resolver", 2006, <http://unbound.net>.
[Unbound]NLnet实验室，“Unbound:验证、递归和缓存DNS解析程序”，2006年<http://unbound.net>.
[phreebird] Kaminsky, D., "Phreebird: a DNSSEC proxy", January 2011, <http://dankaminsky.com/phreebird/>.
[phreebird]Kaminsky，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所有者名称，从而确保不覆盖任何现有名称。下一个所有者名称可以使用所谓的epsilon函数从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.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”也不存在，但对手不能在区域步行攻击中使用下一个所有者名称。注意：类型位图仅设置了RRSIG和NSEC，因为[RFC4470]声明：
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位，并且不应设置任何其他位。
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":
因为DNS排序非常严格，所以应该将范围缩短到最小。为此，NSEC所有者名称最左侧标签中的最后一个字符需要递减，并且标签必须填充值为255的八位字节，直到标签长度达到63个八位字节的最大值。下一个所有者名称是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 )
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.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善意谎言”。这里，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死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记录。这些也可以生成：
# 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死15BG9L6359F5CH23E34DDUA6N1RIHL9I NS SOA RRSIG DNSKEY NSEC3参数）
# Covering `*.example.org`: `22670trplhsr72pqqmedltg1kdqeolb7` 22670trplhsr72pqqmedltg1kdqeolb6.example.org.( NSEC3 1 0 2 DEAD 22670TRPLHSR72PQQMEDLTG1KDQEOLB8 )
#覆盖`*.example.org`:`22670trplhsr72pqqmedltg1kdqeolb7`22670trplhsr72pqqmedltg1kdqeolb6.example.org.（NSEC3 1 0 2死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" |
+----------------+-------------------------------------+
+----------------+-------------------------------------+
| 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.（Miek）Gieben谷歌
EMail: miek@google.com
EMail: miek@google.com
W. (Matthijs) Mekking NLnet Labs Science Park 400 Amsterdam 1098 XH NL
W.（Matthijs）Mekking NLnet实验室科技园400阿姆斯特丹1098 XH NL
EMail: matthijs@nlnetlabs.nl
URI: http://www.nlnetlabs.nl/
EMail: matthijs@nlnetlabs.nl
URI: http://www.nlnetlabs.nl/