Internet Engineering Task Force (IETF) J. Dickinson
Request for Comments: 7766 S. Dickinson
Obsoletes: 5966 Sinodun
Updates: 1035, 1123 R. Bellis
Category: Standards Track ISC
ISSN: 2070-1721 A. Mankin
D. Wessels
Verisign Labs
March 2016
Internet Engineering Task Force (IETF) J. Dickinson
Request for Comments: 7766 S. Dickinson
Obsoletes: 5966 Sinodun
Updates: 1035, 1123 R. Bellis
Category: Standards Track ISC
ISSN: 2070-1721 A. Mankin
D. Wessels
Verisign Labs
March 2016
DNS Transport over TCP - Implementation Requirements
TCP上的DNS传输-实现要求
Abstract
摘要
This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123.
该文档规定了支持TCP作为DNS实现的传输协议的要求，并提供了与DNS相比，在DNP之上的DNS在UDP上的准则。本文件淘汰了RFC 5966，因此更新了RFC 1035和RFC 1123。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7766.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7766.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Terminology . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Transport Protocol Selection . . . . . . . . . . . . . . . . 5
6. Connection Handling . . . . . . . . . . . . . . . . . . . . . 6
6.1. Current Practices . . . . . . . . . . . . . . . . . . . . 6
6.1.1. Clients . . . . . . . . . . . . . . . . . . . . . . . 7
6.1.2. Servers . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 8
6.2.1. Connection Reuse . . . . . . . . . . . . . . . . . . 8
6.2.1.1. Query Pipelining . . . . . . . . . . . . . . . . 8
6.2.2. Concurrent Connections . . . . . . . . . . . . . . . 9
6.2.3. Idle Timeouts . . . . . . . . . . . . . . . . . . . . 9
6.2.4. Teardown . . . . . . . . . . . . . . . . . . . . . . 10
7. Response Reordering . . . . . . . . . . . . . . . . . . . . . 10
8. TCP Message Length Field . . . . . . . . . . . . . . . . . . 11
9. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Summary of Advantages and Disadvantages to Using TCP
for DNS . . . . . . . . . . . . . . . . . . . . . . 16
Appendix B. Changes to RFC 5966 . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Terminology . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Transport Protocol Selection . . . . . . . . . . . . . . . . 5
6. Connection Handling . . . . . . . . . . . . . . . . . . . . . 6
6.1. Current Practices . . . . . . . . . . . . . . . . . . . . 6
6.1.1. Clients . . . . . . . . . . . . . . . . . . . . . . . 7
6.1.2. Servers . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 8
6.2.1. Connection Reuse . . . . . . . . . . . . . . . . . . 8
6.2.1.1. Query Pipelining . . . . . . . . . . . . . . . . 8
6.2.2. Concurrent Connections . . . . . . . . . . . . . . . 9
6.2.3. Idle Timeouts . . . . . . . . . . . . . . . . . . . . 9
6.2.4. Teardown . . . . . . . . . . . . . . . . . . . . . . 10
7. Response Reordering . . . . . . . . . . . . . . . . . . . . . 10
8. TCP Message Length Field . . . . . . . . . . . . . . . . . . 11
9. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Summary of Advantages and Disadvantages to Using TCP
for DNS . . . . . . . . . . . . . . . . . . . . . . 16
Appendix B. Changes to RFC 5966 . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Most DNS [RFC1034] transactions take place over UDP [RFC768]. TCP [RFC793] is always used for full zone transfers (using AXFR) and is often used for messages whose sizes exceed the DNS protocol's original 512-byte limit. The growing deployment of DNS Security (DNSSEC) and IPv6 has increased response sizes and therefore the use of TCP. The need for increased TCP use has also been driven by the protection it provides against address spoofing and therefore exploitation of DNS in reflection/amplification attacks. It is now widely used in Response Rate Limiting [RRL1] [RRL2]. Additionally, recent work on DNS privacy solutions such as [DNS-over-TLS] is another motivation to revisit DNS-over-TCP requirements.
大多数DNS[RFC1034]事务通过UDP[RFC768]进行。TCP[RFC793]始终用于全区域传输（使用AXFR），并且通常用于大小超过DNS协议原始512字节限制的消息。DNS安全（DNSSEC）和IPv6的不断增长的部署增加了响应大小，因此TCP的使用也随之增加。增加TCP使用的需求也受到其提供的防止地址欺骗的保护的驱动，因此，DNS在反射/放大攻击中被利用。它现在广泛应用于响应速率限制[RRL1][RRL2]。此外，最近关于DNS隐私解决方案（如[DNS over TLS]）的工作是重新考虑DNS over TCP需求的另一个动机。
Section 6.1.3.2 of [RFC1123] states:
[RFC1123]第6.1.3.2节规定：
DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries.
DNS解析程序和递归服务器必须支持UDP，并且应该支持TCP，以便发送（非区域传输）查询。
However, some implementors have taken the text quoted above to mean that TCP support is an optional feature of the DNS protocol.
然而，一些实现者认为上面引用的文本意味着TCP支持是DNS协议的可选功能。
The majority of DNS server operators already support TCP, and the default configuration for most software implementations is to support TCP. The primary audience for this document is those implementors whose limited support for TCP restricts interoperability and hinders deployment of new DNS features.
大多数DNS服务器运营商已经支持TCP，大多数软件实现的默认配置是支持TCP。本文档的主要读者是那些对TCP的有限支持限制了互操作性并阻碍了新DNS功能部署的实现者。
This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation.
因此，本文档更新了核心DNS协议规范，从而使TCP支持成为完整DNS协议实现的必要部分。
There are several advantages and disadvantages to the increased use of TCP (see Appendix A) as well as implementation details that need to be considered. This document addresses these issues and presents TCP as a valid transport alternative for DNS. It extends the content of [RFC5966], with additional considerations and lessons learned from research, developments, and implementation of TCP in DNS and in other Internet protocols.
增加使用TCP（见附录A）有几个优点和缺点，以及需要考虑的实施细节。本文档解决了这些问题，并将TCP作为DNS的有效传输替代方案。它扩展了[RFC5966]的内容，增加了从DNS和其他互联网协议中TCP的研究、开发和实施中获得的额外考虑和经验教训。
Whilst this document makes no specific requirements for operators of DNS servers to meet, it does offer some suggestions to operators to help ensure that support for TCP on their servers and network is optimal. It should be noted that failure to support TCP (or the blocking of DNS over TCP at the network layer) will probably result in resolution failure and/or application-level timeouts.
虽然本文件没有对DNS服务器的运营商提出具体要求，但它确实向运营商提供了一些建议，以帮助确保其服务器和网络上对TCP的支持是最佳的。应注意，如果不支持TCP（或在网络层通过TCP阻止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]中所述进行解释。
o Persistent connection: a TCP connection that is not closed either by the server after sending the first response nor by the client after receiving the first response.
o 持久连接：在发送第一个响应后服务器或在接收第一个响应后客户端都不会关闭的TCP连接。
o Connection Reuse: the sending of multiple queries and responses over a single TCP connection.
o 连接重用：通过单个TCP连接发送多个查询和响应。
o Idle DNS-over-TCP session: Clients and servers view application-level idleness differently. A DNS client considers an established DNS-over-TCP session to be idle when it has no pending queries to send and there are no outstanding responses. A DNS server considers an established DNS-over-TCP session to be idle when it has sent responses to all the queries it has received on that connection.
o TCP会话上的空闲DNS：客户端和服务器以不同的方式查看应用程序级别的空闲。当DNS客户端没有待发送的查询且没有未完成的响应时，它会将通过TCP建立的DNS会话视为空闲。当DNS服务器已发送对其在该连接上接收到的所有查询的响应时，它会将通过TCP建立的DNS会话视为空闲。
o Pipelining: the sending of multiple queries and responses over a single TCP connection but not waiting for any outstanding replies before sending another query.
o 管道：通过单个TCP连接发送多个查询和响应，但在发送另一个查询之前不等待任何未完成的响应。
o Out-of-Order Processing: The processing of queries concurrently and the returning of individual responses as soon as they are available, possibly out of order. This will most likely occur in recursive servers; however, it is possible in authoritative servers that, for example, have different backend data stores.
o 无序处理：并发处理查询，并在单个响应可用时立即返回，可能是无序的。这很可能发生在递归服务器中；但是，在权威服务器中，例如，可能有不同的后端数据存储。
In the absence of EDNS0 (Extension Mechanisms for DNS 0 [RFC6891]; see below), the normal behaviour of any DNS server that needs to send a UDP response that would exceed the 512-byte limit is for the server to truncate the response so that it fits within that limit and then set the TC flag in the response header. When the client receives such a response, it takes the TC flag as an indication that it should retry over TCP instead.
在没有EDNS0（DNS 0的扩展机制[RFC6891]；见下文）的情况下，需要发送超过512字节限制的UDP响应的任何DNS服务器的正常行为是服务器截断响应，使其符合该限制，然后在响应头中设置TC标志。当客户端收到这样的响应时，它将TC标志作为指示，指示它应该通过TCP重试。
RFC 1123 also says:
RFC1123还说：
... it is also clear that some new DNS record types defined in the future will contain information exceeding the 512 byte limit that applies to UDP, and hence will require TCP. Thus, resolvers and name servers should implement TCP services as a backup to UDP today, with the knowledge that they will require the TCP service in the future.
... 很明显，将来定义的一些新DNS记录类型将包含超过适用于UDP的512字节限制的信息，因此需要TCP。因此，解析程序和名称服务器现在应该实现TCP服务作为UDP的备份，因为它们知道将来需要TCP服务。
Existing deployments of DNSSEC [RFC4033] have shown that truncation at the 512-byte boundary is now commonplace. For example, a Non-Existent Domain (NXDOMAIN) (RCODE == 3) response from a DNSSEC-signed zone using NextSECure 3 (NSEC3) [RFC5155] is almost invariably larger than 512 bytes.
DNSSEC[RFC4033]的现有部署表明，512字节边界处的截断现在已司空见惯。例如，来自使用NextSECure 3（NSEC3）[RFC5155]的DNSSEC签名区域的不存在域（NXDOMAIN）（RCODE==3）响应几乎总是大于512字节。
Since the original core specifications for DNS were written, the extension mechanisms for DNS have been introduced. These extensions can be used to indicate that the client is prepared to receive UDP responses larger than 512 bytes. An EDNS0-compatible server receiving a request from an EDNS0-compatible client may send UDP packets up to that client's announced buffer size without truncation.
自从编写了最初的DNS核心规范之后，就引入了DNS的扩展机制。这些扩展可用于指示客户端准备接收大于512字节的UDP响应。与EDNS0兼容的服务器接收来自与EDNS0兼容的客户端的请求时，可以发送UDP数据包，该数据包的大小达到该客户端宣布的缓冲区大小，而无需截断。
However, transport of UDP packets that exceed the size of the path MTU causes IP packet fragmentation, which has been found to be unreliable in many circumstances. Many firewalls routinely block fragmented IP packets, and some do not implement the algorithms necessary to reassemble fragmented packets. Worse still, some network devices deliberately refuse to handle DNS packets containing EDNS0 options. Other issues relating to UDP transport and packet size are discussed in [RFC5625].
但是，超过路径MTU大小的UDP数据包的传输会导致IP数据包碎片，这在许多情况下都是不可靠的。许多防火墙通常会阻止碎片化的IP数据包，有些防火墙没有实现重组碎片化数据包所需的算法。更糟糕的是，一些网络设备故意拒绝处理包含EDNS0选项的DNS数据包。[RFC5625]中讨论了与UDP传输和数据包大小相关的其他问题。
The MTU most commonly found in the core of the Internet is around 1500 bytes, and even that limit is routinely exceeded by DNSSEC-signed responses.
互联网核心中最常见的MTU约为1500字节，即使是DNSSEC签名的响应也经常超过该限制。
The future that was anticipated in RFC 1123 has arrived, and the only standardised UDP-based mechanism that may have resolved the packet size issue has been found inadequate.
RFC1123中预期的未来已经到来，唯一可能解决数据包大小问题的基于UDP的标准化机制已被发现不充分。
Section 6.1.3.2 of [RFC1123] is updated: All general-purpose DNS implementations MUST support both UDP and TCP transport.
[RFC1123]第6.1.3.2节已更新：所有通用DNS实现必须同时支持UDP和TCP传输。
o Authoritative server implementations MUST support TCP so that they do not limit the size of responses to what fits in a single UDP packet.
o 权威服务器实现必须支持TCP，以便它们不会将响应的大小限制为适合单个UDP数据包的大小。
o Recursive server (or forwarder) implementations MUST support TCP so that they do not prevent large responses from a TCP-capable server from reaching its TCP-capable clients.
o 递归服务器（或转发器）实现必须支持TCP，以便它们不会阻止支持TCP的服务器的大型响应到达支持TCP的客户端。
o Stub resolver implementations (e.g., an operating system's DNS resolution library) MUST support TCP since to do otherwise would limit the interoperability between their own clients and upstream servers.
o 存根解析器实现（例如，操作系统的DNS解析库）必须支持TCP，否则会限制其自身客户端和上游服务器之间的互操作性。
Regarding the choice of when to use UDP or TCP, Section 6.1.3.2 of RFC 1123 also says:
关于何时使用UDP或TCP的选择，RFC 1123第6.1.3.2节还规定：
... a DNS resolver or server that is sending a non-zone-transfer query MUST send a UDP query first.
... 发送非区域传输查询的DNS解析程序或服务器必须首先发送UDP查询。
This requirement is hereby relaxed. Stub resolvers and recursive resolvers MAY elect to send either TCP or UDP queries depending on local operational reasons. TCP MAY be used before sending any UDP queries. If the resolver already has an open TCP connection to the server, it SHOULD reuse this connection. In essence, TCP ought to be considered a valid alternative transport to UDP, not purely a retry option.
现放宽这项规定。存根解析器和递归解析器可以根据本地操作原因选择发送TCP或UDP查询。可以在发送任何UDP查询之前使用TCP。如果冲突解决程序已与服务器建立开放的TCP连接，则应重新使用此连接。本质上，TCP应该被视为UDP的有效替代传输，而不仅仅是重试选项。
In addition, it is noted that all recursive and authoritative servers MUST send responses using the same transport as the query arrived on. In the case of TCP, this MUST also be the same connection.
此外，需要注意的是，所有递归和权威服务器都必须使用与查询到达时相同的传输发送响应。对于TCP，这也必须是相同的连接。
Section 4.2.2 of [RFC1035] says:
[RFC1035]第4.2.2节规定：
- The server should assume that the client will initiate connection closing, and should delay closing its end of the connection until all outstanding client requests have been satisfied.
- 服务器应假定客户端将启动连接关闭，并应延迟关闭其连接端，直到满足所有未完成的客户端请求。
- If the server needs to close a dormant connection to reclaim resources, it should wait until the connection has been idle for a period on the order of two minutes. In particular, the server should allow the SOA and AXFR request sequence (which begins a refresh operation) to be made on a single connection. Since the server would be unable to answer queries anyway, a unilateral close or reset may be used instead of graceful close.
- 如果服务器需要关闭休眠连接以回收资源，则应等待连接空闲两分钟左右。特别是，服务器应该允许在单个连接上执行SOA和AXFR请求序列（开始刷新操作）。由于服务器无论如何都无法回答查询，因此可以使用单边关闭或重置来代替正常关闭。
Other more modern protocols (e.g., HTTP/1.1 [RFC7230], HTTP/2 [RFC7540]) have support by default for persistent TCP connections for all requests. Connections are then normally closed via a 'connection close' signal from one party.
其他更现代的协议（例如HTTP/1.1[RFC7230]、HTTP/2[RFC7540]）默认支持所有请求的持久TCP连接。然后通过一方发出的“连接关闭”信号将连接正常关闭。
The description in [RFC1035] is clear that servers should view connections as persistent (particularly after receiving an SOA), but unfortunately does not provide enough detail for an unambiguous interpretation of client behaviour for queries other than a SOA. Additionally, DNS does not yet have a signalling mechanism for connection timeout or close, although some have been proposed.
[RFC1035]中的描述很清楚，服务器应该将连接视为持久的（特别是在接收到SOA之后），但遗憾的是，对于SOA以外的查询，没有提供足够的细节来明确解释客户端行为。此外，DNS还没有连接超时或关闭的信令机制，尽管已经提出了一些机制。
There is no clear guidance today in any RFC as to when a DNS client should close a TCP connection, and there are no specific recommendations with regard to DNS client idle timeouts. However, at the time of writing, it is common practice for clients to close the TCP connection after sending a single request (apart from the SOA/ AXFR case).
目前，在任何RFC中都没有明确的指导，说明DNS客户端何时应该关闭TCP连接，也没有关于DNS客户端空闲超时的具体建议。然而，在撰写本文时，客户端通常在发送单个请求后关闭TCP连接（SOA/AXFR案例除外）。
Many DNS server implementations use a long fixed idle timeout and default to a small number of TCP connections. They also offer little in the way of TCP connection management options. The disadvantages of this include:
许多DNS服务器实现使用固定的长空闲超时，默认为少量TCP连接。它们也很少提供TCP连接管理选项。这样做的缺点包括：
o Operational experience has shown that long server timeouts can easily cause resource exhaustion and poor response under heavy load.
o 运行经验表明，长时间的服务器超时很容易导致资源耗尽和在重负载下响应差。
o Intentionally opening many connections and leaving them idle can trivially create a TCP denial of service (DoS) attack as many DNS servers are poorly equipped to defend against this by modifying their idle timeouts or other connection management policies.
o 故意打开许多连接并使其处于空闲状态很容易造成TCP拒绝服务（DoS）攻击，因为许多DNS服务器没有足够的能力通过修改其空闲超时或其他连接管理策略来抵御这种攻击。
o A modest number of clients that all concurrently attempt to use persistent connections with non-zero idle timeouts to such a server could unintentionally cause the same DoS problem.
o 如果有一定数量的客户端同时尝试使用具有非零空闲超时的持久连接连接到这样的服务器，则可能会无意中导致相同的DoS问题。
Note that this DoS is only on the TCP service. However, in these cases, it affects not only clients that wish to use TCP for their queries for operational reasons, but all clients that choose to fall back to TCP from UDP after receiving a TC=1 flag.
请注意，此DoS仅在TCP服务上。但是，在这些情况下，它不仅会影响出于操作原因希望使用TCP进行查询的客户端，还会影响所有在接收到TC=1标志后选择从UDP返回TCP的客户端。
The following sections include recommendations that are intended to result in more consistent and scalable implementations of DNS-over-TCP.
以下部分包括旨在通过TCP实现更一致和可扩展的DNS实现的建议。
One perceived disadvantage to DNS over TCP is the added connection setup latency, generally equal to one RTT. To amortise connection setup costs, both clients and servers SHOULD support connection reuse by sending multiple queries and responses over a single persistent TCP connection.
DNS over TCP的一个明显缺点是增加了连接设置延迟，通常等于一个RTT。为了分摊连接设置成本，客户端和服务器都应该通过在单个持久TCP连接上发送多个查询和响应来支持连接重用。
When sending multiple queries over a TCP connection, clients MUST NOT reuse the DNS Message ID of an in-flight query on that connection in order to avoid Message ID collisions. This is especially important if the server could be performing out-of-order processing (see Section 7).
当通过TCP连接发送多个查询时，客户端不得在该连接上重用正在进行的查询的DNS消息ID，以避免消息ID冲突。如果服务器可能执行无序处理，这一点尤其重要（请参见第7节）。
Due to the historical use of TCP primarily for zone transfer and truncated responses, no existing RFC discusses the idea of pipelining DNS queries over a TCP connection.
由于历史上TCP主要用于区域传输和截断响应，因此没有任何现有RFC讨论通过TCP连接管道化DNS查询的想法。
In order to achieve performance on par with UDP, DNS clients SHOULD pipeline their queries. When a DNS client sends multiple queries to a server, it SHOULD NOT wait for an outstanding reply before sending the next query. Clients SHOULD treat TCP and UDP equivalently when considering the time at which to send a particular query.
为了实现与UDP相称的性能，DNS客户端应该对它们的查询进行流水线操作。当DNS客户端向服务器发送多个查询时，它不应在发送下一个查询之前等待未完成的答复。在考虑发送特定查询的时间时，客户端应同等对待TCP和UDP。
It is likely that DNS servers need to process pipelined queries concurrently and also send out-of-order responses over TCP in order to provide the level of performance possible with UDP transport. If TCP performance is of importance, clients might find it useful to use server processing times as input to server and transport selection algorithms.
DNS服务器可能需要同时处理流水线查询，并通过TCP发送无序响应，以提供UDP传输可能的性能级别。如果TCP性能很重要，客户端可能会发现使用服务器处理时间作为服务器和传输选择算法的输入很有用。
DNS servers (especially recursive) MUST expect to receive pipelined queries. The server SHOULD process TCP queries concurrently, just as it would for UDP. The server SHOULD answer all pipelined queries, even if they are received in quick succession. The handling of responses to pipelined queries is covered in Section 7.
DNS服务器（特别是递归服务器）必须能够接收流水线查询。服务器应该并发处理TCP查询，就像处理UDP一样。服务器应该回答所有流水线查询，即使它们是快速连续接收的。第7节介绍了对流水线查询响应的处理。
To mitigate the risk of unintentional server overload, DNS clients MUST take care to minimize the number of concurrent TCP connections made to any individual server. It is RECOMMENDED that for any given client/server interaction there SHOULD be no more than one connection for regular queries, one for zone transfers, and one for each protocol that is being used on top of TCP (for example, if the resolver was using TLS). However, it is noted that certain primary/ secondary configurations with many busy zones might need to use more than one TCP connection for zone transfers for operational reasons (for example, to support concurrent transfers of multiple zones).
为了降低服务器意外过载的风险，DNS客户端必须注意尽量减少与任何单个服务器的并发TCP连接数。建议对于任何给定的客户机/服务器交互，常规查询的连接不应超过一个，区域传输的连接不应超过一个，TCP上使用的每个协议的连接不应超过一个（例如，如果解析器使用TLS）。但是，需要注意的是，由于操作原因（例如，为了支持多个区域的并发传输），具有许多繁忙区域的某些主/辅助配置可能需要使用多个TCP连接进行区域传输。
Similarly, servers MAY impose limits on the number of concurrent TCP connections being handled for any particular client IP address or subnet. These limits SHOULD be much looser than the client guidelines above, because the server does not know, for example, if a client IP address belongs to a single client, is multiple resolvers on a single machine, or is multiple clients behind a device performing Network Address Translation (NAT).
类似地，服务器可能会对任何特定客户端IP地址或子网正在处理的并发TCP连接的数量施加限制。这些限制应该比上面的客户机指南宽松得多，因为服务器不知道，例如，一个客户机IP地址是否属于一个客户机，是一台机器上的多个解析器，还是一个设备后面的多个客户机正在执行网络地址转换（NAT）。
To mitigate the risk of unintentional server overload, DNS clients MUST take care to minimise the idle time of established DNS-over-TCP sessions made to any individual server. DNS clients SHOULD close the TCP connection of an idle session, unless an idle timeout has been established using some other signalling mechanism, for example, [edns-tcp-keepalive].
为了降低服务器意外过载的风险，DNS客户端必须注意尽量减少已建立的DNS通过TCP会话对任何单个服务器的空闲时间。DNS客户端应关闭空闲会话的TCP连接，除非已使用某些其他信令机制（例如，[edns TCP keepalive]）建立空闲超时。
To mitigate the risk of unintentional server overload, it is RECOMMENDED that the default server application-level idle period be on the order of seconds, but no particular value is specified. In practice, the idle period can vary dynamically, and servers MAY allow idle connections to remain open for longer periods as resources permit. A timeout of at least a few seconds is advisable for normal operations to support those clients that expect the SOA and AXFR request sequence to be made on a single connection as originally specified in [RFC1035]. Servers MAY use zero timeouts when they are experiencing heavy load or are under attack.
为了降低意外服务器过载的风险，建议默认服务器应用程序级别的空闲时间为秒，但不指定特定值。实际上，空闲时间可以动态变化，服务器可能允许空闲连接在资源允许的情况下保持更长时间的开放。对于正常操作，建议至少超时几秒钟，以支持那些希望在单个连接上执行SOA和AXFR请求序列的客户端，如[RFC1035]中最初指定的那样。服务器在负载过重或受到攻击时可能会使用零超时。
DNS messages delivered over TCP might arrive in multiple segments. A DNS server that resets its idle timeout after receiving a single segment might be vulnerable to a "slow-read attack". For this reason, servers SHOULD reset the idle timeout on the receipt of a full DNS message, rather than on receipt of any part of a DNS message.
通过TCP传递的DNS消息可能以多个段到达。接收到单个网段后重置其空闲超时的DNS服务器可能容易受到“慢速读取攻击”。因此，服务器应在收到完整DNS消息时重置空闲超时，而不是在收到DNS消息的任何部分时重置空闲超时。
Under normal operation DNS clients typically initiate connection closing on idle connections; however, DNS servers can close the connection if the idle timeout set by local policy is exceeded. Also, connections can be closed by either end under unusual conditions such as defending against an attack or system failure/ reboot.
在正常操作下，DNS客户端通常在空闲连接上启动连接关闭；但是，如果超过本地策略设置的空闲超时，DNS服务器可以关闭连接。此外，在防御攻击或系统故障/重新启动等异常情况下，连接的两端都可以关闭。
DNS clients SHOULD retry unanswered queries if the connection closes before receiving all outstanding responses. No specific retry algorithm is specified in this document.
如果连接在收到所有未响应之前关闭，DNS客户端应重试未响应的查询。本文档中未指定特定的重试算法。
If a DNS server finds that a DNS client has closed a TCP session (or if the session has been otherwise interrupted) before all pending responses have been sent, then the server MUST NOT attempt to send those responses. Of course, the DNS server MAY cache those responses.
如果DNS服务器发现DNS客户端在发送所有挂起的响应之前已关闭TCP会话（或者会话已被中断），则服务器不得尝试发送这些响应。当然，DNS服务器可以缓存这些响应。
RFC 1035 is ambiguous on the question of whether TCP responses may be reordered -- the only relevant text is in Section 4.2.1, which relates to UDP:
RFC 1035在TCP响应是否可以重新排序的问题上模棱两可——唯一相关的文本在第4.2.1节中，该节与UDP有关：
Queries or their responses may be reordered by the network, or by processing in name servers, so resolvers should not depend on them being returned in order.
查询或它们的响应可以由网络重新排序，也可以在名称服务器中进行处理，因此解析程序不应该依赖于它们按顺序返回。
For the avoidance of future doubt, this requirement is clarified. Authoritative servers and recursive resolvers are RECOMMENDED to support the preparing of responses in parallel and sending them out of order, regardless of the transport protocol in use. Stub and recursive resolvers MUST be able to process responses that arrive in a different order than that in which the requests were sent, regardless of the transport protocol in use.
为避免将来产生疑问，澄清了该要求。无论使用何种传输协议，建议使用权威服务器和递归解析器来支持并行准备响应并按顺序发送响应。存根解析程序和递归解析程序必须能够处理以与发送请求的顺序不同的顺序到达的响应，而不管使用何种传输协议。
In order to achieve performance on par with UDP, recursive resolvers SHOULD process TCP queries in parallel and return individual responses as soon as they are available, possibly out of order.
为了实现与UDP相称的性能，递归解析器应该并行处理TCP查询并返回单个响应，只要它们可用，可能是无序的。
Since pipelined responses can arrive out of order, clients MUST match responses to outstanding queries on the same TCP connection using the Message ID. If the response contains a question section, the client MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients to properly match responses to outstanding queries can have serious consequences for interoperability.
由于管道响应可能会无序到达，因此客户端必须使用消息ID匹配同一TCP连接上未完成查询的响应。如果响应包含问题部分，则客户端必须匹配QNAME、QCClass和QTYPE字段。客户端未能正确匹配对未完成查询的响应可能会对互操作性造成严重后果。
DNS clients and servers SHOULD pass the two-octet length field, and the message described by that length field, to the TCP layer at the same time (e.g., in a single "write" system call) to make it more likely that all the data will be transmitted in a single TCP segment. This is for reasons of both efficiency and to avoid problems due to some DNS server implementations behaving undesirably when reading data from the TCP layer (due to a lack of clarity in previous documents). For example, some DNS server implementations might abort a TCP session if the first "read" from the TCP layer does not contain both the length field and the entire message.
DNS客户端和服务器应同时将两个八位字节长度字段和该长度字段描述的消息传递给TCP层（例如，在单个“写入”系统调用中），以使所有数据更有可能在单个TCP段中传输。这是出于效率和避免一些DNS服务器实现在从TCP层读取数据时表现不理想（由于以前的文档不清楚）而导致的问题的原因。例如，如果TCP层的第一次“读取”不包含长度字段和整个消息，则某些DNS服务器实现可能会中止TCP会话。
To clarify, DNS servers MUST NOT close a connection simply because the first "read" from the TCP layer does not contain the entire DNS message, and servers SHOULD apply the connection timeouts as specified in Section 6.2.3.
为了澄清，DNS服务器不得仅仅因为TCP层的第一次“读取”不包含整个DNS消息而关闭连接，服务器应按照第6.2.3节的规定应用连接超时。
This section is non-normative.
本节是非规范性的。
TCP Fast Open (TFO) [RFC7413] allows data to be carried in the SYN packet, reducing the cost of reopening TCP connections. It also saves up to one RTT compared to standard TCP.
TCP快速打开（TFO）[RFC7413]允许在SYN数据包中携带数据，从而降低重新打开TCP连接的成本。与标准TCP相比，它还可以节省多达一个RTT。
TFO mitigates the security vulnerabilities inherent in sending data in the SYN, especially on a system like DNS where amplification attacks are possible, by use of a server-supplied cookie. TFO clients request a server cookie in the initial SYN packet at the start of a new connection. The server returns a cookie in its SYN-ACK. The client caches the cookie and reuses it when opening subsequent connections to the same server.
TFO通过使用服务器提供的cookie，缓解了在SYN中发送数据时固有的安全漏洞，特别是在DNS这样的系统上，在这种系统上，可能会发生放大攻击。TFO客户端在新连接开始时在初始SYN数据包中请求服务器cookie。服务器在其SYN-ACK中返回一个cookie。客户端缓存cookie，并在打开与同一服务器的后续连接时重用它。
The cookie is stored by the client's TCP stack (kernel) and persists if either the client or server processes are restarted. TFO also falls back to a regular TCP handshake gracefully.
cookie由客户机的TCP堆栈（内核）存储，如果客户机或服务器进程重新启动，cookie将持续存在。TFO还可以优雅地返回到常规TCP握手。
DNS services taking advantage of IP anycast [RFC4786] might need to take additional steps when enabling TFO. From [RFC7413]:
启用TFO时，利用IP选播[RFC4786]的DNS服务可能需要采取其他步骤。从[RFC7413]：
Servers behind load balancers that accept connection requests to the same server IP address should use the same key such that they generate identical Fast Open cookies for a particular client IP address. Otherwise, a client may get different cookies across connections; its Fast Open attempts would fall back to the regular 3WHS.
负载平衡器后面的服务器接受到相同服务器IP地址的连接请求，它们应该使用相同的密钥，以便为特定客户端IP地址生成相同的快速打开cookie。否则，客户端可能会跨连接获得不同的cookie；它的快速开放尝试将回落到常规的3WH。
When DNS-over-TCP is a transport for DNS private exchange, as in [DNS-over-TLS], the implementor needs to be aware of TFO and to ensure that data requiring protection (e.g. data for a DNS query) is not accidentally transported in the clear. See [DNS-over-TLS] for discussion.
当TCP上的DNS是DNS专用交换的传输时，如[DNS over TLS]中所述，实施者需要了解TFO，并确保需要保护的数据（例如DNS查询的数据）不会意外地以明文形式传输。有关讨论，请参阅[DNS over TLS]。
Some DNS server operators have expressed concern that wider promotion and use of DNS over TCP will expose them to a higher risk of DoS attacks on TCP (both accidental and deliberate).
一些DNS服务器运营商表示担心，在TCP上更广泛地推广和使用DNS将使他们面临更高的TCP DoS攻击风险（包括意外攻击和故意攻击）。
Although there is a higher risk of some specific attacks against TCP-enabled servers, techniques for the mitigation of DoS attacks at the network level have improved substantially since DNS was first designed.
尽管针对启用TCP的服务器的某些特定攻击的风险较高，但自DNS首次设计以来，在网络级别缓解DoS攻击的技术已经有了很大的改进。
Readers are advised to familiarise themselves with [CPNI-TCP], a security assessment of TCP that details known TCP attacks and countermeasures and that references most of the relevant RFCs on this topic.
建议读者熟悉[CPNI-TCP]，这是一种TCP安全评估，详细说明了已知的TCP攻击和对策，并参考了此主题的大多数相关RFC。
To mitigate the risk of DoS attacks, DNS servers are advised to engage in TCP connection management. This could include maintaining state on existing connections, reusing existing connections, and controlling request queues to enable fair use. It is likely to be advantageous to provide configurable connection management options, for example:
为了降低DoS攻击的风险，建议DNS服务器参与TCP连接管理。这可能包括维护现有连接的状态、重用现有连接以及控制请求队列以实现公平使用。提供可配置的连接管理选项可能是有利的，例如：
o total number of TCP connections
o TCP连接的总数
o maximum TCP connections per source IP address or subnet
o 每个源IP地址或子网的最大TCP连接数
o TCP connection idle timeout
o TCP连接空闲超时
o maximum DNS transactions per TCP connection
o 每个TCP连接的最大DNS事务数
o maximum TCP connection duration
o 最大TCP连接持续时间
No specific values are recommended for these parameters.
这些参数不建议使用特定值。
Operators are advised to familiarise themselves with the configuration and tuning parameters available in the TCP stack of the operating system. However, detailed advice on this is outside the scope of this document.
建议操作员熟悉操作系统TCP堆栈中可用的配置和调优参数。但是，关于这方面的详细建议不在本文件的范围之内。
Operators of recursive servers are advised to ensure that they only accept connections from expected clients (for example, by the use of an Access Control List (ACL)) and do not accept them from unknown sources. In the case of UDP traffic, this will help protect against reflection attacks [RFC5358]; and in the case of TCP traffic, it will prevent an unknown client from exhausting the server's limits on the number of concurrent connections.
建议递归服务器的操作员确保他们只接受来自预期客户端的连接（例如，通过使用访问控制列表（ACL））而不接受来自未知源的连接。在UDP通信的情况下，这将有助于防止反射攻击[RFC5358]；在TCP通信的情况下，它将防止未知客户端耗尽服务器对并发连接数的限制。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，DOI 10.17487/RFC0768，1980年8月<http://www.rfc-editor.org/info/rfc768>.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，DOI 10.17487/RFC0793，1981年9月<http://www.rfc-editor.org/info/rfc793>.
[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>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <http://www.rfc-editor.org/info/rfc1123>.
[RFC1123]Braden，R.，Ed.“互联网主机的要求-应用和支持”，STD 3，RFC 1123，DOI 10.17487/RFC1123，1989年10月<http://www.rfc-editor.org/info/rfc1123>.
[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>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<http://www.rfc-editor.org/info/rfc4033>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[RFC4786]Abley，J.和K.Lindqvist，“任意广播服务的运营”，BCP 126，RFC 4786，DOI 10.17487/RFC4786，2006年12月<http://www.rfc-editor.org/info/rfc4786>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, <http://www.rfc-editor.org/info/rfc5155>.
[RFC5155]Laurie，B.，Sisson，G.，Arends，R.，和D.Blacka，“DNS安全（DNSSEC）哈希认证拒绝存在”，RFC 5155，DOI 10.17487/RFC5155，2008年3月<http://www.rfc-editor.org/info/rfc5155>.
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, DOI 10.17487/RFC5358, October 2008, <http://www.rfc-editor.org/info/rfc5358>.
[RFC5358]Damas，J.和F.Neves，“防止在反射器攻击中使用递归名称服务器”，BCP 140，RFC 5358，DOI 10.17487/RFC5358，2008年10月<http://www.rfc-editor.org/info/rfc5358>.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, <http://www.rfc-editor.org/info/rfc5625>.
[RFC5625]Bellis，R.，“DNS代理实施指南”，BCP 152，RFC 5625，DOI 10.17487/RFC5625，2009年8月<http://www.rfc-editor.org/info/rfc5625>.
[RFC5966] Bellis, R., "DNS Transport over TCP - Implementation Requirements", RFC 5966, DOI 10.17487/RFC5966, August 2010, <http://www.rfc-editor.org/info/rfc5966>.
[RFC5966]Bellis，R.，“TCP上的DNS传输-实施要求”，RFC 5966，DOI 10.17487/RFC5966，2010年8月<http://www.rfc-editor.org/info/rfc5966>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <http://www.rfc-editor.org/info/rfc6891>.
[RFC6891]Damas，J.，Graff，M.，和P.Vixie，“DNS的扩展机制（EDNS（0）），STD 75，RFC 6891，DOI 10.17487/RFC68911913年4月<http://www.rfc-editor.org/info/rfc6891>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.
[RFC7540]Belshe，M.，Paon，R.，和M.Thomson，编辑，“超文本传输协议版本2（HTTP/2）”，RFC 7540，DOI 10.17487/RFC7540，2015年5月<http://www.rfc-editor.org/info/rfc7540>.
[Connection-Oriented-DNS] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., and N. Somaiya, "Connection-Oriented DNS to Improve Privacy and Security", 2015 IEEE Symposium on Security and Privacy (SP), DOI 10.1109/SP.2015.18, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=7163025>.
[Connection Oriented DNS]Zhu，L.，Hu，Z.，Heidemann，J.，Wessels，D.，Mankin，A.，和N.Somaiya，“面向连接的DNS改善隐私和安全”，2015年IEEE安全和隐私研讨会（SP），DOI 10.1109/SP.2015.18<http://ieeexplore.ieee.org/xpl/ articleDetails.jsp？arnumber=7163025>。
[CPNI-TCP] CPNI, "Security Assessment of the Transmission Control Protocol (TCP)", 2009, <http://www.gont.com.ar/papers/ tn-03-09-security-assessment-TCP.pdf>.
[CPNI-TCP]CPNI，“传输控制协议（TCP）的安全评估”，2009年<http://www.gont.com.ar/papers/ tn-03-09-security-assessment-TCP.pdf>。
[DNS-over-TLS] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over TLS", Work in Progress, draft-ietf-dprive-dns-over-tls-06, February 2016.
[DNS over TLS]Hu，Z.，Zhu，L.，Heidemann，J.，Mankin，A.，Wessels，D.，和P.Hoffman，“DNS over TLS规范”，正在进行的工作，草案-ietf-dprive-DNS-over-TLS-062016年2月。
[edns-tcp-keepalive] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The edns-tcp-keepalive EDNS0 Option", Work in Progress, draft-ietf-dnsop-edns-tcp-keepalive-03, September 2015.
[edns tcp keepalive]Wouters，P.，Abley，J.，Dickinson，S.，和R.Bellis，“edns tcp keepalive EDNS0选项”，在建工程，草案-ietf-dnsop-edns-tcp-keepalive-032015年9月。
[fragmentation-considered-poisonous] Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous", May 2012, <http://arxiv.org/abs/1205.4011>.
[碎片被认为有毒]Herzberg，A.和H.Shulman，“碎片被认为有毒”，2012年5月<http://arxiv.org/abs/1205.4011>.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, <http://www.rfc-editor.org/info/rfc5405>.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，DOI 10.17487/RFC5405，2008年11月<http://www.rfc-editor.org/info/rfc5405>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <http://www.rfc-editor.org/info/rfc6824>.
[RFC6824]Ford，A.，Raiciu，C.，Handley，M.，和O.Bonaventure，“多地址多路径操作的TCP扩展”，RFC 6824DOI 10.17487/RFC68242013年1月<http://www.rfc-editor.org/info/rfc6824>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <http://www.rfc-editor.org/info/rfc7413>.
[RFC7413]Cheng，Y.，Chu，J.，Radhakrishnan，S.，和A.Jain，“TCP快速开放”，RFC 7413，DOI 10.17487/RFC74132014年12月<http://www.rfc-editor.org/info/rfc7413>.
[RRL1] Vixie, P. and V. Schryver, "DNS Response Rate Limiting (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012, <https://ftp.isc.org/isc/pubs/tn/isc-tn-2012-1.txt>.
[RRL1]Vixie，P.和V.Schryver，“DNS响应速率限制（DNS RRL）”，ISC-TN 2012-1-Draft1，2012年4月<https://ftp.isc.org/isc/pubs/tn/isc-tn-2012-1.txt>.
[RRL2] ISC Support, "Using the Response Rate Limiting Feature in BIND 9.10", ISC Knowledge Base AA-00994, June 2013, <https://kb.isc.org/article/AA-00994/>.
[RRL2]ISC支持，“使用BIND 9.10中的响应速率限制功能”，ISC知识库AA-009942013年6月<https://kb.isc.org/article/AA-00994/>.
Appendix A. Summary of Advantages and Disadvantages to Using TCP for DNS
附录A.将TCP用于DNS的优缺点摘要
The TCP handshake generally prevents address spoofing and, therefore, the reflection/amplification attacks that plague UDP.
TCP握手通常可以防止地址欺骗，从而防止困扰UDP的反射/放大攻击。
IP fragmentation is less of a problem for TCP than it is for UDP. TCP stacks generally implement Path MTU Discovery so they can avoid IP fragmentation of TCP segments. UDP, on the other hand, does not provide reassembly; this means datagrams that exceed the path MTU size must experience fragmentation [RFC5405]. Middleboxes are known to block IP fragments, leading to timeouts and forcing client implementations to "hunt" for EDNS0 reply size values supported by the network path. Additionally, fragmentation may lead to cache poisoning [fragmentation-considered-poisonous].
与UDP相比，TCP的IP碎片问题更少。TCP堆栈通常实现路径MTU发现，因此它们可以避免TCP段的IP碎片。另一方面，UDP不提供重新组装；这意味着超过路径MTU大小的数据报必须经历碎片[RFC5405]。众所周知，中间盒会阻止IP片段，导致超时，并迫使客户端实现“搜寻”网络路径支持的EDNS0回复大小值。此外，碎片可能导致缓存中毒[碎片被认为有毒]。
TCP setup costs an additional RTT compared to UDP queries. Setup costs can be amortised by reusing connections, pipelining queries, and enabling TCP Fast Open.
与UDP查询相比，TCP设置需要额外的RTT。安装成本可以通过重用连接、管道查询和启用TCP Fast Open来分摊。
TCP imposes additional state-keeping requirements on clients and servers. The use of TCP Fast Open reduces the cost of closing and reopening TCP connections.
TCP对客户端和服务器施加了额外的状态保持要求。使用TCP Fast Open可以降低关闭和重新打开TCP连接的成本。
Long-lived TCP connections to anycast servers might be disrupted due to routing changes. Clients utilizing TCP for DNS need to always be prepared to re-establish connections or otherwise retry outstanding queries. It might also be possible for Multipath TCP [RFC6824] to allow a server to hand a connection over from the anycast address to a unicast address.
到选播服务器的长期TCP连接可能因路由更改而中断。使用TCP for DNS的客户端需要随时准备重新建立连接或重试未完成的查询。多路径TCP[RFC6824]也可能允许服务器将连接从选播地址切换到单播地址。
There are many "middleboxes" in use today that interfere with TCP over port 53 [RFC5625]. This document does not propose any solutions, other than to make it absolutely clear that TCP is a valid transport for DNS and support for it is a requirement for all implementations.
现在使用的许多“中间盒”会干扰端口53[RFC5625]上的TCP。本文档没有提出任何解决方案，只是明确说明TCP是DNS的有效传输，并且支持它是所有实现的要求。
A more in-depth discussion of connection-oriented DNS can be found elsewhere [Connection-Oriented-DNS].
有关面向连接的DNS的更深入讨论，请参见[面向连接的DNS]。
This document obsoletes [RFC5966] and differs from it in several respects. An overview of the most substantial changes/updates that implementors should take note of is given below.
本文件淘汰了[RFC5966]，并在几个方面与之不同。下面概述了实施者应该注意的最重要的更改/更新。
1. A Terminology section (Section 3) is added defining several new concepts.
1. 增加了术语部分（第3节），定义了几个新概念。
2. Paragraph 3 of Section 5 puts TCP on a more equal footing with UDP than RFC 5966 does. For example, it states:
2. 第5节第3段将TCP置于比RFC 5966更平等的UDP基础上。例如，它指出：
1. TCP MAY be used before sending any UDP queries.
1. 可以在发送任何UDP查询之前使用TCP。
2. TCP ought to be considered a valid alternative transport to UDP, not purely a fallback option.
2. TCP应该被视为UDP的有效替代传输，而不仅仅是一种回退选项。
3. Section 6.2.1 adds a new recommendation that TCP connection reuse SHOULD be supported.
3. 第6.2.1节增加了一项新的建议，即应支持TCP连接重用。
4. Section 6.2.1.1 adds a new recommendation that DNS clients SHOULD pipeline their queries and DNS servers SHOULD process pipelined queries concurrently.
4. 第6.2.1.1节增加了一项新建议，即DNS客户端应通过管道传输其查询，DNS服务器应同时处理管道传输的查询。
5. Section 6.2.2 adds new recommendations on the number and usage of TCP connections for client/server interactions.
5. 第6.2.2节增加了有关客户端/服务器交互的TCP连接的数量和使用的新建议。
6. Section 6.2.3 adds a new recommendation that DNS clients SHOULD close idle sessions unless using a signalling mechanism.
6. 第6.2.3节增加了一项新建议，即DNS客户端应关闭空闲会话，除非使用信令机制。
7. Section 7 clarifies that servers are RECOMMENDED to prepare TCP responses in parallel and send answers out of order. It also clarifies how TCP queries and responses should be matched by clients.
7. 第7节阐明了建议服务器并行准备TCP响应并按顺序发送响应。它还阐明了客户端应如何匹配TCP查询和响应。
8. Section 8 adds a new recommendation about how DNS clients and servers should handle the 2-byte message length field for TCP messages.
8. 第8节添加了一项新建议，说明DNS客户端和服务器应如何处理TCP消息的2字节消息长度字段。
9. Section 9 adds a non-normative discussion of the use of TCP Fast Open.
9. 第9节增加了关于TCP Fast Open使用的非规范性讨论。
10. Section 10 adds new advice regarding DoS mitigation techniques.
10. 第10节增加了关于DoS缓解技术的新建议。
Acknowledgements
致谢
The authors would like to thank Francis Dupont and Paul Vixie for their detailed reviews, as well as Andrew Sullivan, Tony Finch, Stephane Bortzmeyer, Joe Abley, Tatuya Jinmei, and the many others who contributed to the mailing list discussion. Also, the authors thank Liang Zhu, Zi Hu, and John Heidemann for extensive DNS-over-TCP discussions and code, and Lucie Guiraud and Danny McPherson for reviewing early draft versions of this document. We would also like to thank all those who contributed to RFC 5966.
作者要感谢Francis Dupont和Paul Vixie的详细评论，以及Andrew Sullivan、Tony Finch、Stephane Bortzmeyer、Joe Abley、Tatuya Jinmei和其他参与邮件列表讨论的人。此外，作者还感谢梁祝、Zi Hu和John Heidemann对TCP上DNS的广泛讨论和代码，以及Lucie Guiraud和Danny McPherson对本文档早期草案版本的审查。我们还要感谢所有为RFC 5966捐款的人。
Authors' Addresses
作者地址
John Dickinson Sinodun Internet Technologies Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom
John Dickinson Sinodun互联网技术Magdalen中心牛津科技园牛津OX4 4GA英国
Email: jad@sinodun.com
URI: http://sinodun.com
Email: jad@sinodun.com
URI: http://sinodun.com
Sara Dickinson Sinodun Internet Technologies Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom
Sara Dickinson Sinodun互联网技术中心牛津科技园牛津OX4 4GA英国
Email: sara@sinodun.com
URI: http://sinodun.com
Email: sara@sinodun.com
URI: http://sinodun.com
Ray Bellis Internet Systems Consortium, Inc 950 Charter Street Redwood City, CA 94063 United States
美国加利福尼亚州红木市查特街950号Ray Bellis Internet Systems Consortium，Inc.94063
Phone: +1 650 423 1200
Email: ray@isc.org
URI: http://www.isc.org
Phone: +1 650 423 1200
Email: ray@isc.org
URI: http://www.isc.org
Allison Mankin Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States
Allison Mankin Verisign实验室12061美国弗吉尼亚州布鲁蒙特路莱斯顿，邮编：20190
Phone: +1 301 728 7198
Email: allison.mankin@gmail.com
Phone: +1 301 728 7198
Email: allison.mankin@gmail.com
Duane Wessels Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States
杜安·韦塞尔Verisign实验室12061美国弗吉尼亚州布鲁蒙特路莱斯顿，邮编：20190
Phone: +1 703 948 3200
Email: dwessels@verisign.com
Phone: +1 703 948 3200
Email: dwessels@verisign.com