Internet Engineering Task Force (IETF) K. Fujiwara
Request for Comments: 8198 JPRS
Updates: 4035 A. Kato
Category: Standards Track Keio/WIDE
ISSN: 2070-1721 W. Kumari
Google
July 2017
Internet Engineering Task Force (IETF) K. Fujiwara
Request for Comments: 8198 JPRS
Updates: 4035 A. Kato
Category: Standards Track Keio/WIDE
ISSN: 2070-1721 W. Kumari
Google
July 2017
Aggressive Use of DNSSEC-Validated Cache
积极使用DNSSEC验证缓存
Abstract
摘要
The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances.
DNS依靠缓存来扩展；但是，缓存查找通常需要精确匹配。本文档规定了NSEC/NSEC3资源记录的使用，以允许DNSSEC验证解析程序在一定范围内生成否定答案，并通过通配符生成肯定答案。这提高了性能，减少了延迟，降低了权威服务器和递归服务器上的资源利用率，并增加了隐私。此外，在某些情况下，它可能有助于提高对某些拒绝服务攻击的恢复能力。
This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards.
本文档更新了RFC 4035，允许验证解析器基于NSEC/NSEC3记录生成否定答案，并在存在通配符的情况下生成肯定答案。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8198.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8198.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Aggressive Use of DNSSEC-Validated Cache . . . . . . . . . . 6
5.1. NSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6
5.4. Consideration on TTL . . . . . . . . . . . . . . . . . . 7
6. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Update to RFC 4035 . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Detailed Implementation Notes . . . . . . . . . . . 11
Appendix B. Procedure for Determining ENT vs. NXDOMAIN with NSEC 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Aggressive Use of DNSSEC-Validated Cache . . . . . . . . . . 6
5.1. NSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6
5.4. Consideration on TTL . . . . . . . . . . . . . . . . . . 7
6. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Update to RFC 4035 . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Detailed Implementation Notes . . . . . . . . . . . 11
Appendix B. Procedure for Determining ENT vs. NXDOMAIN with NSEC 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
A DNS negative cache exists, and is used to cache the fact that an RRset does not exist. This method of negative caching requires exact matching; this leads to unnecessary additional lookups, increases latency, leads to extra resource utilization on both authoritative and recursive servers, and decreases privacy by leaking queries.
DNS负缓存存在，用于缓存RRset不存在的事实。这种负缓存方法需要精确匹配；这会导致不必要的额外查找，增加延迟，导致权威服务器和递归服务器上的额外资源利用率，并通过泄漏查询降低隐私。
This document updates RFC 4035 to allow resolvers to use NSEC/NSEC3 resource records to synthesize negative answers from the information they have in the cache. This allows validating resolvers to respond with a negative answer immediately if the name in question falls into a range expressed by an NSEC/NSEC3 resource record already in the cache. It also allows the synthesis of positive answers in the presence of wildcard records.
本文档更新了RFC 4035，以允许解析程序使用NSEC/NSEC3资源记录根据缓存中的信息合成否定答案。这允许验证冲突解决程序在问题名称落入缓存中已存在的NSEC/NSEC3资源记录表示的范围时立即响应否定答案。它还允许在存在通配符记录的情况下合成肯定答案。
Aggressive negative caching was first proposed in Section 6 of DNSSEC Lookaside Validation (DLV) [RFC5074] in order to find covering NSEC records efficiently.
为了有效地查找覆盖NSEC记录，DNSSEC后备验证（DLV）[RFC5074]第6节首次提出了积极的负缓存。
[RFC8020] and [RES-IMPROVE] propose steps to using NXDOMAIN information for more effective caching. This document takes this technique further.
[RFC8020]和[RES-IMPROVE]提出了使用NXDOMAIN信息进行更有效缓存的步骤。本文档进一步介绍了这种技术。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Many of the specialized terms used in this document are defined in DNS Terminology [RFC7719].
本文档中使用的许多专用术语在DNS术语[RFC7719]中定义。
The key words "source of synthesis" in this document are to be interpreted as described in [RFC4592].
本文件中的关键词“合成来源”应按照[RFC4592]中的描述进行解释。
The DNS negative cache caches negative (non-existent) information, and requires an exact match in most instances [RFC2308].
DNS负缓存缓存负（不存在）信息，在大多数情况下需要精确匹配[RFC2308]。
Assume that the (DNSSEC-signed) "example.com" zone contains:
假设（DNSSEC签名的）“example.com”区域包含：
albatross.example.com. IN A 192.0.2.1 elephant.example.com. IN A 192.0.2.2 zebra.example.com. IN A 192.0.2.3
信天翁网。在192.0.2.1 elephant.example.com中。在192.0.2.2 zebra.example.com中。在192.0.2.3中
If a validating resolver receives a query for cat.example.com, it contacts its resolver (which may be itself) to query the example.com servers and will get back an NSEC record stating that there are no records (alphabetically) between albatross and elephant, or an NSEC3 record stating there is nothing between two hashed names. The resolver then knows that cat.example.com does not exist; however, it does not use the fact that the proof covers a range (albatross to elephant) to suppress queries for other labels that fall within this range. This means that if the validating resolver gets a query for ball.example.com (or dog.example.com) it will once again go off and query the example.com servers for these names.
如果验证解析程序收到对cat.example.com的查询，它将联系其解析程序（可能是它自己）查询example.com服务器，并将返回一条NSEC记录，说明信天翁和大象之间没有任何记录（按字母顺序排列），或一条NSEC3记录，说明两个哈希名称之间没有任何内容。然后，解析程序知道cat.example.com不存在；但是，它并没有利用证据覆盖范围（信天翁到大象）这一事实来抑制对该范围内其他标签的查询。这意味着，如果验证解析程序获得对ball.example.com（或dog.example.com）的查询，它将再次关闭并查询example.com服务器中的这些名称。
Apart from wasting bandwidth, this also wastes resources on the recursive server (it needs to keep state for outstanding queries), wastes resources on the authoritative server (it has to answer additional questions), increases latency (the end user has to wait longer than necessary to get back an NXDOMAIN answer), can be used by attackers to cause a DoS, and also has privacy implications (e.g., typos leak out further than necessary).
除了浪费带宽外，这还浪费了递归服务器上的资源（它需要为未完成的查询保持状态），浪费了权威服务器上的资源（它必须回答其他问题），增加了延迟（最终用户必须等待更长的时间才能返回域答案），攻击者可利用该漏洞造成拒绝服务，并且还可能涉及隐私问题（例如，输入错误泄漏的程度超出必要程度）。
Another example: assume that the (DNSSEC-signed) "example.org" zone contains:
另一个示例：假设（DNSSEC签名的）“example.org”区域包含：
avocado.example.org. IN A 192.0.2.1 *.example.org. IN A 192.0.2.2 zucchini.example.org. IN A 192.0.2.3
avocado.example.org。在192.0.2.1*.example.org中。在192.0.2.2 zucchini.example.org中。在192.0.2.3中
If a query is received for leek.example.org, the system contacts its resolver (which may be itself) to query the example.org servers and will get back an NSEC record stating that there are no records (alphabetically) between avocado and zucchini (or an NSEC3 record stating there is nothing between two hashed names), as well as an answer for leek.example.org, with the label count of the signature set to two (see [RFC7129], Section 5.3 for more details).
如果收到leek.example.org的查询，系统会联系其解析程序（可能是自身）来查询example.org服务器，并将返回一条NSEC记录，说明鳄梨和西葫芦之间没有任何记录（按字母顺序排列）（或一条NSEC3记录，说明两个散列名称之间没有任何内容），以及leek.example.org的答案，签名的标签计数设置为2（有关更多详细信息，请参见[RFC7129]，第5.3节）。
If the validating resolver gets a query for banana.example.org, it will once again go off and query the example.org servers for banana.example.org (even though it already has proof that there is a wildcard record) -- just like above, this has privacy implications, wastes resources, can be used to contribute to a DoS, etc.
如果验证解析程序获得了对banana.example.org的查询，它将再次关闭并查询banana.example.org的example.org服务器（即使它已经有证据证明存在通配符记录）——就像上面所述，这会影响隐私，浪费资源，可用于提交DoS，等等。
DNSSEC [RFC4035] and [RFC5155] both provide "authenticated denial of existence"; this is a cryptographic proof that the queried-for name does not exist or the type does not exist. Proof that a name does not exist is accomplished by providing a (DNSSEC-secured) record containing the names that appear alphabetically before and after the
DNSSEC[RFC4035]和[RFC5155]都提供“经验证的拒绝存在”；这是查询的名称不存在或类型不存在的加密证明。通过提供一个（DNSSEC安全）记录来证明名称不存在，该记录包含名称前后的字母顺序
queried-for name. In the first example above, if the (DNSSEC-validating) recursive server were to query for dog.example.com, it would receive a (signed) NSEC record stating that there are no labels between "albatross" and "elephant" (or, for NSEC3, a similar pair of hashed names). This is a signed, cryptographic proof that these names are the ones before and after the queried-for label. As dog.example.com falls within this range, the recursive server knows that dog.example.com really does not exist. Proof that a type does not exist is accomplished by providing a (DNSSEC-secured) record containing the queried-for name, and a type bitmap that does not include the requested type.
查询名称。在上面的第一个示例中，如果（DNSSEC验证）递归服务器要查询dog.example.com，它将收到一个（签名的）NSEC记录，说明“信天翁”和“大象”之间没有标签（或者，对于NSEC3，一对类似的散列名称）。这是一个签名的加密证明，证明这些名称是查询的for标签前后的名称。由于dog.example.com属于此范围，递归服务器知道dog.example.com实际上不存在。类型不存在的证明是通过提供一个（DNSSEC安全）记录来完成的，该记录包含所查询的名称，以及一个不包含所请求类型的类型位图。
This document specifies that this NSEC/NSEC3 record should be used to generate negative answers for any queries that the validating server receives that fall within the range covered by the record (for the TTL for the record). This document also specifies that a positive answer should be generated for any queries that the validating server receives that are proven to be covered by a wildcard record.
本文档规定，此NSEC/NSEC3记录应用于为验证服务器收到的任何查询生成否定答案，这些查询属于该记录覆盖的范围（对于该记录的TTL）。本文档还规定，对于验证服务器收到的任何查询，如果被证明包含在通配符记录中，则应生成肯定答案。
Section 4.5 of [RFC4035] says:
[RFC4035]第4.5节规定：
In theory, a resolver could use wildcards or NSEC RRs to generate positive and negative responses (respectively) until the TTL or signatures on the records in question expire. However, it seems prudent for resolvers to avoid blocking new authoritative data or synthesizing new data on their own. Resolvers that follow this recommendation will have a more consistent view of the namespace.
理论上，解析程序可以使用通配符或NSEC RRs（分别）生成肯定和否定响应，直到相关记录上的TTL或签名过期。然而，对于解析器来说，避免阻塞新的权威数据或自行合成新数据似乎是谨慎的。遵循此建议的解析器将具有更一致的命名空间视图。
And, earlier, Section 4.5 of [RFC4035] says:
[RFC4035]前面的第4.5节说：
The reason for these recommendations is that, between the initial query and the expiration of the data from the cache, the authoritative data might have been changed (for example, via dynamic update).
这些建议的原因是，在初始查询和缓存中的数据过期之间，权威数据可能已经更改（例如，通过动态更新）。
In other words, if a resolver generates negative answers from an NSEC record, it will not send any queries for names within that NSEC range (for the TTL). If a new name is added to the zone during this interval, the resolver will not know this. Similarly, if the resolver is generating responses from a wildcard record, it will continue to do so (for the TTL).
换句话说，如果解析程序从NSEC记录生成否定答案，它将不会发送该NSEC范围内的任何名称查询（对于TTL）。如果在此间隔期间向区域添加了新名称，解析程序将不知道这一点。类似地，如果解析器正在从通配符记录生成响应，它将继续这样做（对于TTL）。
We believe that this recommendation can be relaxed because, in the absence of this technique, a lookup for the exact name could have come in during this interval, and so a negative answer could already be cached (see [RFC2308] for more background). This means that zone operators should have no expectation that an added name would work immediately. With DNSSEC and aggressive use of DNSSEC-validated
我们认为这一建议可以放宽，因为在没有这种技术的情况下，可能会在这段时间内找到确切的名称，因此可能已经缓存了否定的答案（有关更多背景信息，请参见[RFC2308]）。这意味着分区操作员不应期望添加的名称立即起作用。通过DNSSEC和积极使用DNSSEC验证
cache, the TTL of the NSEC/NSEC3 record and the SOA.MINIMUM field are the authoritative statement of how quickly a name can start working within a zone.
cache、NSEC/NSEC3记录的TTL和SOA.MINIMUM字段是一个名称在区域内开始工作的速度的权威声明。
This document relaxes the restriction given in Section 4.5 of [RFC4035]. See Section 7 for more detail.
本文件放宽了[RFC4035]第4.5节中给出的限制。详见第7节。
If the negative cache of the validating resolver has sufficient information to validate the query, the resolver SHOULD use NSEC, NSEC3, and wildcard records to synthesize answers as described in this document. Otherwise, it MUST fall back to send the query to the authoritative DNS servers.
如果验证解析程序的负缓存具有足够的信息来验证查询，则解析程序应使用NSEC、NSEC3和通配符记录来合成本文档中所述的答案。否则，它必须返回以将查询发送到权威DNS服务器。
The validating resolver needs to check the existence of an NSEC RR matching/covering the source of synthesis and an NSEC RR covering the query name.
验证解析器需要检查是否存在与合成源匹配/覆盖的NSEC RR以及是否存在覆盖查询名称的NSEC RR。
If denial of existence can be determined according to the rules set out in Section 5.4 of [RFC4035], using NSEC records in the cache, then the resolver can immediately return an NXDOMAIN or NODATA (as appropriate) response.
如果可以根据[RFC4035]第5.4节中规定的规则，使用缓存中的NSEC记录确定拒绝存在，则解析程序可以立即返回NXDOMAIN或NODATA（视情况而定）响应。
NSEC3 aggressive negative caching is more difficult than NSEC aggressive caching. If the zone is signed with NSEC3, the validating resolver needs to check the existence of non-terminals and wildcards that derive from query names.
NSEC3主动负缓存比NSEC主动缓存更困难。如果区域使用NSEC3签名，验证解析程序需要检查是否存在从查询名称派生的非终端和通配符。
If denial of existence can be determined according to the rules set out in [RFC5155], Sections 8.4, 8.5, 8.6, and 8.7, using NSEC3 records in the cache, then the resolver can immediately return an NXDOMAIN or NODATA response (as appropriate).
如果可以根据[RFC5155]第8.4、8.5、8.6和8.7节中规定的规则，使用缓存中的NSEC3记录来确定拒绝存在，则解析程序可以立即返回NXDOMIN或NODATA响应（视情况而定）。
If a covering NSEC3 RR has an Opt-Out flag, the covering NSEC3 RR does not prove the non-existence of the domain name and the aggressive negative caching is not possible for the domain name.
如果覆盖NSEC3 RR具有选择退出标志，则覆盖NSEC3 RR不会证明域名不存在，并且不可能对域名进行积极的负面缓存。
The last paragraph of [RFC4035], Section 4.5 also discusses the use of wildcards and NSEC RRs to generate positive responses and recommends that it not be relied upon. Just like the case for the
[RFC4035]第4.5节的最后一段还讨论了使用通配符和NSEC RRs生成积极响应，并建议不要依赖它。就像这个案子一样
aggressive use of NSEC/NSEC3 for negative answers, we revise this recommendation.
积极使用NSEC/NSEC3作为否定答案，我们修订了本建议。
As long as the validating resolver can determine that a name would not exist without the wildcard match, determined according to the rules set out in Section 5.3.4 of [RFC4035] (NSEC), or in Section 8.8 of [RFC5155], it SHOULD synthesize an answer (or NODATA response) for that name using the cache-deduced wildcard. If the corresponding wildcard record is not in the cache, it MUST fall back to send the query to the authoritative DNS servers.
只要验证解析程序能够确定如果没有根据[RFC4035]（NSEC）第5.3.4节或[RFC5155]第8.8节中规定的规则确定的通配符匹配，名称将不存在，它就应该使用缓存推导的通配符合成该名称的答案（或节点数据响应）。如果相应的通配符记录不在缓存中，它必须回退以将查询发送到权威DNS服务器。
The TTL value of negative information is especially important, because newly added domain names cannot be used while the negative information is effective.
负面信息的TTL值尤其重要，因为当负面信息有效时，不能使用新添加的域名。
Section 5 of [RFC2308] suggests a maximum default negative cache TTL value of 3 hours (10800). It is RECOMMENDED that validating resolvers limit the maximum effective TTL value of negative responses (NSEC/NSEC3 RRs) to this same value.
[RFC2308]第5节建议最大默认负缓存TTL值为3小时（10800）。建议验证解析器将否定响应（NSEC/NSEC3 RRs）的最大有效TTL值限制在此相同值。
Section 5 of [RFC2308] also states that a negative cache entry TTL is taken from the minimum of the SOA.MINIMUM field and SOA's TTL. This can be less than the TTL of an NSEC or NSEC3 record, since their TTL is equal to the SOA.MINIMUM field (see [RFC4035], Section 2.3 and [RFC5155], Section 3).
[RFC2308]的第5节还指出，从SOA.minimum字段和SOA的TTL的最小值中获取负缓存条目TTL。这可能小于NSEC或NSEC3记录的TTL，因为它们的TTL等于SOA.MINIMUM字段（请参见[RFC4035]，第2.3节和[RFC5155]，第3节）。
A resolver that supports aggressive use of NSEC and NSEC3 SHOULD reduce the TTL of NSEC and NSEC3 records to match the SOA.MINIMUM field in the authority section of a negative response, if SOA.MINIMUM is smaller.
支持积极使用NSEC和NSEC3的解析器应减少NSEC和NSEC3记录的TTL，以匹配否定响应的权限部分中的SOA.MINIMUM字段（如果SOA.MINIMUM较小）。
The techniques described in this document provide a number of benefits, including (in no specific order):
本文档中描述的技术提供了许多好处，包括（无特定顺序）：
Reduced latency: By answering directly from cache, validating resolvers can immediately inform clients that the name they are looking for does not exist, improving the user experience.
减少延迟：通过直接从缓存应答，验证解析程序可以立即通知客户端他们正在查找的名称不存在，从而改善用户体验。
Decreased recursive server load: By answering queries from the cache by synthesizing answers, validating servers avoid having to send a query and wait for a response. In addition to decreasing the bandwidth used, it also means that the server does not need to allocate and maintain state, thereby decreasing memory and CPU load.
减少了递归服务器负载：通过合成答案来回答缓存中的查询，验证服务器可以避免发送查询和等待响应。除了减少使用的带宽外，这还意味着服务器不需要分配和维护状态，从而减少内存和CPU负载。
Decreased authoritative server load: Because recursive servers can answer queries without asking the authoritative server, the authoritative servers receive fewer queries. This decreases the authoritative server bandwidth, queries per second, and CPU utilization.
权威服务器负载减少：因为递归服务器可以在不询问权威服务器的情况下回答查询，所以权威服务器接收的查询更少。这会降低权威服务器带宽、每秒查询数和CPU利用率。
The scale of the benefit depends upon multiple factors, including the query distribution. For example, at the time of this writing, around 65% of queries to root name servers result in NXDOMAIN responses (see statistics from [ROOT-SERVERS]); this technique will eliminate a sizable quantity of these.
好处的规模取决于多个因素，包括查询分布。例如，在撰写本文时，大约65%对根名称服务器的查询会导致NXDOMAIN响应（请参阅[root-servers]的统计数据）；这项技术将消除相当数量的这种情况。
The technique described in this document may also mitigate so-called "random QNAME attacks", in which attackers send many queries for random subdomains to resolvers. As the resolver will not have the answers cached, it has to ask external servers for each random query, leading to a DoS on the authoritative servers (and often resolvers). The technique may help mitigate these attacks by allowing the resolver to answer directly from the cache for any random queries that fall within already requested ranges. It will not always work as an effective defense, not least because not many zones are DNSSEC signed at all -- but it will still provide an additional layer of defense.
本文档中描述的技术还可以缓解所谓的“随机QNAME攻击”，在这种攻击中，攻击者向解析程序发送许多随机子域查询。由于解析程序不会缓存答案，因此它必须为每个随机查询请求外部服务器，从而导致权威服务器（通常是解析程序）上的拒绝服务。该技术允许解析器直接从缓存中回答已请求范围内的任何随机查询，从而有助于减轻这些攻击。它并不总是能起到有效的防御作用，尤其是因为DNSSEC签署的区域并不多——但它仍将提供额外的防御层。
As these benefits are only accrued by those using DNSSEC, it is hoped that these techniques will lead to more DNSSEC deployment.
由于这些好处只有使用DNSSEC的人才能获得，因此希望这些技术将导致更多的DNSSEC部署。
Section 4.5 of [RFC4035] shows that "In theory, a resolver could use wildcards or NSEC RRs to generate positive and negative responses (respectively) until the TTL or signatures on the records in question expire. However, it seems prudent for resolvers to avoid blocking new authoritative data or synthesizing new data on their own. Resolvers that follow this recommendation will have a more consistent view of the namespace".
[RFC4035]的第4.5节表明，“理论上，解析器可以使用通配符或NSEC RRs（分别）生成正面和负面响应直到相关记录上的TTL或签名过期。但是，冲突解决程序似乎应该谨慎地避免阻止新的权威数据或自行合成新数据。遵循此建议的冲突解决程序将具有更一致的命名空间视图”。
The paragraph is updated as follows:
本段更新如下：
+-----------------------------------------------------------------+
| Once the records are validated, DNSSEC-enabled validating |
| resolvers SHOULD use wildcards and NSEC/NSEC3 resource records |
| to generate positive and negative responses until the |
| effective TTLs or signatures for those records expire. |
+-----------------------------------------------------------------+
+-----------------------------------------------------------------+
| Once the records are validated, DNSSEC-enabled validating |
| resolvers SHOULD use wildcards and NSEC/NSEC3 resource records |
| to generate positive and negative responses until the |
| effective TTLs or signatures for those records expire. |
+-----------------------------------------------------------------+
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
Use of NSEC/NSEC3 resource records without DNSSEC validation may create serious security issues, and so this technique requires DNSSEC validation.
在未经DNSSEC验证的情况下使用NSEC/NSEC3资源记录可能会产生严重的安全问题，因此此技术需要DNSSEC验证。
Newly registered resource records may not be used immediately. However, choosing a suitable TTL value and a negative cache TTL value (SOA.MINIMUM field) will mitigate the delay concern, and it is not a security problem.
新注册的资源记录不能立即使用。但是，选择一个合适的TTL值和一个负的缓存TTL值（SOA.MINIMUM字段）将减轻延迟问题，这不是一个安全问题。
It is also suggested to limit the maximum TTL value of NSEC/NSEC3 resource records in the negative cache to, for example, 10800 seconds (3 hours), to mitigate this issue.
还建议将负缓存中NSEC/NSEC3资源记录的最大TTL值限制为例如10800秒（3小时），以缓解此问题。
Although the TTL of NSEC/NSEC3 records is typically fairly short (minutes or hours), their RRSIG expiration time can be much further in the future (weeks). An attacker who is able to successfully spoof responses might poison a cache with old NSEC/NSEC3 records. If the resolver is not making aggressive use of NSEC/NSEC3, the attacker has to repeat the attack for every query. If the resolver is making aggressive use of NSEC/NSEC3, one successful attack would be able to suppress many queries for new names, up to the negative TTL.
尽管NSEC/NSEC3记录的TTL通常相当短（分钟或小时），但它们的RRSIG过期时间在未来可能会更长（几周）。能够成功欺骗响应的攻击者可能会使用旧的NSEC/NSEC3记录毒害缓存。如果解析程序未积极使用NSEC/NSEC3，则攻击者必须对每个查询重复攻击。如果冲突解决程序正在积极使用NSEC/NSEC3，一次成功的攻击将能够抑制许多对新名称的查询，直到负面TTL。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, <http://www.rfc-editor.org/info/rfc2308>.
[RFC2308]Andrews，M.“DNS查询的反向缓存（DNS NCACHE）”，RFC 2308，DOI 10.17487/RFC2308，1998年3月<http://www.rfc-editor.org/info/rfc2308>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，DOI 10.17487/RFC4035，2005年3月<http://www.rfc-editor.org/info/rfc4035>.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, DOI 10.17487/RFC4592, July 2006, <http://www.rfc-editor.org/info/rfc4592>.
[RFC4592]Lewis，E.，“通配符在域名系统中的作用”，RFC 4592，DOI 10.17487/RFC4592，2006年7月<http://www.rfc-editor.org/info/rfc4592>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, <http://www.rfc-editor.org/info/rfc5155>.
[RFC5155]Laurie，B.，Sisson，G.，Arends，R.，和D.Blacka，“DNS安全（DNSSEC）哈希认证拒绝存在”，RFC 5155，DOI 10.17487/RFC5155，2008年3月<http://www.rfc-editor.org/info/rfc5155>.
[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, February 2014, <http://www.rfc-editor.org/info/rfc7129>.
[RFC7129]Gieben，R.和W.Mekking，“DNS中的认证拒绝存在”，RFC 7129，DOI 10.17487/RFC7129，2014年2月<http://www.rfc-editor.org/info/rfc7129>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, <http://www.rfc-editor.org/info/rfc7719>.
[RFC7719]Hoffman，P.，Sullivan，A.和K.Fujiwara，“DNS术语”，RFC 7719，DOI 10.17487/RFC77192015年12月<http://www.rfc-editor.org/info/rfc7719>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
[RES-IMPROVE] Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS Resolvers for Resiliency, Robustness, and Responsiveness", Work in Progress, draft-vixie-dnsext-resimprove-00, June 2010.
[RES-IMPROVE]Vixie，P.，Joffe，R.，和F.Neves，“DNS解析程序的弹性、健壮性和响应性改进”，正在进行的工作，草稿-Vixie-dnsext-resimprove-00，2010年6月。
[RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, DOI 10.17487/RFC5074, November 2007, <http://www.rfc-editor.org/info/rfc5074>.
[RFC5074]Weiler，S.，“DNSSEC后备验证（DLV）”，RFC 5074，DOI 10.17487/RFC5074，2007年11月<http://www.rfc-editor.org/info/rfc5074>.
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, November 2016, <http://www.rfc-editor.org/info/rfc8020>.
[RFC8020]Bortzmeyer，S.和S.Huque，“NXDOMAIN:下面真的什么都没有”，RFC 8020，DOI 10.17487/RFC8020，2016年11月<http://www.rfc-editor.org/info/rfc8020>.
[ROOT-SERVERS] "Root Server Technical Operations Assn", <http://www.root-servers.org/>.
[根服务器]“根服务器技术操作助理”<http://www.root-servers.org/>.
o Previously, cached negative responses were indexed by QNAME, QCLASS, QTYPE, and the setting of the CD bit (see RFC 4035, Section 4.7), and only queries matching the index key would be answered from the cache. With aggressive negative caching, the validator, in addition to checking to see if the answer is in its cache before sending a query, checks to see whether any cached and validated NSEC record denies the existence of the sought record(s). Using aggressive negative caching, a validator will not make queries for any name covered by a cached and validated NSEC record. Furthermore, a validator answering queries from clients will synthesize a negative answer (or NODATA response) whenever it has an applicable validated NSEC in its cache unless the CD bit was set on the incoming query. (Imported from Section 6 of [RFC5074].)
o 以前，缓存的否定响应通过QNAME、QCLASS、QTYPE和CD位的设置进行索引（请参阅RFC 4035，第4.7节），并且只有与索引键匹配的查询才会从缓存中得到回答。使用积极的负缓存，验证程序除了在发送查询之前检查答案是否在其缓存中之外，还检查是否有任何缓存和验证的NSEC记录否认所查找记录的存在。使用积极的负缓存，验证器将不会对缓存和验证的NSEC记录所包含的任何名称进行查询。此外，回答客户机查询的验证器将在其缓存中有适用的已验证NSEC时合成否定答案（或NODATA响应），除非传入查询上设置了CD位。（从[RFC5074]第6节导入）
o Implementing aggressive negative caching suggests that a validator will need to build an ordered data structure of NSEC and NSEC3 records for each signer domain name of NSEC/NSEC3 records in order to efficiently find covering NSEC/NSEC3 records. Call the table as "NSEC_TABLE". (Imported from Section 6.1 of [RFC5074] and expanded.)
o 实施积极的负面缓存意味着验证器需要为NSEC/NSEC3记录的每个签名者域名构建NSEC和NSEC3记录的有序数据结构，以便有效地查找覆盖NSEC/NSEC3记录。将该表称为“NSEC_表”。（从[RFC5074]第6.1节引入并扩展）
o The aggressive negative caching may be inserted at the cache lookup part of the recursive resolvers.
o 可以在递归解析器的缓存查找部分插入积极的负缓存。
o If errors happen in an aggressive negative caching algorithm, resolvers MUST fall back to resolve the query as usual. "Resolve the query as usual" means that the resolver must process the query as though it does not implement aggressive negative caching.
o 如果在激进的负缓存算法中发生错误，解析程序必须像往常一样回退以解析查询。“像往常一样解析查询”意味着解析程序必须处理查询，就好像它没有实现积极的负缓存一样。
This procedure outlines how to determine if a given name does not exist, or is an ENT (empty non-terminal; see [RFC5155], Section 1.3) with NSEC.
本程序概述了如何确定给定名称是否不存在，或是否是NSEC的ENT（空非终端；请参阅[RFC5155]，第1.3节）。
If the NSEC record has not been verified as secure, discard it.
如果NSEC记录未被验证为安全记录，则将其丢弃。
If the given name sorts before or matches the NSEC owner name, discard it as it does not prove the NXDOMAIN or ENT.
如果给定名称排序在NSEC所有者名称之前或与NSEC所有者名称匹配，则放弃该名称，因为它不能证明NXDOMAIN或ENT。
If the given name is a subdomain of the NSEC owner name and the NS bit is present and the SOA bit is absent, then discard the NSEC as it is from a parent zone.
如果给定的名称是NSEC所有者名称的子域，且存在NS位且不存在SOA位，则放弃NSEC，因为它来自父区域。
If the next domain name sorts after the NSEC owner name and the given name sorts after or matches next domain name, then discard the NSEC record as it does not prove the NXDOMAIN or ENT.
如果下一个域名排序在NSEC所有者名称之后，而给定名称排序在下一个域名之后或与下一个域名匹配，则丢弃NSEC记录，因为它不能证明NXDOMAIN或ENT。
If the next domain name sorts before or matches the NSEC owner name and the given name is not a subdomain of the next domain name, then discard the NSEC as it does not prove the NXDOMAIN or ENT.
如果下一个域名排序在NSEC所有者名称之前或与之匹配，且给定名称不是下一个域名的子域，则放弃NSEC，因为它不能证明NXDOMAIN或ENT。
You now have an NSEC record that proves the NXDOMAIN or ENT.
您现在有一个NSEC记录，可以证明NXDOMAIN或ENT。
If the next domain name is a subdomain of the given name, you have an ENT. Otherwise, you have an NXDOMAIN.
如果下一个域名是给定名称的子域，则您有一个ENT。否则，您将拥有一个NXDOMAIN。
Acknowledgments
致谢
The authors gratefully acknowledge DNSSEC Lookaside Validation (DLV) [RFC5074] author Samuel Weiler and the Unbound developers.
作者感谢DNSSEC Lookaside Validation（DLV）[RFC5074]作者Samuel Weiler和未绑定的开发人员。
Thanks to Mark Andrews for providing the helpful notes for implementors provided in Appendix B.
感谢Mark Andrews为附录B中的实施者提供了有用的说明。
The authors would like to specifically thank Stephane Bortzmeyer (for standing next to and helping edit), Ralph Dolmans, Tony Finch, Tatuya JINMEI for extensive review and comments, and also Mark Andrews, Casey Deccio, Alexander Dupuy, Olafur Gudmundsson, Bob Harold, Shumon Huque, John Levine, Pieter Lexis, Matthijs Mekking (who even sent pull requests!), and Ondrej Sury.
作者特别感谢Stephane Bortzmeyer（站在旁边帮助编辑）、Ralph Dolmans、Tony Finch、Tatuya JINMEI的广泛评论和评论，以及Mark Andrews、Casey Deccio、Alexander Dupuy、Olafur Gudmundsson、Bob Harold、Shumon Huque、John Levine、Pieter Lexis、Matthijs Mekking（他们甚至发出了拉车请求！），以及昂德雷·苏里。
Authors' Addresses
作者地址
Kazunori Fujiwara Japan Registry Services Co., Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan
日本东京101-0065西神田千代田区3-8-1号千代田第一大厦东13楼藤原和仁日本注册服务有限公司
Phone: +81 3 5215 8451
Email: fujiwara@jprs.co.jp
Phone: +81 3 5215 8451
Email: fujiwara@jprs.co.jp
Akira Kato Keio University/WIDE Project Graduate School of Media Design, 4-1-1 Hiyoshi Kohoku, Yokohama 223-8526 Japan
秋叶加藤庆应大学/广域项目媒体设计研究生院，4-1-1日本横滨市小冈市，223-8526
Phone: +81 45 564 2490
Email: kato@wide.ad.jp
Phone: +81 45 564 2490
Email: kato@wide.ad.jp
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Warren Kumari谷歌1600圆形剧场公园道山景，加利福尼亚州94043美利坚合众国
Email: warren@kumari.net
Email: warren@kumari.net