Network Working Group M. Andrews
Request for Comments: 2308 CSIRO
Updates: 1034, 1035 March 1998
Category: Standards Track
Network Working Group M. Andrews
Request for Comments: 2308 CSIRO
Updates: 1034, 1035 March 1998
Category: Standards Track
Negative Caching of DNS Queries (DNS NCACHE)
DNS查询的反向缓存（DNS NCACHE）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
[RFC1034] provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces [RFC1034 Section 4.3.4].
[RFC1034]提供了如何缓存否定响应的说明。但是，它有一个基本缺陷，即它不允许名称服务器将那些缓存的响应分发给其他解析程序，从而大大降低了缓存的效果。本文件解决了根据经验提出的问题，并取代了[RFC1034第4.3.4节]。
Negative caching was an optional part of the DNS specification and deals with the caching of the non-existence of an RRset [RFC2181] or domain name.
负缓存是DNS规范的可选部分，处理不存在RRset[RFC2181]或域名的缓存。
Negative caching is useful as it reduces the response time for negative answers. It also reduces the number of messages that have to be sent between resolvers and name servers hence overall network traffic. A large proportion of DNS traffic on the Internet could be eliminated if all resolvers implemented negative caching. With this in mind negative caching should no longer be seen as an optional part of a DNS resolver.
负面缓存非常有用，因为它减少了负面答案的响应时间。它还减少了必须在解析程序和名称服务器之间发送的消息数量，从而减少了总体网络流量。如果所有解析程序都实现负缓存，那么Internet上的大部分DNS流量都可以消除。考虑到这一点，负缓存不应再被视为DNS解析程序的可选部分。
1 - Terminology
1-术语
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]中所述进行解释。
"Negative caching" - the storage of knowledge that something does not exist. We can store the knowledge that a record has a particular value. We can also do the reverse, that is, to store the knowledge that a record does not exist. It is the storage of knowledge that something does not exist, cannot or does not give an answer that we call negative caching.
“负面缓存”-存储某些不存在的知识。我们可以存储记录具有特定值的知识。我们也可以做相反的事情，也就是存储记录不存在的知识。它是知识的存储，某些东西不存在，不能或不能给出答案，我们称之为负缓存。
"QNAME" - the name in the query section of an answer, or where this resolves to a CNAME, or CNAME chain, the data field of the last CNAME. The last CNAME in this sense is that which contains a value which does not resolve to another CNAME. Implementations should note that including CNAME records in responses in order, so that the first has the label from the query section, and then each in sequence has the label from the data section of the previous (where more than one CNAME is needed) allows the sequence to be processed in one pass, and considerably eases the task of the receiver. Other relevant records (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs.
“QNAME”-答案查询部分中的名称，或解析为CNAME或CNAME链时，最后一个CNAME的数据字段。从这个意义上讲，最后一个CNAME是包含一个不解析为另一个CNAME的值的CNAME。实现应注意，在响应中按顺序包括CNAME记录，以便第一个具有来自查询部分的标签，然后每个顺序中具有来自前一个（其中需要多个CNAME）的数据部分的标签，从而允许在一次过程中处理序列，并且大大简化了接收者的任务。其他相关记录（如SIG RRs[RFC2065]）可以散布在CNAMEs中。
"NXDOMAIN" - an alternate expression for the "Name Error" RCODE as described in [RFC1035 Section 4.1.1] and the two terms are used interchangeably in this document.
“NXDOMAIN”-如[RFC1035第4.1.1节]所述的“名称错误”RCODE的替代表达式，这两个术语在本文件中互换使用。
"NODATA" - a pseudo RCODE which indicates that the name is valid, for the given class, but are no records of the given type. A NODATA response has to be inferred from the answer.
“NODATA”-一个伪RCODE，表示该名称对给定类有效，但不是给定类型的记录。必须根据答案推断出NODATA响应。
"FORWARDER" - a nameserver used to resolve queries instead of directly using the authoritative nameserver chain. The forwarder typically either has better access to the internet, or maintains a bigger cache which may be shared amongst many resolvers. How a server is identified as a FORWARDER, or knows it is a FORWARDER is outside the scope of this document. However if you are being used as a forwarder the query will have the recursion desired flag set.
“转发器”-用于解析查询的名称服务器，而不是直接使用权威名称服务器链。转发器通常可以更好地访问internet，或者维护一个更大的缓存，该缓存可以在多个解析程序之间共享。如何将服务器标识为转发器或知道它是转发器不在本文档的范围内。但是，如果您被用作转发器，查询将设置递归所需的标志。
An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected when reading this document.
阅读本文件时，应了解[RFC1034]、[RFC1035]和[RFC2065]。
2 - Negative Responses
2-否定回答
The most common negative responses indicate that a particular RRset does not exist in the DNS. The first sections of this document deal with this case. Other negative responses can indicate failures of a nameserver, those are dealt with in section 7 (Other Negative Responses).
最常见的否定响应表明DNS中不存在特定的RRset。本文件的前几节涉及这一案件。其他负面响应可能表示名称服务器出现故障，这些在第7节（其他负面响应）中讨论。
A negative response is indicated by one of the following conditions:
以下情况之一表示否定响应：
Name errors (NXDOMAIN) are indicated by the presence of "Name Error" in the RCODE field. In this case the domain referred to by the QNAME does not exist. Note: the answer section may have SIG and CNAME RRs and the authority section may have SOA, NXT [RFC2065] and SIG RRsets.
名称错误（NXDOMAIN）由RCODE字段中出现的“名称错误”表示。在这种情况下，QNAME引用的域不存在。注：应答部分可能有SIG和CNAME RRs，授权部分可能有SOA、NXT[RFC2065]和SIG RRs集。
It is possible to distinguish between a referral and a NXDOMAIN response by the presense of NXDOMAIN in the RCODE regardless of the presence of NS or SOA records in the authority section.
无论授权部分中是否存在NS或SOA记录，都可以通过在RCODE中显示NXDOMIN来区分引用和NXDOMIN响应。
NXDOMAIN responses can be categorised into four types by the contents of the authority section. These are shown below along with a referral for comparison. Fields not mentioned are not important in terms of the examples.
NXDOMAIN响应可以根据权限部分的内容分为四种类型。下面显示了这些内容以及用于比较的参考资料。就示例而言，未提及的字段并不重要。
NXDOMAIN RESPONSE: TYPE 1.
NXDOMAIN响应：类型1。
Header:
RDCODE=NXDOMAIN
Query:
AN.EXAMPLE. A
Answer:
AN.EXAMPLE. CNAME TRIPPLE.XX.
Authority:
XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
XX. NS NS1.XX.
XX. NS NS2.XX.
Additional:
NS1.XX. A 127.0.0.2
NS2.XX. A 127.0.0.3
Header:
RDCODE=NXDOMAIN
Query:
AN.EXAMPLE. A
Answer:
AN.EXAMPLE. CNAME TRIPPLE.XX.
Authority:
XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
XX. NS NS1.XX.
XX. NS NS2.XX.
Additional:
NS1.XX. A 127.0.0.2
NS2.XX. A 127.0.0.3
NXDOMAIN RESPONSE: TYPE 2.
NXDOMAIN响应：类型2。
Header: RDCODE=NXDOMAIN Query: AN.EXAMPLE. A
Header:RDCODE=NXDOMAIN查询：例如。A.
Answer:
AN.EXAMPLE. CNAME TRIPPLE.XX.
Authority:
XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
Additional:
<empty>
Answer:
AN.EXAMPLE. CNAME TRIPPLE.XX.
Authority:
XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
Additional:
<empty>
NXDOMAIN RESPONSE: TYPE 3.
NXDOMAIN响应：类型3。
Header: RDCODE=NXDOMAIN Query: AN.EXAMPLE. A Answer: AN.EXAMPLE. CNAME TRIPPLE.XX. Authority: <empty> Additional: <empty>
Header:RDCODE=NXDOMAIN查询：例如。答案：举个例子。CNAME TRIPPLE.XX。权限：<empty>附加：<empty>
NXDOMAIN RESPONSE: TYPE 4
NXDOMAIN响应：类型4
Header: RDCODE=NXDOMAIN Query: AN.EXAMPLE. A Answer: AN.EXAMPLE. CNAME TRIPPLE.XX. Authority: XX. NS NS1.XX. XX. NS NS2.XX. Additional: NS1.XX. A 127.0.0.2 NS2.XX. A 127.0.0.3
Header:RDCODE=NXDOMAIN查询：例如。答案：举个例子。CNAME TRIPPLE.XX。主管机关：XX。NS NS1.XX。XX。NS NS2.XX。附加：NS1.XX。A 127.0.0.2 NS2.XX。A 127.0.0.3
REFERRAL RESPONSE.
转介反应。
Header: RDCODE=NOERROR Query: AN.EXAMPLE. A Answer: AN.EXAMPLE. CNAME TRIPPLE.XX. Authority: XX. NS NS1.XX. XX. NS NS2.XX. Additional: NS1.XX. A 127.0.0.2
Header:RDCODE=NOERROR Query:AN.EXAMPLE。答案：举个例子。CNAME TRIPPLE.XX。主管机关：XX。NS NS1.XX。XX。NS NS2.XX。附加：NS1.XX。A 127.0.0.2
NS2.XX. A 127.0.0.3
NS2.XX。A 127.0.0.3
Note, in the four examples of NXDOMAIN responses, it is known that the name "AN.EXAMPLE." exists, and has as its value a CNAME record. The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to exist. On the other hand, in the referral example, it is shown that "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is known one way or the other about the existence of "TRIPPLE.XX", other than that "NS1.XX" or "NS2.XX" can be consulted as the next step in obtaining information about it.
注意，在NXDOMAIN响应的四个示例中，已知名称“AN.EXAMPLE.”存在，并且其值为CNAME记录。NXDOMAIN指的是“TRIPPLE.XX”，已知它不存在。另一方面，在引用示例中，显示了“AN.example”的存在，并且其值为CNAME RR，但是对于“TRIPPLE.XX”的存在，我们以这种或那种方式一无所知，除了作为获取其相关信息的下一步，可以参考“NS1.XX”或“NS2.XX”。
Where no CNAME records appear, the NXDOMAIN response refers to the name in the label of the RR in the question section.
如果没有出现CNAME记录，NXDOMAIN响应将引用问题部分中RR标签中的名称。
This section deals with errors encountered when implementing negative caching of NXDOMAIN responses.
本节介绍在实现NXDOMAIN响应的负缓存时遇到的错误。
There are a large number of resolvers currently in existence that fail to correctly detect and process all forms of NXDOMAIN response. Some resolvers treat a TYPE 1 NXDOMAIN response as a referral. To alleviate this problem it is recommended that servers that are authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN responses, that is the authority section contains a SOA record and no NS records. If a non- authoritative server sends a type 1 NXDOMAIN response to one of these old resolvers, the result will be an unnecessary query to an authoritative server. This is undesirable, but not fatal except when the server is being used a FORWARDER. If however the resolver is using the server as a FORWARDER to such a resolver it will be necessary to disable the sending of TYPE 1 NXDOMAIN response to it, use TYPE 2 NXDOMAIN instead.
目前存在大量解析程序，无法正确检测和处理所有形式的域响应。某些解析程序将类型1域响应视为引用。为了缓解此问题，建议对NXDOMAIN响应具有权威性的服务器只发送类型2 NXDOMAIN响应，即权威部分包含SOA记录而不包含NS记录。如果非权威服务器向这些旧解析程序之一发送类型1 NXDOMAIN响应，则结果将是向权威服务器发送不必要的查询。这是不需要的，但不是致命的，除非服务器被用作转发器。但是，如果冲突解决程序使用服务器作为此类冲突解决程序的转发器，则有必要禁用向其发送类型1 NXDOMAIN响应，请改用类型2 NXDOMAIN。
Some resolvers incorrectly continue processing if the authoritative answer flag is not set, looping until the query retry threshold is exceeded and then returning SERVFAIL. This is a problem when your nameserver is listed as a FORWARDER for such resolvers. If the nameserver is used as a FORWARDER by such resolver, the authority flag will have to be forced on for NXDOMAIN responses to these resolvers. In practice this causes no problems even if turned on always, and has been the default behaviour in BIND from 4.9.3 onwards.
如果未设置权威应答标志，某些解析程序将错误地继续处理，循环直到超过查询重试阈值，然后返回SERVFAIL。当名称服务器被列为此类解析程序的转发器时，这是一个问题。如果名称服务器被此类冲突解决程序用作转发器，则必须为这些冲突解决程序的NXDOMAIN响应强制启用权限标志。实际上，即使始终打开，这也不会导致任何问题，并且从4.9.3开始，这一直是BIND中的默认行为。
NODATA is indicated by an answer with the RCODE set to NOERROR and no relevant answers in the answer section. The authority section will contain an SOA record, or there will be no NS records there.
NODATA由RCODE设置为NOERROR的答案表示，答案部分没有相关答案。authority部分将包含一个SOA记录，或者那里将没有NS记录。
NODATA responses have to be algorithmically determined from the response's contents as there is no RCODE value to indicate NODATA. In some cases to determine with certainty that NODATA is the correct response it can be necessary to send another query.
NODATA响应必须根据响应内容通过算法确定，因为没有RCODE值来指示NODATA。在某些情况下，为了确定NODATA是正确的响应，可能需要发送另一个查询。
The authority section may contain NXT and SIG RRsets in addition to NS and SOA records. CNAME and SIG records may exist in the answer section.
除NS和SOA记录外，授权部分还可能包含NXT和SIG RRSET。应答部分可能存在CNAME和SIG记录。
It is possible to distinguish between a NODATA and a referral response by the presence of a SOA record in the authority section or the absence of NS records in the authority section.
通过在授权部分中存在SOA记录或在授权部分中不存在NS记录，可以区分节点数据和引用响应。
NODATA responses can be categorised into three types by the contents of the authority section. These are shown below along with a referral for comparison. Fields not mentioned are not important in terms of the examples.
根据权限部分的内容，NODATA响应可分为三种类型。下面显示了这些内容以及用于比较的参考资料。就示例而言，未提及的字段并不重要。
NODATA RESPONSE: TYPE 1.
NODATA响应：类型1。
Header:
RDCODE=NOERROR
Query:
ANOTHER.EXAMPLE. A
Answer:
<empty>
Authority:
EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
EXAMPLE. NS NS1.XX.
EXAMPLE. NS NS2.XX.
Additional:
NS1.XX. A 127.0.0.2
NS2.XX. A 127.0.0.3
Header:
RDCODE=NOERROR
Query:
ANOTHER.EXAMPLE. A
Answer:
<empty>
Authority:
EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
EXAMPLE. NS NS1.XX.
EXAMPLE. NS NS2.XX.
Additional:
NS1.XX. A 127.0.0.2
NS2.XX. A 127.0.0.3
NO DATA RESPONSE: TYPE 2.
无数据响应：类型2。
Header:
RDCODE=NOERROR
Query:
ANOTHER.EXAMPLE. A
Answer:
<empty>
Authority:
EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
Additional:
<empty>
Header:
RDCODE=NOERROR
Query:
ANOTHER.EXAMPLE. A
Answer:
<empty>
Authority:
EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
Additional:
<empty>
NO DATA RESPONSE: TYPE 3.
无数据响应：类型3。
Header:
RDCODE=NOERROR
Query:
ANOTHER.EXAMPLE. A
Answer:
<empty>
Authority:
<empty>
Additional:
<empty>
Header:
RDCODE=NOERROR
Query:
ANOTHER.EXAMPLE. A
Answer:
<empty>
Authority:
<empty>
Additional:
<empty>
REFERRAL RESPONSE.
转介反应。
Header: RDCODE=NOERROR Query: ANOTHER.EXAMPLE. A Answer: <empty> Authority: EXAMPLE. NS NS1.XX. EXAMPLE. NS NS2.XX. Additional: NS1.XX. A 127.0.0.2 NS2.XX. A 127.0.0.3
Header:RDCODE=NOERROR查询：另一个示例。答案：<empty>权威：示例。NS NS1.XX。实例NS NS2.XX。附加：NS1.XX。A 127.0.0.2 NS2.XX。A 127.0.0.3
These examples, unlike the NXDOMAIN examples above, have no CNAME records, however they could, in just the same way that the NXDOMAIN examples did, in which case it would be the value of the last CNAME (the QNAME) for which NODATA would be concluded.
与上面的NXDOMAIN示例不同，这些示例没有CNAME记录，但是它们可以，就像NXDOMAIN示例一样，在这种情况下，它将是最后一个CNAME（QNAME）的值，NODATA将由此得出结论。
There are a large number of resolvers currently in existence that fail to correctly detect and process all forms of NODATA response. Some resolvers treat a TYPE 1 NODATA response as a referral. To alleviate this problem it is recommended that servers that are authoritative for the NODATA response only send TYPE 2 NODATA responses, that is the authority section contains a SOA record and no NS records. Sending a TYPE 1 NODATA response from a non-authoritative server to one of these resolvers will only result in an unnecessary query. If a server is listed as a FORWARDER for another resolver it may also be necessary to disable the sending of TYPE 1 NODATA response for non-authoritative NODATA responses.
目前存在大量解析程序，无法正确检测和处理所有形式的NODATA响应。某些解析程序将类型1 NODATA响应视为引用。为了缓解此问题，建议对NODATA响应具有权威性的服务器只发送类型2 NODATA响应，即权威部分包含SOA记录而不包含NS记录。从非权威服务器向其中一个解析程序发送类型1 NODATA响应只会导致不必要的查询。如果某个服务器被列为另一个解析程序的转发器，则可能还需要禁用发送非权威NodeData响应的类型1 NodeData响应。
Some name servers fail to set the RCODE to NXDOMAIN in the presence of CNAMEs in the answer section. If a definitive NXDOMAIN / NODATA answer is required in this case the resolver must query again using the QNAME as the query label.
在应答部分有CNAMEs时，某些名称服务器无法将RCODE设置为NXDOMAIN。如果在这种情况下需要最终的NXDOMAIN/NODATA答案，解析程序必须使用QNAME作为查询标签再次查询。
3 - Negative Answers from Authoritative Servers
3-权威服务器的否定回答
Name servers authoritative for a zone MUST include the SOA record of the zone in the authority section of the response when reporting an NXDOMAIN or indicating that no data of the requested type exists. This is required so that the response may be cached. The TTL of this record is set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself, and indicates how long a resolver may cache the negative answer. The TTL SIG record associated with the SOA record should also be trimmed in line with the SOA's TTL.
当报告NXDOMAIN或指示不存在请求类型的数据时，区域的授权名称服务器必须在响应的授权部分包含该区域的SOA记录。这是必需的，以便可以缓存响应。此记录的TTL是根据SOA记录的最小字段的最小值和SOA本身的TTL设置的，并指示解析程序可以缓存否定答案的时间。与SOA记录关联的TTL SIG记录也应该按照SOA的TTL进行修剪。
If the containing zone is signed [RFC2065] the SOA and appropriate NXT and SIG records MUST be added.
如果包含区域已签名[RFC2065]，则必须添加SOA和相应的NXT和SIG记录。
4 - SOA Minimum Field
4-SOA最小字段
The SOA minimum field has been overloaded in the past to have three different meanings, the minimum TTL value of all RRs in a zone, the default TTL of RRs which did not contain a TTL value and the TTL of negative responses.
SOA最小值字段在过去被重载，具有三种不同的含义：区域中所有RRs的最小TTL值、不包含TTL值的RRs的默认TTL和负面响应的TTL。
Despite being the original defined meaning, the first of these, the minimum TTL value of all RRs in a zone, has never in practice been used and is hereby deprecated.
尽管是最初定义的含义，但其中第一个，即区域内所有RRs的最小TTL值，在实践中从未使用过，因此不推荐使用。
The second, the default TTL of RRs which contain no explicit TTL in the master zone file, is relevant only at the primary server. After a zone transfer all RRs have explicit TTLs and it is impossible to determine whether the TTL for a record was explicitly set or derived from the default after a zone transfer. Where a server does not require RRs to include the TTL value explicitly, it should provide a mechanism, not being the value of the MINIMUM field of the SOA record, from which the missing TTL values are obtained. How this is done is implementation dependent.
第二个是RRs的默认TTL，它在主区域文件中不包含显式TTL，只与主服务器相关。区域传输后，所有RRs都有显式TTL，因此无法确定记录的TTL是显式设置的还是从区域传输后的默认值派生的。如果服务器不要求RRs显式地包含TTL值，那么它应该提供一种机制，而不是SOA记录的最小字段的值，从中可以获得缺少的TTL值。如何做到这一点取决于实现。
The Master File format [RFC 1035 Section 5] is extended to include the following directive:
主文件格式[RFC 1035第5节]扩展为包含以下指令：
$TTL <TTL> [comment]
$TTL<TTL>[评论]
All resource records appearing after the directive, and which do not explicitly include a TTL value, have their TTL set to the TTL given in the $TTL directive. SIG records without a explicit TTL get their TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5].
在指令之后出现的所有资源记录，如果没有明确包含TTL值，则其TTL设置为$TTL指令中给定的TTL。没有显式TTL的SIG记录从SIG记录的“原始TTL”获取其TTL[RFC 2065第4.5节]。
The remaining of the current meanings, of being the TTL to be used for negative responses, is the new defined meaning of the SOA minimum field.
当前的其余含义，即用于负面响应的TTL，是SOA最小值字段的新定义含义。
5 - Caching Negative Answers
5-缓存否定答案
Like normal answers negative answers have a time to live (TTL). As there is no record in the answer section to which this TTL can be applied, the TTL must be carried by another method. This is done by including the SOA record from the zone in the authority section of the reply. When the authoritative server creates this record its TTL is taken from the minimum of the SOA.MINIMUM field and SOA's TTL. This TTL decrements in a similar manner to a normal cached answer and upon reaching zero (0) indicates the cached negative answer MUST NOT be used again.
与正常答案一样，否定答案也有生存时间（TTL）。由于应答部分中没有可应用此TTL的记录，因此必须使用其他方法进行TTL。这是通过在回复的authority部分包含来自区域的SOA记录来实现的。权威服务器创建此记录时，其TTL取自SOA.minimum字段和SOA的TTL中的最小值。此TTL以与正常缓存答案类似的方式递减，当达到零（0）时，表示不能再次使用缓存的否定答案。
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>的查询。
A negative answer that resulted from a no data error (NODATA) should be cached such that it can be retrieved and returned in response to another query for the same <QNAME, QTYPE, QCLASS> that resulted in the cached negative response.
应该缓存由无数据错误（NODATA）导致的否定回答，以便可以检索并返回该否定回答，以响应另一个查询，该查询与导致缓存否定回答的<QNAME，QTYPE，QCLASS>相同。
The NXT record, if it exists in the authority section of a negative answer received, MUST be stored such that it can be be located and returned with SOA record in the authority section, as should any SIG records in the authority section. For NXDOMAIN answers there is no "necessary" obvious relationship between the NXT records and the QNAME. The NXT record MUST have the same owner name as the query name for NODATA responses.
如果NXT记录存在于收到的否定回答的授权部分中，则必须存储该记录，以便能够在授权部分中找到该记录并与SOA记录一起返回，就像在授权部分中的任何SIG记录一样。对于NXTomain答案，NXT记录和QNAME之间没有“必要的”明显关系。NXT记录的所有者名称必须与NODATA响应的查询名称相同。
Negative responses without SOA records SHOULD NOT be cached as there is no way to prevent the negative responses looping forever between a pair of servers even with a short TTL.
不应缓存没有SOA记录的负面响应，因为即使使用较短的TTL，也无法防止负面响应在一对服务器之间永远循环。
Despite the DNS forming a tree of servers, with various mis-configurations it is possible to form a loop in the query graph, e.g. two servers listing each other as forwarders, various lame server configurations. Without a TTL count down a cache negative response
尽管DNS形成了一个服务器树，但通过各种mis配置，仍有可能在查询图中形成一个循环，例如，两台服务器彼此列为转发器，各种lame服务器配置。没有TTL倒计时，缓存响应为负
when received by the next server would have its TTL reset. This negative indication could then live forever circulating between the servers involved.
当下一个服务器收到时，将重置其TTL。这种负面指示可能会在相关服务器之间永远存在。
As with caching positive responses it is sensible for a resolver to limit for how long it will cache a negative response as the protocol supports caching for up to 68 years. Such a limit should not be greater than that applied to positive answers and preferably be tunable. Values of one to three hours have been found to work well and would make sensible a default. Values exceeding one day have been found to be problematic.
与缓存积极响应一样，解析程序应该限制缓存消极响应的时间，因为协议支持缓存长达68年。这种限制不应大于适用于肯定答案的限制，最好是可调的。一到三个小时的值被发现效果很好，可以作为一个合理的默认值。发现超过一天的值有问题。
6 - Negative answers from the cache
6-缓存中的否定答案
When a server, in answering a query, encounters a cached negative response it MUST add the cached SOA record to the authority section of the response with the TTL decremented by the amount of time it was stored in the cache. This allows the NXDOMAIN / NODATA response to time out correctly.
当服务器在回答查询时遇到缓存的否定响应时，它必须将缓存的SOA记录添加到响应的authority部分，TTL按存储在缓存中的时间量递减。这允许NXDOMAIN/NODATA响应正确超时。
If a NXT record was cached along with SOA record it MUST be added to the authority section. If a SIG record was cached along with a NXT record it SHOULD be added to the authority section.
如果NXT记录与SOA记录一起缓存，则必须将其添加到授权部分。如果SIG记录与NXT记录一起缓存，则应将其添加到授权部分。
As with all answers coming from the cache, negative answers SHOULD have an implicit referral built into the answer. This enables the resolver to locate an authoritative source. An implicit referral is characterised by NS records in the authority section referring the resolver towards a authoritative source. NXDOMAIN types 1 and 4 responses contain implicit referrals as does NODATA type 1 response.
与所有来自缓存的答案一样，否定答案应该在答案中内置一个隐式引用。这使解析器能够定位权威源。隐式转介的特点是授权部分中的NS记录将解析程序转介到权威来源。NXDOMAIN类型1和4响应与NODATA类型1响应一样包含隐式引用。
7 - Other Negative Responses
7-其他负面回应
Caching of other negative responses is not covered by any existing RFC. There is no way to indicate a desired TTL in these responses. Care needs to be taken to ensure that there are not forwarding loops.
任何现有RFC都不包括其他负面响应的缓存。在这些响应中无法指示所需的TTL。需要注意确保没有转发循环。
Server failures fall into two major classes. The first is where a server can determine that it has been misconfigured for a zone. This may be where it has been listed as a server, but not configured to be a server for the zone, or where it has been configured to be a server for the zone, but cannot obtain the zone data for some reason. This can occur either because the zone file does not exist or contains errors, or because another server from which the zone should have been available either did not respond or was unable or unwilling to supply the zone.
服务器故障分为两大类。第一种情况是，服务器可以确定它已被错误配置为区域。这可能是因为它已被列为服务器，但未配置为区域的服务器，或者它已配置为区域的服务器，但由于某种原因无法获取区域数据。发生这种情况的原因可能是区域文件不存在或包含错误，或者是因为本应提供该区域的另一台服务器没有响应或无法或不愿意提供该区域。
The second class is where the server needs to obtain an answer from elsewhere, but is unable to do so, due to network failures, other servers that don't reply, or return server failure errors, or similar.
第二类是服务器需要从其他地方获取答案，但由于网络故障、其他服务器不响应或返回服务器故障错误或类似原因而无法获取答案。
In either case a resolver MAY cache a server failure response. If it does so it MUST NOT cache it for longer than five (5) minutes, and it MUST be cached against the specific query tuple <query name, type, class, server IP address>.
在任何一种情况下，解析程序都可能缓存服务器故障响应。如果这样做，则缓存时间不得超过五（5）分钟，并且必须针对特定的查询元组<query name，type，class，server IP address>进行缓存。
Dead / Unreachable servers are servers that fail to respond in any way to a query or where the transport layer has provided an indication that the server does not exist or is unreachable. A server may be deemed to be dead or unreachable if it has not responded to an outstanding query within 120 seconds.
死/不可访问服务器是指无法以任何方式响应查询的服务器，或者传输层提供了服务器不存在或不可访问的指示的服务器。如果服务器在120秒内未响应未完成的查询，则该服务器可能被视为已死亡或无法访问。
Examples of transport layer indications are:
传输层指示的示例包括：
ICMP error messages indicating host, net or port unreachable. TCP resets IP stack error messages providing similar indications to those above.
指示无法访问主机、网络或端口的ICMP错误消息。TCP重置IP堆栈错误消息，提供与上述类似的指示。
A server MAY cache a dead server indication. If it does so it MUST NOT be deemed dead for longer than five (5) minutes. The indication MUST be stored against query tuple <query name, type, class, server IP address> unless there was a transport layer indication that the server does not exist, in which case it applies to all queries to that specific IP address.
服务器可以缓存失效服务器指示。如果发生这种情况，则不得将其视为死亡超过五（5）分钟。必须根据查询元组<query name，type，class，server IP address>存储该指示，除非传输层指示服务器不存在，在这种情况下，该指示适用于该特定IP地址的所有查询。
8 - Changes from RFC 1034
8-RFC 1034的变更
Negative caching in resolvers is no-longer optional, if a resolver caches anything it must also cache negative answers.
解析程序中的负缓存不再是可选的，如果解析程序缓存任何内容，它还必须缓存负答案。
Non-authoritative negative answers MAY be cached.
非权威的否定答案可能会被缓存。
The SOA record from the authority section MUST be cached. Name error indications must be cached against the tuple <query name, QCLASS>. No data indications must be cached against <query name, QTYPE, QCLASS> tuple.
必须缓存来自授权部分的SOA记录。必须针对元组<query Name，QCLASS>缓存名称错误指示。必须针对<query name，QTYPE，QCLASS>元组缓存任何数据指示。
A cached SOA record must be added to the response. This was explicitly not allowed because previously the distinction between a normal cached SOA record, and the SOA cached as a result of a negative response was not made, and simply extracting a normal cached SOA and adding that to a cached negative response causes problems.
必须将缓存的SOA记录添加到响应中。这是明确不允许的，因为以前没有区分正常缓存的SOA记录和由于负面响应而缓存的SOA，而简单地提取正常缓存的SOA并将其添加到缓存的负面响应会导致问题。
The $TTL TTL directive was added to the master file format.
$TTL TTL指令已添加到主文件格式。
9 - History of Negative Caching
9-负缓存的历史记录
This section presents a potted history of negative caching in the DNS and forms no part of the technical specification of negative caching.
本节介绍DNS中负缓存的封装历史，不构成负缓存技术规范的一部分。
It is interesting to note that the same concepts were re-invented in both the CHIVES and BIND servers.
有趣的是，在CHIVES和BIND服务器中都重新发明了相同的概念。
The history of the early CHIVES work (Section 9.1) was supplied by Rob Austein <sra@epilogue.com> and is reproduced here in the form in which he supplied it [MPA].
早期韭菜作品的历史（第9.1节）由Rob Austein提供<sra@epilogue.com>并在这里以他提供的形式复制[MPA]。
Sometime around the spring of 1985, I mentioned to Paul Mockapetris that our experience with his JEEVES DNS resolver had pointed out the need for some kind of negative caching scheme. Paul suggested that we simply cache authoritative errors, using the SOA MINIMUM value for the zone that would have contained the target RRs. I'm pretty sure that this conversation took place before RFC-973 was written, but it was never clear to me whether this idea was something that Paul came up with on the spot in response to my question or something he'd already been planning to put into the document that became RFC-973. In any case, neither of us was entirely sure that the SOA MINIMUM value was really the right metric to use, but it was available and was under the control of the administrator of the target zone, both of which seemed to us at the time to be important feature.
大约在1985年春天的某个时候，我向Paul Mockapetris提到，我们使用他的JEEVES DNS解析器的经验表明需要某种负面缓存方案。Paul建议我们只缓存权威错误，使用包含目标RRs的区域的SOA最小值。我很确定这段对话发生在RFC-973编写之前，但我始终不清楚这个想法是保罗在现场回答我的问题时提出的，还是他已经计划在成为RFC-973的文件中提出的。在任何情况下，我们都不完全确定SOA最小值是否真的是正确的度量标准，但它是可用的，并且在目标区域的管理员的控制下，这两个在当时对我们来说都是重要的特性。
Late in 1987, I released the initial beta-test version of CHIVES, the DNS resolver I'd written to replace Paul's JEEVES resolver. CHIVES included a search path mechanism that was used pretty heavily at several sites (including my own), so CHIVES also included a negative caching mechanism based on SOA MINIMUM values. The basic strategy was to cache authoritative error codes keyed by the exact query parameters (QNAME, QCLASS, and QTYPE), with a cache TTL equal to the SOA MINIMUM value. CHIVES did not attempt to track down SOA RRs if they weren't supplied in the authoritative response, so it never managed to completely eliminate the gratuitous DNS error message traffic, but it did help considerably. Keep in mind that this was happening at about the same time as the near-collapse of the ARPANET due to congestion caused by exponential growth and the the "old" (pre-VJ) TCP retransmission algorithm, so negative caching resulted in drasticly better DNS response time for our users, mailer daemons, etcetera.
1987年末，我发布了CHIVES的最初beta测试版本，这是我为取代Paul的JEEVES解析器而编写的DNS解析器。CHIVES包括一个搜索路径机制，在几个站点（包括我自己的站点）中使用得相当频繁，因此CHIVES还包括一个基于SOA最小值的负缓存机制。基本策略是缓存由精确查询参数（QNAME、QCLASS和QTYPE）键入的权威错误代码，缓存TTL等于SOA最小值。如果权威响应中没有提供SOA RRs，CHIVES不会尝试跟踪这些RRs，因此它从未设法完全消除免费的DNS错误消息流量，但它确实提供了相当大的帮助。请记住，这与ARPANET因指数增长和“旧”（VJ之前）TCP重传算法造成的拥塞而几乎崩溃的同时发生，因此负缓存为我们的用户mailer daemons等带来了更好的DNS响应时间。
As far as I know, CHIVES was the first resolver to implement negative caching. CHIVES was developed during the twilight years of TOPS-20, so it never ran on very many machines, but the few machines that it did run on were the ones that were too critical to shut down quickly no matter how much it cost to keep them running. So what few users we did have tended to drive CHIVES pretty hard. Several interesting bits of DNS technology resulted from that, but the one that's relevant here is the MAXTTL configuration parameter.
据我所知，CHIVES是第一个实现负缓存的解析器。韭菜是在TOP-20的暮年开发的，所以它从来没有在很多机器上运行过，但它所运行的少数机器是那些太关键的机器，无论维持它们运行需要多少成本，都无法快速关闭。因此，我们所做的很少有用户倾向于把韭菜弄得很厉害。DNS技术的几个有趣的方面就是由此产生的，但这里相关的是MAXTTL配置参数。
Experience with JEEVES had already shown that RRs often showed up with ridiculously long TTLs (99999999 was particularly popular for many years, due to bugs in the code and documentation of several early versions of BIND), and that robust software that blindly believed such TTLs could create so many strange failures that it was often necessary to reboot the resolver frequently just to clear this garbage out of the cache. So CHIVES had a configuration parameter "MAXTTL", which specified the maximum "reasonable" TTL in a received RR. RRs with TTLs greater than MAXTTL would either have their TTLs reduced to MAXTTL or would be discarded entirely, depending on the setting of another configuration parameter.
使用JEEVES的经验已经表明，RRs通常会出现长得离谱的TTL（由于BIND的几个早期版本的代码和文档中存在bug，9999999多年来特别流行），而那些盲目相信这种TTL会造成如此多奇怪故障的健壮软件，常常需要频繁地重新启动解析器，以便从缓存中清除这些垃圾。因此CHIVES有一个配置参数“MAXTTL”，它指定了接收到的RR中的最大“合理”TTL。TTL大于MAXTTL的RRs的TTL将减少为MAXTTL，或者将完全丢弃，具体取决于另一个配置参数的设置。
When we started getting field experience with CHIVES's negative caching code, it became clear that the SOA MINIMUM value was often large enough to cause the same kinds of problems for negative caching as the huge TTLs in RRs had for normal caching (again, this was in part due to a bug in several early versions of BIND, where a secondary server would authoritatively deny all knowledge of its zones if it couldn't contact the primaries on reboot). So we started running the negative cache TTLs through the MAXTTL check too, and continued to experiment.
当我们开始使用CHIVES的负缓存代码获得现场经验时，很明显，SOA最小值通常大到足以导致负缓存出现与RRs中的巨大TTL在正常缓存中相同的问题（同样，这在一定程度上是由于BIND的几个早期版本中存在一个bug，如果在重新启动时无法联系主要服务器，辅助服务器将权威性地拒绝其区域的所有知识）。因此，我们也开始通过MAXTTL检查运行负缓存TTL，并继续进行实验。
The configuration that seemed to work best on WSMR-SIMTEL20.ARMY.MIL (last of the major Internet TOPS-20 machines to be shut down, thus the last major user of CHIVES, thus the place where we had the longest experimental baseline) was to set MAXTTL to about three days. Most of the traffic initiated by SIMTEL20 in its last years was mail-related, and the mail queue timeout was set to one week, so this gave a "stuck" message several tries at complete DNS resolution, without bogging down the system with a lot of useless queries. Since (for reasons that now escape me) we only had the single MAXTTL parameter rather than separate ones for positive and negative caching, it's not clear how much effect this setting of MAXTTL had on the negative caching code.
在WSMR-SIMTEL20.ARMY.MIL（最后一台主要的互联网TOP-20机器被关闭，因此是最后一个主要的韭菜用户，因此是我们拥有最长实验基线的地方）上似乎最有效的配置是将MAXTTL设置为大约三天。SIMTEL20在其最后几年中发起的大多数通信量都与邮件相关，邮件队列超时设置为一周，因此这会在完成DNS解析时多次尝试“卡住”消息，而不会让系统陷入大量无用查询的困境。由于（出于我现在无法理解的原因）我们只有一个MAXTTL参数，而没有单独的参数用于正缓存和负缓存，所以不清楚MAXTTL的设置对负缓存代码有多大影响。
CHIVES also included a second, somewhat controversial mechanism which took the place of negative caching in some cases. The CHIVES resolver daemon could be configured to load DNS master files, giving it the ability to act as what today would be called a "stealth
CHIVES还包括第二个有点争议的机制，在某些情况下它取代了负缓存。CHIVES resolver守护进程可以配置为加载DNS主文件，使其能够充当今天所谓的“隐身”
secondary". That is, when configured in this way, the resolver had direct access to authoritative information for heavily-used zones. The search path mechanisms in CHIVES reflected this: there were actually two separate search paths, one of which only searched local authoritative zone data, and one which could generate normal iterative queries. This cut down on the need for negative caching in cases where usage was predictably heavy (e.g., the resolver on XX.LCS.MIT.EDU always loaded the zone files for both LCS.MIT.EDU and AI.MIT.EDU and put both of these suffixes into the "local" search path, since between them the hosts in these two zones accounted for the bulk of the DNS traffic). Not all sites running CHIVES chose to use this feature; C.CS.CMU.EDU, for example, chose to use the "remote" search path for everything because there were too many different sub-zones at CMU for zone shadowing to be practical for them, so they relied pretty heavily on negative caching even for local traffic.
次要的“。也就是说，当以这种方式配置时，解析程序可以直接访问大量使用的区域的权威信息。CHIVES中的搜索路径机制反映了这一点：实际上有两条独立的搜索路径，一条只搜索本地权威区域数据，另一条可以生成正常的迭代查询。这减少了在使用量预计会很高的情况下对负缓存的需求（例如，XX.LCS.MIT.EDU上的解析器始终加载LCS.MIT.EDU和AI.MIT.EDU的区域文件，并将这两个后缀都放在“本地”搜索路径中，因为这两个区域中的主机占了DNS流量的大部分）。并非所有运行CHIVES的站点都选择使用此功能；例如，C.CS.CMU.EDU选择对所有内容使用“远程”搜索路径，因为CMU上有太多不同的子区域用于区域阴影，因此它们非常依赖负缓存，即使是本地流量。
Overall, I still think the basic design we used for negative caching was pretty reasonable: the zone administrator specified how long to cache negative answers, and the resolver configuration chose the actual cache time from the range between zero and the period specified by the zone administrator. There are a lot of details I'd do differently now (like using a new SOA field instead of overloading the MINIMUM field), but after more than a decade, I'd be more worried if we couldn't think of at least a few improvements.
总的来说，我仍然认为我们用于负面缓存的基本设计是相当合理的：区域管理员指定了负面答案的缓存时间，而解析器配置选择了介于零和区域管理员指定的时间段之间的实际缓存时间。现在有很多细节我会做不同的事情（比如使用一个新的SOA字段而不是重载最小字段），但十多年后，如果我们想不出至少一些改进，我会更担心。
While not the first attempt to get negative caching into BIND, in July 1993, BIND 4.9.2 ALPHA, Anant Kumar of ISI supplied code that implemented, validation and negative caching (NCACHE). This code had a 10 minute TTL for negative caching and only cached the indication that there was a negative response, NXDOMAIN or NOERROR_NODATA. This is the origin of the NODATA pseudo response code mentioned above.
虽然不是第一次尝试将负缓存引入BIND，但在1993年7月，BIND 4.9.2 ALPHA，ISI的Anant Kumar提供了实现、验证和负缓存（NCACHE）的代码。这段代码有一个10分钟的TTL用于负缓存，并且只缓存有负响应的指示，NXDOMAIN或NOERROR_NODATA。这就是上面提到的NODATA伪响应代码的来源。
Mark Andrews of CSIRO added code (RETURNSOA) that stored the SOA record such that it could be retrieved by a similar query. UUnet complained that they were getting old answers after loading a new zone, and the option was turned off, BIND 4.9.3-alpha5, April 1994. In reality this indicated that the named needed to purge the space the zone would occupy. Functionality to do this was added in BIND 4.9.3 BETA11 patch2, December 1994.
CSIRO的MarkAndrews添加了存储SOA记录的代码（RETURNSOA），以便可以通过类似的查询检索该记录。UUnet抱怨他们在加载新区域后得到了旧答案，选项被关闭，BIND 4.9.3-alpha5，1994年4月。实际上，这表明命名者需要清除分区将占用的空间。1994年12月，BIND 4.9.3 BETA11 patch2中添加了此功能。
RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996.
RETURNSOA在默认情况下被重新启用，BIND 4.9.5-T1A，1996年8月。
10 Example
10例
The following example is based on a signed zone that is empty apart from the nameservers. We will query for WWW.XX.EXAMPLE showing initial response and again 10 minutes later. Note 1: during the intervening 10 minutes the NS records for XX.EXAMPLE have expired. Note 2: the TTL of the SIG records are not explicitly set in the zone file and are hence the TTL of the RRset they are the signature for.
下面的示例基于除名称服务器之外为空的签名区域。我们将查询WWW.XX.EXAMPLE，显示初始响应，10分钟后再次查询。注1：在此期间的10分钟内，XX.EXAMPLE的NS记录已过期。注2：SIG记录的TTL没有在区域文件中明确设置，因此是它们作为签名的RRset的TTL。
Zone File:
区域文件：
$TTL 86400
$ORIGIN XX.EXAMPLE.
@ IN SOA NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. (
1997102000 ; serial
1800 ; refresh (30 mins)
900 ; retry (15 mins)
604800 ; expire (7 days)
1200 ) ; minimum (20 mins)
IN SIG SOA ...
1200 IN NXT NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY
IN SIG NXT ... XX.EXAMPLE. ...
300 IN NS NS1.XX.EXAMPLE.
300 IN NS NS2.XX.EXAMPLE.
IN SIG NS ... XX.EXAMPLE. ...
IN KEY 0x4100 1 1 ...
IN SIG KEY ... XX.EXAMPLE. ...
IN SIG KEY ... EXAMPLE. ...
NS1 IN A 10.0.0.1
IN SIG A ... XX.EXAMPLE. ...
1200 IN NXT NS2.XX.EXAMPLE. A NXT SIG
IN SIG NXT ...
NS2 IN A 10.0.0.2
IN SIG A ... XX.EXAMPLE. ...
1200 IN NXT XX.EXAMPLE. A NXT SIG
IN SIG NXT ... XX.EXAMPLE. ...
$TTL 86400
$ORIGIN XX.EXAMPLE.
@ IN SOA NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. (
1997102000 ; serial
1800 ; refresh (30 mins)
900 ; retry (15 mins)
604800 ; expire (7 days)
1200 ) ; minimum (20 mins)
IN SIG SOA ...
1200 IN NXT NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY
IN SIG NXT ... XX.EXAMPLE. ...
300 IN NS NS1.XX.EXAMPLE.
300 IN NS NS2.XX.EXAMPLE.
IN SIG NS ... XX.EXAMPLE. ...
IN KEY 0x4100 1 1 ...
IN SIG KEY ... XX.EXAMPLE. ...
IN SIG KEY ... EXAMPLE. ...
NS1 IN A 10.0.0.1
IN SIG A ... XX.EXAMPLE. ...
1200 IN NXT NS2.XX.EXAMPLE. A NXT SIG
IN SIG NXT ...
NS2 IN A 10.0.0.2
IN SIG A ... XX.EXAMPLE. ...
1200 IN NXT XX.EXAMPLE. A NXT SIG
IN SIG NXT ... XX.EXAMPLE. ...
Initial Response:
初步答复：
Header: RDCODE=NXDOMAIN, AA=1, QR=1, TC=0 Query: WWW.XX.EXAMPLE. IN A Answer: <empty> Authority: XX.EXAMPLE. 1200 IN SOA NS1.XX.EXAMPLE. ... XX.EXAMPLE. 1200 IN SIG SOA ... XX.EXAMPLE. ...
标题：RDCODE=NXDOMAIN，AA=1，QR=1，TC=0查询：WWW.XX.EXAMPLE。在回答中：<empty>权限：XX.EXAMPLE。SOA NS1.XX.EXAMPLE中的1200。。。二十、 例如。1200英寸的SIG SOA。。。二十、 例如。。。
NS2.XX.EXAMPLE. 1200 IN NXT XX.EXAMPLE. NXT A NXT SIG NS2.XX.EXAMPLE. 1200 IN SIG NXT ... XX.EXAMPLE. ... XX.EXAMPLE. 86400 IN NS NS1.XX.EXAMPLE. XX.EXAMPLE. 86400 IN NS NS2.XX.EXAMPLE. XX.EXAMPLE. 86400 IN SIG NS ... XX.EXAMPLE. ... Additional XX.EXAMPLE. 86400 IN KEY 0x4100 1 1 ... XX.EXAMPLE. 86400 IN SIG KEY ... EXAMPLE. ... NS1.XX.EXAMPLE. 86400 IN A 10.0.0.1 NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ... NS2.XX.EXAMPLE. 86400 IN A 10.0.0.2 NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
NS2.XX.示例。NXT XX.EXAMPLE中的1200。NXT A NXT SIG NS2.XX.EXAMPLE。1200英寸SIG NXT。。。二十、 例如。。。二十、 例如。NS NS1.XX.EXAMPLE中的86400。二十、 例如。NS NS2.XX.EXAMPLE中的86400。二十、 例如。86400英寸SIG NS。。。二十、 例如。。。附加XX.1示例。键0x4100 1中的86400。。。二十、 例如。86400在SIG键中。。。实例NS1.XX.示例。在10.0.0.1 NS1.XX.EXAMPLE中使用86400。信号A中的86400。。。二十、 例如。。。NS2.XX.示例。在10.0.0.2 NS3.XX.EXAMPLE中使用86400。信号A中的86400。。。二十、 例如。。。
After 10 Minutes:
10分钟后：
Header: RDCODE=NXDOMAIN, AA=0, QR=1, TC=0 Query: WWW.XX.EXAMPLE. IN A Answer: <empty> Authority: XX.EXAMPLE. 600 IN SOA NS1.XX.EXAMPLE. ... XX.EXAMPLE. 600 IN SIG SOA ... XX.EXAMPLE. ... NS2.XX.EXAMPLE. 600 IN NXT XX.EXAMPLE. NXT A NXT SIG NS2.XX.EXAMPLE. 600 IN SIG NXT ... XX.EXAMPLE. ... EXAMPLE. 65799 IN NS NS1.YY.EXAMPLE. EXAMPLE. 65799 IN NS NS2.YY.EXAMPLE. EXAMPLE. 65799 IN SIG NS ... XX.EXAMPLE. ... Additional XX.EXAMPLE. 65800 IN KEY 0x4100 1 1 ... XX.EXAMPLE. 65800 IN SIG KEY ... EXAMPLE. ... NS1.YY.EXAMPLE. 65799 IN A 10.100.0.1 NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ... NS2.YY.EXAMPLE. 65799 IN A 10.100.0.2 NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ... EXAMPLE. 65799 IN KEY 0x4100 1 1 ... EXAMPLE. 65799 IN SIG KEY ... . ...
标题：RDCODE=NXDOMAIN，AA=0，QR=1，TC=0查询：WWW.XX.EXAMPLE。在回答中：<empty>权限：XX.EXAMPLE。SOA NS1.XX.EXAMPLE中的600。。。二十、 例如。SIG SOA中的600。。。二十、 例如。。。NS2.XX.示例。NXT XX.EXAMPLE中的600。NXT A NXT SIG NS2.XX.EXAMPLE。600英寸SIG NXT。。。二十、 例如。。。实例NS NS1.YY.EXAMPLE中的65799。实例NS NS2.YY.EXAMPLE中的65799。实例65799英寸SIG NS。。。二十、 例如。。。附加XX.1示例。键0x4100 1中的65800。。。二十、 例如。65800英寸信号键。。。实例NS1.YY.EXAMPLE。65799在10.100.0.1 NS1.YY.EXAMPLE中。信号A中的65799。。。实例NS2.YY.EXAMPLE。65799在10.100.0.2 NS3.YY.EXAMPLE中。信号A中的65799。。。实例实例键0x4100 1中的65799。。。实例SIG键中的65799。。。
11 Security Considerations
11安全考虑
It is believed that this document does not introduce any significant additional security threats other that those that already exist when using data from the DNS.
我们相信，本文档不会引入任何重大的额外安全威胁，除了在使用来自DNS的数据时已经存在的安全威胁。
With negative caching it might be possible to propagate a denial of service attack by spreading a NXDOMAIN message with a very high TTL. Without negative caching that would be much harder. A similar effect could be achieved previously by spreading a bad A record, so that the server could not be reached - which is almost the same. It has the same effect as far as what the end user is able to do, but with a different psychological effect. With the bad A, I feel "damn the network is broken again" and try again tomorrow. With the "NXDOMAIN" I feel "Oh, they've turned off the server and it doesn't exist any more" and probably never bother trying this server again.
使用负缓存时，可能会通过传播具有非常高TTL的NXDOMAIN消息来传播拒绝服务攻击。如果没有负缓存，这将更加困难。以前也可以通过传播坏的A记录来实现类似的效果，这样就无法访问服务器——这几乎是一样的。就最终用户的能力而言，它具有相同的效果，但具有不同的心理效果。有了坏A，我觉得“该死的网络又坏了”，明天再试一次。有了“NXDOMAIN”，我觉得“哦，他们已经关闭了服务器，而且它已经不存在了”，而且可能再也不会尝试这个服务器了。
A practical example of this is a SMTP server where this behaviour is encoded. With a NXDOMAIN attack the mail message would bounce immediately, where as with a bad A attack the mail would be queued and could potentially get through after the attack was suspended.
这方面的一个实际示例是SMTP服务器，其中对这种行为进行了编码。对于NXDOMAIN攻击，邮件消息将立即反弹，而对于坏的a攻击，邮件将排队，并可能在攻击暂停后通过。
For such an attack to be successful, the NXDOMAIN indiction must be injected into a parent server (or a busy caching resolver). One way this might be done by the use of a CNAME which results in the parent server querying an attackers server. Resolvers that wish to prevent such attacks can query again the final QNAME ignoring any NS data in the query responses it has received for this query.
要使此类攻击成功，必须将NXDOMAIN指示注入父服务器（或忙缓存解析程序）。一种方法是使用CNAME，导致父服务器查询攻击者服务器。希望防止此类攻击的解析程序可以再次查询最终QNAME，忽略它为此查询收到的查询响应中的任何NS数据。
Implementing TTL sanity checking will reduce the effectiveness of such an attack, because a successful attack would require re-injection of the bogus data at more frequent intervals.
实施TTL健全性检查将降低此类攻击的有效性，因为成功的攻击需要以更频繁的间隔重新注入虚假数据。
DNS Security [RFC2065] provides a mechanism to verify whether a negative response is valid or not, through the use of NXT and SIG records. This document supports the use of that mechanism by promoting the transmission of the relevant security records even in a non security aware server.
DNS安全[RFC2065]提供了一种机制，通过使用NXT和SIG记录来验证否定响应是否有效。本文档通过促进相关安全记录的传输（即使在无安全意识的服务器中）来支持该机制的使用。
Acknowledgments
致谢
I would like to thank Rob Austein for his history of the CHIVES nameserver. The DNSIND working group, in particular Robert Elz for his valuable technical and editorial contributions to this document.
我要感谢Rob Austein对CHIVES命名服务器的历史。DNSIND工作组，特别是Robert Elz对本文件的宝贵技术和编辑贡献。
References
工具书类
[RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES," STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION," STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security Extensions," RFC 2065, January 1997.
[RFC2065]Eastlake，D.和C.Kaufman，“域名系统安全扩展”，RFC2065，1997年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2181] Elz, R., and R. Bush, "Clarifications to the DNS Specification," RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
Author's Address
作者地址
Mark Andrews CSIRO - Mathematical and Information Sciences Locked Bag 17 North Ryde NSW 2113 AUSTRALIA
Mark Andrews CSIRO-数学和信息科学锁袋17澳大利亚新南威尔士州北莱德2113
Phone: +61 2 9325 3148
EMail: Mark.Andrews@cmis.csiro.au
Phone: +61 2 9325 3148
EMail: Mark.Andrews@cmis.csiro.au
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。