Internet Engineering Task Force (IETF) S. Bortzmeyer
Request for Comments: 8020 AFNIC
Updates: 1034, 2308 S. Huque
Category: Standards Track Verisign Labs
ISSN: 2070-1721 November 2016
Internet Engineering Task Force (IETF) S. Bortzmeyer
Request for Comments: 8020 AFNIC
Updates: 1034, 2308 S. Huque
Category: Standards Track Verisign Labs
ISSN: 2070-1721 November 2016
NXDOMAIN: There Really Is Nothing Underneath
NXDOMAIN：下面真的什么都没有
Abstract
摘要
This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist.
本文档明确指出，当DNS解析程序收到响应代码为NXDOMAIN的响应时，这意味着被拒绝的域名及其下的所有名称都不存在。
This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them.
本文件澄清了RFC 1034并修改了RFC 2308的一部分：它更新了两者。
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/rfc8020.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8020.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 and Background .....................................2
1.1. Terminology ................................................3
2. Rules ...........................................................3
3. Updates to RFCs .................................................5
3.1. Updates to RFC 1034 ........................................5
3.2. Updates to RFC 2308 ........................................5
4. Benefits ........................................................5
5. Possible Issues .................................................6
6. Implementation Considerations ...................................6
7. Security Considerations .........................................7
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................8
Appendix A. Why can't we just use the owner name of the returned
SOA? ...................................................9
Appendix B. Related Approaches .....................................9
Acknowledgments ....................................................9
Authors' Addresses ................................................10
1. Introduction and Background .....................................2
1.1. Terminology ................................................3
2. Rules ...........................................................3
3. Updates to RFCs .................................................5
3.1. Updates to RFC 1034 ........................................5
3.2. Updates to RFC 2308 ........................................5
4. Benefits ........................................................5
5. Possible Issues .................................................6
6. Implementation Considerations ...................................6
7. Security Considerations .........................................7
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................8
Appendix A. Why can't we just use the owner name of the returned
SOA? ...................................................9
Appendix B. Related Approaches .....................................9
Acknowledgments ....................................................9
Authors' Addresses ................................................10
The DNS protocol [RFC1035] defines response code 3 as "Name Error", or "NXDOMAIN" [RFC2308], which means that the queried domain name does not exist in the DNS. Since domain names are represented as a tree of labels ([RFC1034], Section 3.1), nonexistence of a node implies nonexistence of the entire subtree rooted at this node.
DNS协议[RFC1035]将响应代码3定义为“名称错误”或“NXDOMAIN”[RFC2308]，这意味着查询的域名在DNS中不存在。由于域名表示为标签树（[RFC1034]，第3.1节），因此节点不存在意味着根在此节点的整个子树不存在。
The DNS iterative resolution algorithm precisely interprets the NXDOMAIN signal in this manner. If it encounters an NXDOMAIN response code from an authoritative server, it immediately stops iteration and returns the NXDOMAIN response to the querier.
DNS迭代解析算法以这种方式精确解释NXDOMAIN信号。如果它遇到来自权威服务器的NXDOMAIN响应代码，它会立即停止迭代并将NXDOMAIN响应返回给查询器。
However, in most known existing resolvers today, a cached nonexistence for a domain is not considered "proof" that there can be no child domains underneath. This is due to an ambiguity in [RFC1034] that failed to distinguish Empty Non-Terminal (ENT) names ([RFC7719]) from nonexistent names (Section 3.1). The distinction became especially important for the development of DNSSEC, which provides proof of nonexistence. [RFC4035], Section 3.1.3.2, describes how security-aware authoritative name servers make the distinction, but no existing RFCs describe the behavior for recursive name servers.
然而，在当今大多数已知的现有解析程序中，域的缓存不存在并不被认为是下面不可能有子域的“证据”。这是由于[RFC1034]中存在歧义，未能区分空的非终端（ENT）名称（[RFC7719]）和不存在的名称（第3.1节）。这种区别对于DNSSEC的发展尤为重要，DNSSEC提供了不存在的证据。[RFC4035]第3.1.3.2节描述了具有安全意识的权威名称服务器如何进行区分，但没有现有的RFC描述递归名称服务器的行为。
This document specifies that an NXDOMAIN response for a domain name means that no child domains underneath the queried name exist either; furthermore, it means that DNS resolvers should interpret cached nonexistence in this manner. Since the domain names are organized in a tree, it is a simple consequence of the tree structure: nonexistence of a node implies nonexistence of the entire subtree rooted at this node.
本文档规定，域名的NXDOMAIN响应意味着查询名称下也不存在子域；此外，这意味着DNS解析程序应该以这种方式解释缓存的不存在。由于域名组织在树中，这是树结构的一个简单结果：节点不存在意味着根在此节点上的整个子树不存在。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
"QNAME": defined in [RFC1034] and in [RFC1035], Section 4.1.2, but, because [RFC2308] provides a different definition, we repeat the original one here: the QNAME is the domain name in the question section.
“QNAME”：在[RFC1034]和[RFC1035]第4.1.2节中定义，但是，由于[RFC2308]提供了不同的定义，我们在此重复原始定义：QNAME是问题部分中的域名。
"Denied name": the domain name whose existence has been denied by a response RCODE of NXDOMAIN. In most cases, it is the QNAME but, because of [RFC6604], it is not always the case.
“拒绝名称”：其存在已被NXDOMAIN的响应RCODE拒绝的域名。在大多数情况下，它是QNAME，但由于[RFC6604]，情况并非总是如此。
Other terms are defined in [RFC1034], [RFC1035], and (like NXDOMAIN itself) in the more recent [RFC7719].
其他术语在[RFC1034]、[RFC1035]和（与NXDOMAIN本身类似）最近的[RFC7719]中定义。
The domain name space is conceptually defined in terms of a tree structure. The implementation of a DNS resolver/cache MAY use a tree or other data structures. The cache being a subset of the data in the domain name space, it is much easier to reason about it in terms of that tree structure and to describe things in those terms (names under/above, descendant names, subtrees, etc.). In fact, the DNS algorithm description in [RFC1034] even states an assumption that the cache is a tree structure, so the precedent is already well established: see its Section 4.3.2, which says "The following algorithm assumes that the RRs are organized in several tree structures, one for each zone, and another for the cache..." So, in this document, each time we talk about a tree or tree operations, we're referring to the model, not to the actual implementation.
域名空间在概念上是按照树结构定义的。DNS解析程序/缓存的实现可以使用树或其他数据结构。缓存是域名空间中数据的一个子集，它更容易根据树结构进行推理，并用这些术语（上面/下面的名称、子代名称、子树等）进行描述。事实上，[RFC1034]中的DNS算法描述甚至提出了一个假设，即缓存是一个树状结构，因此先例已经确立：参见其第4.3.2节，其中说“以下算法假设RRs组织在多个树状结构中，每个区域一个，缓存另一个……”因此，在本文档中，每次我们讨论树或树操作时，都是指模型，而不是实际的实现。
When an iterative caching DNS resolver receives an NXDOMAIN response, it SHOULD store it in its cache and then all names and resource record sets (RRsets) at or below that node SHOULD be considered unreachable. Subsequent queries for such names SHOULD elicit an NXDOMAIN response.
当迭代缓存DNS解析器接收到NXDOMAIN响应时，它应该将其存储在其缓存中，然后该节点上或之下的所有名称和资源记录集（RRSET）都应该被视为不可访问。对此类名称的后续查询应引发NXDOMAIN响应。
But, if a resolver has cached data under the NXDOMAIN cut, it MAY continue to send it as a reply (until the TTL of this cached data expires), since this may avoid additional processing when a query is received. Section 6 provides more information about this.
但是，如果冲突解决程序在NXDOMAIN cut下缓存了数据，它可能会继续将其作为回复发送（直到该缓存数据的TTL过期），因为这样可以避免在收到查询时进行额外处理。第6节提供了有关这方面的更多信息。
Another exception is that a validating resolver MAY decide to implement the "NXDOMAIN cut" behavior (described in the first paragraph of this section) only when the NXDOMAIN response has been validated with DNSSEC. See Section 7 for the rationale.
另一个例外是，只有当NXDOMAIN响应已通过DNSSEC验证时，验证解析器才可能决定实施“NXDOMAIN cut”行为（在本节第一段中描述）。有关基本原理，请参见第7节。
The fact that a subtree does not exist is not forever: [RFC2308], Section 3, already describes the amount of time that an NXDOMAIN response may be cached (the "negative TTL").
子树不存在的事实并非永远存在：[RFC2308]，第3节已经描述了可以缓存NXDOMAIN响应的时间量（“负TTL”）。
If the NXDOMAIN response due to a cached nonexistence is from a DNSSEC-signed zone, then it will have accompanying NSEC or NSEC3 records that authenticate the nonexistence of the name. For a descendant name of the original NXDOMAIN name, the same set of NSEC or NSEC3 records proves the nonexistence of the descendant name. The iterative, caching resolver MUST return these NSEC or NSEC3 records in the response to the triggering query if the query had the DNSSEC OK (DO) bit set.
如果由于缓存不存在而导致的NXDOMAIN响应来自DNSSEC签名区域，则它将附带NSEC或NSEC3记录，以验证名称的不存在。对于原始域名的后代名称，同一组NSEC或NSEC3记录证明该后代名称不存在。如果查询设置了DNSSEC OK（DO）位，则迭代缓存解析器必须在对触发查询的响应中返回这些NSEC或NSEC3记录。
Warning: if there is a chain of CNAME (or DNAME), the name that does not exist is the last of the chain ([RFC6604]) and not the QNAME. The NXDOMAIN stored in the cache is for the denied name, not always for the QNAME.
警告：如果存在CNAME（或DNAME）链，则不存在的名称是链的最后一个（[RFC6604]），而不是QNAME。缓存中存储的NXDOMAIN用于拒绝的名称，并不总是用于QNAME。
As an example of the consequence of these rules, consider two successive queries to a resolver with a nonexisting domain 'foo.example': the first is for 'foo.example' (which results in an NXDOMAIN) and the second for 'bar.foo.example' (which also results in an NXDOMAIN). Many resolvers today will forward both queries. However, following the rules in this document ("NXDOMAIN cut"), a resolver would cache the first NXDOMAIN response, as a sign of nonexistence, and then immediately return an NXDOMAIN response for the second query, without transmitting it to an authoritative server.
作为这些规则的结果的一个例子，考虑两个连续的查询到一个具有一个不存在的域“fo.示例”的解析器：第一个是“Fo.Stase'”（它导致NxDebug），第二个是“Bar。Fo..Stase'”（这也导致了NX域）。今天，许多解析程序将转发这两个查询。但是，按照本文档中的规则（“NXDOMAIN cut”），解析程序将缓存第一个NXDOMAIN响应，作为不存在的标志，然后立即返回第二个查询的NXDOMAIN响应，而不将其传输到权威服务器。
If the first request is for 'bar.foo.example' and the second for 'baz.foo.example', then the first NXDOMAIN response won't tell anything about 'baz.foo.example'; therefore, the second query will be transmitted as it was before the use of "NXDOMAIN cut" optimization (see Appendix A).
如果第一个请求是“bar.foo.example”，第二个请求是“baz.foo.example”，那么第一个NXDOMAIN响应不会告诉任何关于“baz.foo.example”的信息；因此，第二个查询将按照使用“NXDOMAIN cut”优化之前的方式传输（见附录A）。
This document clarifies possible ambiguities in [RFC1034] that did not clearly distinguish Empty Non-Terminal (ENT) names ([RFC7719]) from nonexistent names, and it refers to subsequent documents that do. ENTs are nodes in the DNS that do not have resource record sets associated with them but have descendant nodes that do. The correct response to ENTs is NODATA (i.e., a response code of NOERROR and an empty answer section). Additional clarifying language on these points is provided in Section 7.16 of [RFC2136] and in Sections 2.2.2 and 2.2.3 of [RFC4592].
本文件澄清了[RFC1034]中可能存在的含糊不清之处，这些含糊不清之处没有明确区分空的非终端（ENT）名称（[RFC7719]）和不存在的名称，并引用了后续文件。ENT是DNS中没有与其关联的资源记录集的节点，但具有与其关联的后代节点。对ENTs的正确响应是NODATA（即NOERROR的响应代码和空的应答部分）。[RFC2136]第7.16节和[RFC4592]第2.2.2节和第2.2.3节提供了关于这些要点的其他澄清语言。
The second paragraph of Section 5 in [RFC2308] states the following:
[RFC2308]第5节第二段规定如下：
A negative answer that resulted from a name error (NXDOMAIN) should be cached such that it can be retrieved and returned in response to another query for the same <QNAME, QCLASS> that resulted in the cached negative response.
应缓存由名称错误（NXDOMAIN）导致的否定回答，以便可以检索并返回该否定回答，以响应另一个对导致缓存否定回答的相同<QNAME，QCLASS>的查询。
This document revises that paragraph to the following:
本文件将该段修改如下：
A negative answer that resulted from a name error (NXDOMAIN) should be cached such that it can be retrieved and returned in response to another query for the same <QNAME, QCLASS> that resulted in the cached negative response, or where the QNAME is a descendant of the original QNAME and the QCLASS is the same.
应缓存由名称错误（NXDOMAIN）导致的否定答案，以便在对导致缓存否定响应的相同<QNAME，QCLASS>的另一个查询作出响应时，或在QNAME是原始QNAME的后代且QCLASS相同的情况下，检索并返回该答案。
Section 2 above elaborates on the revised rule and specifies when it may be reasonable to relax or ignore it.
上文第2节详细阐述了修订后的规则，并规定了何时可以合理地放宽或忽略该规则。
The main benefit is a better efficiency of the caches. In the example above, the resolver sends only one query instead of two, the second one being answered from the cache. This will benefit the entire DNS ecosystem, since the authoritative name servers will have less unnecessary traffic to process.
主要的好处是缓存的效率更高。在上面的示例中，解析器只发送一个查询，而不是两个查询，第二个查询从缓存中应答。这将有利于整个DNS生态系统，因为权威名称服务器将有更少的不必要的流量进行处理。
The correct behavior (in [RFC1034] and made clearer in this document) is especially useful when combined with QNAME minimization [RFC7816] since it will allow a resolver to stop searching as soon as an NXDOMAIN is encountered.
当与QNAME最小化[RFC7816]结合使用时，正确的行为（在[RFC1034]中，并在本文档中明确说明）尤其有用，因为它将允许解析器在遇到NXDOMAIN时立即停止搜索。
"NXDOMAIN cut" may also help mitigate certain types of random QNAME attacks [joost-dnsterror] and [balakrichenan-dafa888], where there is a fixed suffix that does not exist. In these attacks against the authoritative name server, queries are sent to resolvers for a QNAME composed of a fixed suffix ("dafa888.wf" in one of the articles above), which is typically nonexistent, and a random prefix, different for each request. A resolver receiving these requests has to forward them to the authoritative servers. With "NXDOMAIN cut", a system administrator would just have to send to the resolver a query for the fixed suffix, the resolver would get a NXDOMAIN and then would stop forwarding the queries. (It would be better if the SOA record in the NXDOMAIN response were sufficient to find the nonexisting domain, but this is not the case, see Appendix A.)
“NXDOMAIN cut”还可能有助于缓解某些类型的随机QNAME攻击[joost dnsterror]和[balakrichenan-dafa888]，其中存在不存在的固定后缀。在这些针对权威名称服务器的攻击中，查询被发送到解析程序，以查找由固定后缀（在上面的一篇文章中为“dafa888.wf”）和随机前缀组成的QNAME，该后缀通常不存在，每个请求的前缀都不同。接收这些请求的解析程序必须将它们转发到权威服务器。使用“NXDOMAIN cut”，系统管理员只需向解析程序发送固定后缀的查询，解析程序将获得一个NXDOMAIN，然后停止转发查询。（如果NXDOMAIN响应中的SOA记录足以找到不存在的域，则更好，但事实并非如此，请参见附录A。）
Let's assume that the Top-Level Domain (TLD) example exists, but foobar.example is not delegated (so the example's name servers will reply NXDOMAIN for a query about anything.foobar.example). A system administrator decides to name the internal machines of his organization under office.foobar.example and uses a trick of his resolver to forward requests about this zone to his local authoritative name servers. "NXDOMAIN cut" would create problems here; depending on the order of requests to the resolver, it may have cached the nonexistence from example and therefore "deleted" everything under it. This document assumes that such a setup is rare and does not need to be supported.
让我们假设顶级域（TLD）示例存在，但foobar.example未被委派（因此示例的名称服务器将答复NXDOMAIN以查询任何.foobar.example）。系统管理员决定将其组织的内部计算机命名为office.foobar.example，并使用其解析程序的技巧将有关此区域的请求转发到其本地权威名称服务器。“域名切割”会在这里产生问题；根据对解析器的请求顺序，它可能缓存了示例中不存在的内容，因此“删除”了它下面的所有内容。本文档假设这样的设置很少，不需要支持。
Today, another possible issue exists; we see authoritative name servers that reply to ENT ([RFC7719], Section 6) with NXDOMAIN instead of the normal NODATA ([RFC7719], Section 3).
今天，存在另一个可能的问题；我们看到权威名称服务器使用NXDOMAIN而不是普通的节点数据（[RFC7719]，第3节）回复ENT（[RFC7719]，第6节）。
Such name servers are definitely wrong and have always been. Their behaviour is incompatible with DNSSEC. Given the advantages of "NXDOMAIN cut", there is little reason to support this behavior.
这样的名称服务器肯定是错误的，而且一直都是错误的。他们的行为与DNSSEC不相容。考虑到“NXDOMAIN cut”的优点，几乎没有理由支持这种行为。
This section is non-normative and is composed only of various things that may be useful for implementors. A recursive resolver may implement its cache in many ways. The most obvious one is a tree data structure, because it fits the data model of domain names. But, in practice, other implementations are possible, as well as various optimizations (such as a tree, augmented by an index of some common domain names).
本节是非规范性的，只包含可能对实现者有用的各种内容。递归解析器可以通过多种方式实现其缓存。最明显的是树形数据结构，因为它适合域名的数据模型。但是，在实践中，其他实现以及各种优化都是可能的（比如树，通过一些常见域名的索引进行扩展）。
If a resolver implements its cache as a tree (without any optimization), one way to follow the rules in Section 2 is as follows: when receiving the NXDOMAIN, prune the subtree of positive cache entries at that node or delete all individual cache entries for names below that node. Then, when searching downward in its cache, this iterative caching DNS resolver will stop searching if it encounters a cached nonexistence.
如果冲突解决程序将其缓存实现为树（无任何优化），则遵循第2节中规则的一种方法如下：在接收NXDOMAIN时，修剪该节点上正缓存项的子树，或删除该节点下名称的所有单个缓存项。然后，当在其缓存中向下搜索时，如果遇到缓存不存在，此迭代缓存DNS解析器将停止搜索。
Some resolvers may have a cache that is NOT organized as a tree (but, for instance, as a dictionary); therefore, they have a reason to ignore the rules of Section 2. So these rules use SHOULD and not MUST.
一些解析器可能有一个缓存，它不是以树的形式组织的（例如，作为字典组织的）；因此，他们有理由忽视第2节的规则。因此，这些规则应该使用，而不是必须使用。
The technique described in this document may help against a denial-of-service attack named "random qnames" described in Section 4.
本文档中描述的技术可能有助于抵御第4节中描述的名为“随机qnames”的拒绝服务攻击。
If a resolver does not validate the answers with DNSSEC, or if the zone is not signed, the resolver can of course be poisoned with a false NXDOMAIN, thus, "deleting" a part of the domain name tree. This denial-of-service attack is already possible without the rules of this document (but "NXDOMAIN cut" may increase its effects). The only solution is to use DNSSEC.
如果解析程序未使用DNSSEC验证答案，或者如果区域未签名，则解析程序当然可能会被错误的域名毒害，从而“删除”域名树的一部分。如果没有本文档中的规则，这种拒绝服务攻击已经是可能的（但“NXDOMAIN cut”可能会增加其影响）。唯一的解决方案是使用DNSSEC。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<http://www.rfc-editor.org/info/rfc1035>.
[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>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <http://www.rfc-editor.org/info/rfc2136>.
[RFC2136]Vixie，P.，Ed.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 2136，DOI 10.17487/RFC2136，1997年4月<http://www.rfc-editor.org/info/rfc2136>.
[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>.
[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>.
[RFC6604] Eastlake 3rd, D., "xNAME RCODE and Status Bits Clarification", RFC 6604, DOI 10.17487/RFC6604, April 2012, <http://www.rfc-editor.org/info/rfc6604>.
[RFC6604]Eastlake 3rd，D.，“X名称代码和状态位澄清”，RFC 6604，DOI 10.17487/RFC6604，2012年4月<http://www.rfc-editor.org/info/rfc6604>.
[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>.
[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>.
[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, <http://www.rfc-editor.org/info/rfc7816>.
[RFC7816]Bortzmeyer，S.，“DNS查询名称最小化以改善隐私”，RFC 7816，DOI 10.17487/RFC7816，2016年3月<http://www.rfc-editor.org/info/rfc7816>.
[DNSRRR] 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.
[DNSRRR]Vixie，P.，Joffe，R.，和F.Neves，“DNS解析程序在弹性、健壮性和响应性方面的改进”，正在进行的工作，草稿-Vixie-dnsext-resimprove-00，2010年6月。
[NSEC] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive use of NSEC/NSEC3", Work in Progress, draft-ietf-dnsop-nsec-aggressiveuse-04, September 2016.
[NSEC]Fujiwara，K.，Kato，A.，和W.Kumari，“NSEC/NSEC3的积极使用”，正在进行的工作，草稿-ietf-dnsop-NSEC-AggressiveEUSE-042016年9月。
[joost-dnsterror] Joost, M., "About DNS Attacks and ICMP Destination Unreachable Reports", December 2014, <http://www.michael-joost.de/dnsterror.html>.
[joost Dnsteror]joost，M.，“关于DNS攻击和ICMP目的地不可访问报告”，2014年12月<http://www.michael-joost.de/dnsterror.html>.
[balakrichenan-dafa888] Balakrichenan, S., "Disturbance in the DNS - "Random qnames", the dafa888 DoS attack"", October 2014, <https://indico.dns-oarc.net/event/20/session/3/ contribution/3>.
[balakrichenan-dafa888]balakrichenan，S.，“DNS中的干扰—“随机QName”，dafa888 DoS攻击”，2014年10月<https://indico.dns-oarc.net/event/20/session/3/ 贡献/3>。
Appendix A. Why can't we just use the owner name of the returned SOA?
附录A：为什么我们不能使用返回的SOA的所有者名称？
In this document, we deduce the nonexistence of a domain only for NXDOMAIN answers where the denied name was the exact domain. If a resolver sends a query to the name servers of the TLD example, asking for the mail exchange (MX) record for www.foobar.example, and subsequently receives a NXDOMAIN, it can only register the fact that www.foobar.example (and everything underneath) does not exist. This is true regardless of whether or not the accompanying SOA record is for the domain example only. One cannot infer that foobar.example is nonexistent. The accompanying SOA record indicates the apex of the zone, not the closest existing domain name. So, using the owner name of the SOA record in the authority section to deduce "NXDOMAIN cuts" is currently definitely not OK.
在本文档中，我们仅针对被拒绝的名称为确切域的NXDOMAIN答案推断域不存在。如果冲突解决程序向TLD示例的名称服务器发送查询，请求www.foobar.example的邮件交换（MX）记录，并随后接收NXDOMAIN，则它只能注册www.foobar.example（以及下面的所有内容）不存在的事实。无论附带的SOA记录是否仅用于域示例，这都是正确的。无法推断foobar.example不存在。随附的SOA记录表示区域的顶点，而不是最近的现有域名。因此，在authority部分使用SOA记录的所有者名称来推断“NXDOMAIN cuts”目前肯定是不正确的。
Deducing the nonexistence of a node from the SOA in the NXDOMAIN reply may certainly help with random qnames attacks, but this is out-of-scope for this document. It would require addressing the problems mentioned in the first paragraph of this section. A possible solution is, when receiving a NXDOMAIN with a SOA that is more than one label up in the tree, to send requests for the domains that are between the QNAME and the owner name of the SOA. (A resolver that does DNSSEC validation or QNAME minimization will need to do it anyway.)
在NXDOMAIN回复中从SOA推断节点不存在肯定有助于应对随机qnames攻击，但这超出了本文的范围。这将需要解决本节第一段中提到的问题。一种可能的解决方案是，当接收到一个包含在树中不止一个标签的SOA的NXDOMAIN时，向位于SOA的QNAME和所有者名称之间的域发送请求。（进行DNSSEC验证或QNAME最小化的解析器无论如何都需要这样做。）
The document [NSEC] describes another way to address some of the same concerns (decreasing the traffic for nonexisting domain names). Unlike "NXDOMAIN cut", it requires DNSSEC, but it is more powerful since it can synthesize NXDOMAINs for domains that were not queried.
文件[NSEC]描述了解决一些相同问题的另一种方法（减少不存在的域名的流量）。与“NXDOMAIN cut”不同，它需要DNSSEC，但功能更强大，因为它可以为未查询的域合成NXDOMAINs。
Acknowledgments
致谢
The main idea in this document is taken from [DNSRRR], Section 3, "Stopping Downward Cache Search on NXDOMAIN". Thanks to its authors, Paul Vixie, Rodney Joffe, and Frederico Neves. Additionally, Tony Finch, Ted Lemon, John Levine, Jinmei Tatuya, Bob Harold, and Duane Wessels provided valuable feedback and suggestions.
本文档的主要思想摘自[DNSRRR]，第3节，“停止NXDOMAIN上的向下缓存搜索”。多亏了它的作者保罗·维克西、罗德尼·乔夫和弗雷德里克·内维斯。此外，Tony Finch、Ted Lemon、John Levine、Jinmei Tatuya、Bob Harold和Duane Wessels提供了宝贵的反馈和建议。
Authors' Addresses
作者地址
Stephane Bortzmeyer AFNIC 1, rue Stephenson Montigny-le-Bretonneux 78180 France
Stephane Bortzmeyer AFNIC 1号，Stephenson Montigny le Bretoneux街78180号，法国
Phone: +33 1 39 30 83 46
Email: bortzmeyer+ietf@nic.fr
URI: https://www.afnic.fr/
Phone: +33 1 39 30 83 46
Email: bortzmeyer+ietf@nic.fr
URI: https://www.afnic.fr/
Shumon Huque Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States of America
Shumon Huque Verisign实验室12061美国弗吉尼亚州布鲁蒙特路莱斯顿20190
Email: shuque@verisign.com
URI: http://www.verisignlabs.com/
Email: shuque@verisign.com
URI: http://www.verisignlabs.com/