Internet Engineering Task Force (IETF) J. Abley
Request for Comments: 8482 Afilias
Updates: 1034, 1035 O. Gudmundsson
Category: Standards Track M. Majkowski
ISSN: 2070-1721 Cloudflare Inc.
E. Hunt
ISC
January 2019
Internet Engineering Task Force (IETF) J. Abley
Request for Comments: 8482 Afilias
Updates: 1034, 1035 O. Gudmundsson
Category: Standards Track M. Majkowski
ISSN: 2070-1721 Cloudflare Inc.
E. Hunt
ISC
January 2019
Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
为QTYPE=ANY的DNS查询提供最小大小的响应
Abstract
摘要
The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.
域名系统（DNS）指定查询类型（QTYPE）“任意”。权威DNS服务器的操作员可能出于本地策略、安全性、性能或其他原因选择不响应此类查询。
The DNS specification does not include specific guidance for the behavior of DNS servers or clients in this situation. This document aims to provide such guidance.
DNS规范不包括这种情况下DNS服务器或客户端行为的具体指导。本文件旨在提供此类指导。
This document updates RFCs 1034 and 1035.
本文件更新了RFCs 1034和1035。
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 https://www.rfc-editor.org/info/rfc8482.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8482.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Motivations for Use of ANY Queries ..............................3
3. General Approach ................................................4
4. Behavior of DNS Responders ......................................5
4.1. Answer with a Subset of Available RRsets ...................5
4.2. Answer with a Synthesized HINFO RRset ......................5
4.3. Answer with Best Guess as to Intention .....................6
4.4. Transport Considerations ...................................6
5. Behavior of DNS Initiators ......................................7
6. HINFO Considerations ............................................7
7. Updates to RFCs 1034 and 1035 ...................................7
8. Implementation Experience .......................................8
9. Security Considerations .........................................8
10. IANA Considerations ............................................9
11. References .....................................................9
11.1. Normative References ......................................9
11.2. Informative References ....................................9
Acknowledgements ..................................................10
Authors' Addresses ................................................10
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Motivations for Use of ANY Queries ..............................3
3. General Approach ................................................4
4. Behavior of DNS Responders ......................................5
4.1. Answer with a Subset of Available RRsets ...................5
4.2. Answer with a Synthesized HINFO RRset ......................5
4.3. Answer with Best Guess as to Intention .....................6
4.4. Transport Considerations ...................................6
5. Behavior of DNS Initiators ......................................7
6. HINFO Considerations ............................................7
7. Updates to RFCs 1034 and 1035 ...................................7
8. Implementation Experience .......................................8
9. Security Considerations .........................................8
10. IANA Considerations ............................................9
11. References .....................................................9
11.1. Normative References ......................................9
11.2. Informative References ....................................9
Acknowledgements ..................................................10
Authors' Addresses ................................................10
The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.
域名系统（DNS）指定查询类型（QTYPE）“任意”。权威DNS服务器的操作员可能出于本地策略、安全性、性能或其他原因选择不响应此类查询。
The DNS specification [RFC1034] [RFC1035] does not include specific guidance for the behavior of DNS servers or clients in this situation. This document aims to provide such guidance.
DNS规范[RFC1034][RFC1035]不包括这种情况下DNS服务器或客户端行为的具体指导。本文件旨在提供此类指导。
This document uses terminology specific to the Domain Name System (DNS), descriptions of which can be found in [RFC8499].
本文档使用域名系统（DNS）特有的术语，其描述可在[RFC8499]中找到。
[RFC1035] defined type 255 to be "*". However, DNS implementations commonly use the keyword "ANY" to refer to that type code; this document follows that common usage.
[RFC1035]将类型255定义为“*”。然而，DNS实现通常使用关键字“ANY”来指代该类型代码；本文档遵循该常见用法。
In this document, "ANY query" refers to a DNS meta-query with QTYPE=ANY. An "ANY response" is a response to such a query.
在本文档中，“任何查询”是指QTYPE=ANY的DNS元查询。“任何响应”是对此类查询的响应。
In this document, "conventional ANY response" means an ANY response that is constructed in accordance with the algorithm documented in Section 4.3.2 of [RFC1034] and specifically without implementing any of the mechanisms described in this document.
在本文件中，“常规任何响应”是指根据[RFC1034]第4.3.2节中记录的算法构造的任何响应，具体而言，不实施本文件中描述的任何机制。
In an exchange of DNS messages between two hosts, this document refers to the host sending a DNS request as the "initiator" and the host sending a DNS response as the "responder".
在两台主机之间的DNS消息交换中，本文档将发送DNS请求的主机称为“发起方”，将发送DNS响应的主机称为“响应方”。
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]所述进行解释。
ANY queries are legitimately used for debugging and checking the state of a DNS server for a particular name.
任何查询都合法地用于调试和检查特定名称的DNS服务器的状态。
ANY queries are sometimes used as an attempt to reduce the number of queries needed to get information, e.g., to obtain MX, A, and AAAA resource record sets (RRsets) for a mail domain in a single query. However, there is no documented guidance available for this use case, and some implementations have been observed not to function as their
任何查询有时都被用作减少获取信息所需的查询数量的尝试，例如，在单个查询中获取邮件域的MX、A和AAAA资源记录集（RRSET）。然而，对于这个用例没有可用的文档化指导，并且已经观察到一些实现不能作为它们的功能
developers expected. If implementers assume that an ANY query will ultimately be received by an authoritative server and will fetch all existing RRsets, they should include a fallback mechanism to use when that does not happen.
开发者们期待着。如果实现者假设ANY查询最终将由权威服务器接收，并将获取所有现有的RRSET，那么他们应该包括一个回退机制，以便在不发生这种情况时使用。
ANY queries are frequently used to exploit the amplification potential of DNS servers and resolvers using spoofed source addresses and UDP transport (see [RFC5358]). Having the ability to return small responses to such queries makes DNS servers less attractive amplifiers.
任何查询都经常用于利用DNS服务器和解析程序的放大潜力，使用伪造的源地址和UDP传输（请参见[RFC5358]）。由于能够返回对此类查询的小响应，DNS服务器就不那么吸引人了。
ANY queries are sometimes used to help mine authoritative-only DNS servers for zone data, since they are expected to return all RRsets for a particular query name. If DNS operators prefer to reduce the potential for information leaks, they might choose not to send large ANY responses.
任何查询有时用于帮助为区域数据挖掘仅授权DNS服务器，因为它们将返回特定查询名称的所有RRSET。如果DNS运营商希望减少信息泄漏的可能性，他们可能会选择不发送任何大型响应。
Some authoritative-only DNS server implementations require additional processing in order to send a conventional ANY response; avoiding that processing expense might be desirable.
一些仅限权威的DNS服务器实现需要额外的处理，以便发送常规的任何响应；避免这种处理费用可能是可取的。
This proposal provides a mechanism for an authoritative DNS server to signal that conventional ANY queries are not supported for a particular QNAME. It does so in a way that is both compatible with and triggers desirable behavior by unmodified clients (e.g., DNS resolvers).
该方案为权威DNS服务器提供了一种机制，以表明特定QNAME不支持传统的任何查询。它以与未修改的客户端（例如DNS解析程序）兼容并触发所需行为的方式执行此操作。
Alternative proposals for dealing with ANY queries have been discussed. One approach proposes using a new RCODE to signal that an authoritative server did not answer ANY queries in the standard way. This approach was found to have an undesirable effect on both resolvers and authoritative-only servers; resolvers receiving an unknown RCODE would resend the same query to all available authoritative servers rather than suppress future ANY queries for the same QNAME.
已经讨论了处理任何疑问的备选方案。一种方法建议使用新的RCODE来表示权威服务器没有以标准方式回答任何查询。发现这种方法对解析器和仅权威服务器都有不良影响；接收未知RCODE的解析程序将向所有可用的权威服务器重新发送相同的查询，而不是抑制将来对相同QNAME的任何查询。
The proposal described in this document avoids that outcome by returning a non-empty RRset in the ANY response, which provides resolvers with something to cache and effectively suppresses repeat queries to the same or different authoritative DNS servers.
本文档中描述的方案通过在ANY响应中返回非空RRset避免了这种结果，这为解析程序提供了要缓存的内容，并有效地抑制了对相同或不同权威DNS服务器的重复查询。
Below are the three different modes of behavior by DNS responders when processing queries with QNAMEs that exist, QCLASS=IN, and QTYPE=ANY. Operators and implementers are free to choose whichever mechanism best suits their environment.
下面是DNS响应程序在处理QName为QCLASS=IN和QTYPE=ANY的查询时的三种不同行为模式。操作员和实现者可以自由选择最适合其环境的机制。
1. A DNS responder can choose to select one or a larger subset of the available RRsets at the QNAME.
1. DNS响应程序可以选择在QNAME处选择一个或更大的可用RRSET子集。
2. A DNS responder can return a synthesized HINFO resource record. See Section 6 for discussion of the use of HINFO.
2. DNS响应程序可以返回合成的HINFO资源记录。有关HINFO使用的讨论，请参见第6节。
3. A resolver can try to give out the most likely records the requester wants. This is not always possible, and the result might well be a large response.
3. 解析程序可以尝试给出请求者想要的最有可能的记录。这并不总是可能的，结果很可能是一个巨大的响应。
Except as described below in this section, the DNS responder MUST follow the standard algorithms when constructing a response.
除本节下文所述外，DNS响应程序在构建响应时必须遵循标准算法。
A DNS responder that receives an ANY query MAY decline to provide a conventional ANY response or MAY instead send a response with a single RRset (or a larger subset of available RRsets) in the answer section.
接收任何查询的DNS响应者可以拒绝提供传统的任何响应，或者可以在应答部分中使用单个RRset（或可用RRset的更大子集）发送响应。
The RRsets returned in the answer section of the response MAY consist of a single RRset owned by the name specified in the QNAME. Where multiple RRsets exist, the responder SHOULD choose a small subset of those available to reduce the amplification potential of the response.
响应的应答部分中返回的RRset可能由QNAME中指定的名称拥有的单个RRset组成。如果存在多个RRSET，响应者应选择可用RRSET的一小部分，以降低响应的放大潜力。
If the zone is signed, appropriate RRSIG records MUST be included in the answer.
如果区域已签名，则应答中必须包含适当的RRSIG记录。
Note that this mechanism does not provide any signaling to indicate to a client that an incomplete subset of the available RRsets has been returned.
请注意，此机制不提供任何信号向客户端指示已返回可用RRSET的不完整子集。
If there is no CNAME present at the owner name matching the QNAME, the resource record returned in the response MAY instead be synthesized. In this case, a single HINFO resource record SHOULD be returned. The CPU field of the HINFO RDATA SHOULD be set to "RFC8482". The OS field of the HINFO RDATA SHOULD be set to the null string to minimize the size of the response.
如果所有者名称中没有与QNAME匹配的CNAME，则可以合成响应中返回的资源记录。在这种情况下，应返回一条HINFO资源记录。HINFO RDATA的CPU字段应设置为“RFC8482”。HINFO RDATA的OS字段应设置为空字符串，以最小化响应的大小。
The TTL encoded for the synthesized HINFO resource record SHOULD be chosen by the operator of the DNS responder to be large enough to suppress frequent subsequent ANY queries from the same initiator with the same QNAME, understanding that a TTL that is too long might make policy changes relating to ANY queries difficult to change in the future. The specific value used SHOULD be configurable by the operator of the nameserver according to local policy, based on the familiar considerations involved in choosing a TTL value for any resource record in any zone.
DNS响应程序的操作员应选择为合成HINFO资源记录编码的TTL，使其足够大，以抑制来自具有相同QNAME的同一启动器的频繁后续任何查询，同时了解过长的TTL可能会使与任何查询相关的策略更改在将来难以更改。所使用的特定值应由名称服务器的操作员根据本地策略进行配置，这是基于为任何区域中的任何资源记录选择TTL值时所涉及的常见考虑因素。
If the DNS query includes DO=1 and the QNAME corresponds to a zone that is known by the responder to be signed, a valid RRSIG for the RRsets in the answer (or authority if answer is empty) section MUST be returned. In the case of DO=0, the RRSIG SHOULD be omitted.
如果DNS查询包含DO=1，并且QNAME对应于响应者已知要签名的区域，则必须返回应答（或权限，如果应答为空）部分中RRSET的有效RRSIG。如果DO=0，则应省略RRSIG。
A system that receives an HINFO response SHOULD NOT infer that the response was generated according to this specification and apply any special processing of the response because, in general, it is not possible to tell with certainty whether the HINFO RRset received was synthesized. In particular, systems SHOULD NOT rely upon the HINFO RDATA described in this section to distinguish between synthesized and non-synthesized HINFO RRsets.
接收HINFO响应的系统不应推断响应是根据本规范生成的，并对响应进行任何特殊处理，因为通常无法确定接收到的HINFO RRset是否是合成的。特别是，系统不应依赖本节中描述的HINFO RDATA来区分合成和非合成HINFO RRSET。
In some cases, it is possible to guess what the initiator wants in the answer (but not always). Some implementations have implemented the spirit of this document by returning all RRsets of RRTYPE CNAME, MX, A, and AAAA that are present at the owner name while suppressing others. This heuristic seems to work well in practice; it satisfies the needs of some applications whilst suppressing other RRsets such as TXT and DNSKEY that can often contribute to large responses. Whilst some applications may be satisfied by this behavior, the resulting responses in the general case are larger than in the approaches described in Sections 4.1 and 4.2.
在某些情况下，可以猜测发起者在答案中想要什么（但并非总是如此）。一些实现通过返回所有者名称中存在的所有RRTYPE CNAME、MX、A和AAAA的RRSET，同时抑制其他RRSET，实现了本文档的精神。这种启发式方法在实践中似乎很有效；它满足某些应用程序的需求，同时抑制其他RRSET，如TXT和DNSKEY，这些RRSET通常会导致较大的响应。虽然某些应用可能通过这种行为得到满足，但在一般情况下产生的响应大于第4.1节和第4.2节中描述的方法。
As before, if the zone is signed and the DO bit is set on the corresponding query, an RRSIG RRset MUST be included in the response.
与前面一样，如果区域已签名，并且在相应的查询上设置了DO位，则响应中必须包含RRSIG RRset。
A DNS responder MAY behave differently when processing ANY queries received over different transports, e.g., by providing a conventional ANY response over TCP whilst using one of the other mechanisms specified in this document in the case where a query was received using UDP.
当处理通过不同传输接收的任何查询时，DNS响应程序的行为可能有所不同，例如，在使用UDP接收查询的情况下，通过TCP提供传统的ANY响应，同时使用本文档中指定的其他机制之一。
Implementers MAY provide configuration options to allow operators to specify different behavior over different transports.
实现者可以提供配置选项，以允许操作员在不同的传输上指定不同的行为。
A DNS initiator that sends a query with QTYPE=ANY and receives a response containing an HINFO resource record or a single RRset, as described in Section 4, MAY cache the response in the normal way. Such cached resource records SHOULD be retained in the cache following normal caching semantics, as with any other response received from a DNS responder.
如第4节所述，发送QTYPE=ANY的查询并接收包含HINFO资源记录或单个RRset的响应的DNS启动器可以正常方式缓存响应。这种缓存的资源记录应该按照正常的缓存语义保留在缓存中，就像从DNS响应程序接收的任何其他响应一样。
A DNS initiator MAY suppress queries with QTYPE=ANY in the event that the local cache contains a matching HINFO resource record with the CPU field of the HINFO RDATA, as described in Section 4. A DNS initiator MAY instead respond to such queries with the contents of the local cache in the usual way.
如第4节所述，如果本地缓存包含与HINFO RDATA的CPU字段相匹配的HINFO资源记录，则DNS启动器可能会抑制QTYPE=ANY的查询。DNS启动器可以用本地缓存的内容以通常的方式响应此类查询。
It is possible that the synthesized HINFO RRset in an ANY response, once cached by the initiator, might suppress subsequent queries from the same initiator with QTYPE=HINFO. Thus, the use of HINFO in this proposal would effectively mask the HINFO RRset present in the zone.
ANY响应中的合成HINFO RRset一旦被启动器缓存，就可能会禁止来自同一启动器（QTYPE=HINFO）的后续查询。因此，在本提案中使用HINFO将有效掩盖区域中存在的HINFO RRset。
Operators of authoritative servers who serve zones that rely upon conventional use of the HINFO RRTYPE SHOULD sensibly choose the "single RRset" method described in this document or select another type.
为依赖HINFO RRTYPE常规使用的区域提供服务的权威服务器的运营商应明智地选择本文档中描述的“单一RRset”方法或选择其他类型。
The HINFO RRTYPE is believed to be rarely used in the DNS at the time of writing, based on observations made in passive DNS and at recursive and authoritative DNS servers.
根据在被动DNS以及递归和权威DNS服务器上进行的观察，在撰写本文时，HINFO RRTYPE被认为很少在DNS中使用。
This document extends the specification for processing ANY queries described in Section 4.3.2 of [RFC1034].
本文件扩展了[RFC1034]第4.3.2节所述任何查询的处理规范。
It is important to note that returning a subset of available RRsets when processing an ANY query is legitimate and consistent with [RFC1035]; it can be argued that ANY does not always mean ALL, as used in Section 3.2.3 of [RFC1035]. The main difference here is that the TC bit SHOULD NOT be set in the response, thus indicating that this is not a complete answer.
需要注意的是，在处理任何查询时返回可用RRSET的子集是合法的，并且与[RFC1035]一致；可以说，任何并不总是指所有，如[RFC1035]第3.2.3节所述。这里的主要区别是不应在响应中设置TC位，因此表明这不是一个完整的答案。
This document describes optional behavior for both DNS initiators and responders; implementation of the guidance provided by this document is OPTIONAL.
本文档描述DNS启动器和响应程序的可选行为；本文件提供的指南的实施是可选的。
RRSIG queries (i.e., queries with QTYPE=RRSIG) are similar to ANY queries in the sense that they have the potential to generate large responses as well as extra work for the responders that process them, e.g., in the case where signatures are generated on the fly. RRSIG RRsets are not usually obtained using such explicit queries but are rather included in the responses for other RRsets that the RRSIGs cover. This document does not specify appropriate behavior for RRSIG queries; however, future such advice might well benefit from consistency with and experience with the approaches for ANY queries described here.
RRSIG查询（即QTYPE=RRSIG的查询）与任何查询类似，因为它们有可能生成大量响应，并为处理它们的响应者提供额外的工作，例如，在动态生成签名的情况下。RRSIG RRSET通常不使用此类显式查询获得，而是包含在RRSIG涵盖的其他RRSET的响应中。本文件未规定RRSIG查询的适当行为；然而，将来这样的建议可能会受益于与这里描述的任何查询方法的一致性和经验。
In October 2015, the Cloudflare authoritative nameserver implementation implemented the HINFO response. A few minor problems were reported and have since been resolved.
2015年10月，Cloudflare权威名称服务器实现实现了HINFO响应。报告了一些小问题，并已解决。
An implementation of the subset-mode response to ANY queries was implemented in NSD 4.1 in 2016.
2016年，NSD 4.1中实现了对任何查询的子集模式响应。
An implementation of a single RRset response to an ANY query was made for BIND9 by Tony Finch, and that functionality was subsequently made available in production releases starting in BIND 9.11.
Tony Finch为BIND9实现了对ANY查询的单个RRset响应，该功能随后在从BIND 9.11开始的生产版本中可用。
Queries with QTYPE=ANY are frequently observed as part of reflection attacks, since a relatively small query can be used to elicit a large response. This is a desirable characteristic if the goal is to maximize the amplification potential of a DNS server as part of a volumetric attack. The ability of a DNS operator to suppress such responses on a particular server makes that server a less useful amplifier.
QTYPE=ANY的查询经常作为反射攻击的一部分被观察到，因为相对较小的查询可以用来引发较大的响应。如果目标是最大化DNS服务器作为体积攻击的一部分的放大潜力，则这是一个理想的特征。DNS运营商在特定服务器上抑制此类响应的能力使该服务器不再是有用的放大器。
The optional behavior described in this document to reduce the size of responses to queries with QTYPE=ANY is compatible with the use of DNSSEC by both initiator and responder.
本文档中描述的减少对QTYPE=ANY查询的响应大小的可选行为与发起方和响应方使用DNSSEC兼容。
IANA has updated the following entry in the "Resource Record (RR) TYPEs" registry [RR_TYPES]:
IANA已更新“资源记录（RR）类型”注册表[RR_类型]中的以下条目：
+------+-------+-------------------------------+--------------------+
| TYPE | Value | Meaning | Reference |
+------+-------+-------------------------------+--------------------+
| * | 255 | A request for some or all | [RFC1035][RFC6895] |
| | | records the server has | [RFC8482] |
| | | available | |
+------+-------+-------------------------------+--------------------+
+------+-------+-------------------------------+--------------------+
| TYPE | Value | Meaning | Reference |
+------+-------+-------------------------------+--------------------+
| * | 255 | A request for some or all | [RFC1035][RFC6895] |
| | | records the server has | [RFC8482] |
| | | available | |
+------+-------+-------------------------------+--------------------+
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<https://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, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, DOI 10.17487/RFC5358, October 2008, <https://www.rfc-editor.org/info/rfc5358>.
[RFC5358]Damas，J.和F.Neves，“防止在反射器攻击中使用递归名称服务器”，BCP 140，RFC 5358，DOI 10.17487/RFC5358，2008年10月<https://www.rfc-editor.org/info/rfc5358>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[RFC6895]Eastlake 3rd，D.，“域名系统（DNS）IANA注意事项”，BCP 42，RFC 6895，DOI 10.17487/RFC6895，2013年4月<https://www.rfc-editor.org/info/rfc6895>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8499]Hoffman，P.，Sullivan，A.和K.Fujiwara，“DNS术语”，BCP 219，RFC 8499，DOI 10.17487/RFC8499，2019年1月<https://www.rfc-editor.org/info/rfc8499>.
[RR_TYPES] IANA, "Domain Name System (DNS) Parameters", <https://www.iana.org/assignments/dns-parameters>.
[RR_TYPES]IANA，“域名系统（DNS）参数”<https://www.iana.org/assignments/dns-parameters>.
Acknowledgements
致谢
David Lawrence provided valuable observations and concrete suggestions. Jeremy Laidman helped make the document better. Tony Finch realized that this document was valuable and implemented it while under attack. Richard Gibson identified areas where more detail and accuracy were useful. A large number of other people also provided comments and suggestions; we thank them all for the feedback.
戴维·劳伦斯提供了宝贵的意见和具体建议。杰里米·莱德曼帮助改进了文件。托尼·芬奇意识到这份文件很有价值，并在受到攻击时实施了它。理查德·吉布森指出了更多细节和准确性有用的领域。其他许多人也提出了意见和建议；我们感谢他们的反馈。
Authors' Addresses
作者地址
Joe Abley Afilias 300-184 York Street London, ON N6A 1B5 Canada
Joe Abley Afilias位于加拿大N6A 1B5的伦敦约克街300-184号
Phone: +1 519 670 9327
Email: jabley@afilias.info
Phone: +1 519 670 9327
Email: jabley@afilias.info
Olafur Gudmundsson Cloudflare Inc.
Olafur Gudmundsson Cloudflare公司。
Email: olafur+ietf@cloudflare.com
Email: olafur+ietf@cloudflare.com
Marek Majkowski Cloudflare Inc.
马雷克·马吉科夫斯基云闪公司。
Email: marek@cloudflare.com
Email: marek@cloudflare.com
Evan Hunt ISC 950 Charter St Redwood City, CA 94063 United States of America
美国加利福尼亚州雷德伍德市埃文亨特ISC 950特许街94063号
Email: each@isc.org
Email: each@isc.org