Internet Engineering Task Force (IETF) P. Wouters
Request for Comments: 7828 Red Hat
Category: Standards Track J. Abley
ISSN: 2070-1721 Dyn, Inc.
S. Dickinson
Sinodun
R. Bellis
ISC
April 2016
Internet Engineering Task Force (IETF) P. Wouters
Request for Comments: 7828 Red Hat
Category: Standards Track J. Abley
ISSN: 2070-1721 Dyn, Inc.
S. Dickinson
Sinodun
R. Bellis
ISC
April 2016
The edns-tcp-keepalive EDNS0 Option
edns tcp keepalive EDNS0选项
Abstract
摘要
DNS messages between clients and servers may be received over either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds.
客户端和服务器之间的DNS消息可以通过UDP或TCP接收。UDP传输需要在繁忙的服务器上保持较少的状态，但可能会导致截断和通过TCP重试。此外，UDP还可用于反射攻击。使用TCP将减少重传和放大。但是，客户端通常仅在重试时使用TCP，服务器通常使用以秒为单位的空闲超时。
This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time.
本文档定义了一个EDNS0选项（“edns tcp keepalive”），该选项允许DNS服务器发出可变空闲超时信号。此信令通过允许有效管理与TCP传输相关联的状态而对DNS事务时间的影响最小，从而鼓励使用长寿命TCP连接。
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/rfc7828.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7828.
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 Notation . . . . . . . . . . . . . . . . . . . . 4
3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 5
3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 5
3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 5
3.2.2. Receiving Responses . . . . . . . . . . . . . . . . . 6
3.3. Use by DNS Servers . . . . . . . . . . . . . . . . . . . 6
3.3.1. Receiving Queries . . . . . . . . . . . . . . . . . . 6
3.3.2. Sending Responses . . . . . . . . . . . . . . . . . . 6
3.4. TCP Session Management . . . . . . . . . . . . . . . . . 7
3.5. Non-clean Paths . . . . . . . . . . . . . . . . . . . . . 8
3.6. Anycast Considerations . . . . . . . . . . . . . . . . . 8
4. Intermediary Considerations . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 5
3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 5
3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 5
3.2.2. Receiving Responses . . . . . . . . . . . . . . . . . 6
3.3. Use by DNS Servers . . . . . . . . . . . . . . . . . . . 6
3.3.1. Receiving Queries . . . . . . . . . . . . . . . . . . 6
3.3.2. Sending Responses . . . . . . . . . . . . . . . . . . 6
3.4. TCP Session Management . . . . . . . . . . . . . . . . . 7
3.5. Non-clean Paths . . . . . . . . . . . . . . . . . . . . . 8
3.6. Anycast Considerations . . . . . . . . . . . . . . . . . 8
4. Intermediary Considerations . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
DNS messages between clients and servers may be received over either UDP or TCP [RFC1035]. Historically, DNS clients used APIs that only facilitated sending and receiving a single query over either UDP or TCP. New APIs and deployment of DNSSEC validating resolvers on hosts that in the past were using stub resolving only is increasing the DNS client base that prefer using long-lived TCP connections. Long-lived TCP connections can result in lower request latency than the case where UDP transport is used and truncated responses are received. This is because clients that retry over TCP following a truncated UDP response typically only use the TCP session for a single (request, response) pair, continuing with UDP transport for subsequent queries.
客户端和服务器之间的DNS消息可以通过UDP或TCP[RFC1035]接收。历史上，DNS客户端使用的API仅促进通过UDP或TCP发送和接收单个查询。新的API和在过去仅使用存根解析的主机上部署DNSSEC验证解析程序增加了更喜欢使用长寿命TCP连接的DNS客户端。与使用UDP传输和接收截断响应的情况相比，长寿命TCP连接可以降低请求延迟。这是因为在经过截断的UDP响应之后通过TCP重试的客户端通常只对单个（请求、响应）对使用TCP会话，继续使用UDP传输进行后续查询。
The use of TCP transport requires state to be retained on DNS servers. If a server is to perform adequately with a significant query load received over TCP, it must manage its available resources to ensure that all established TCP sessions are well-used, and idle connections are closed after an appropriate amount of time.
使用TCP传输需要在DNS服务器上保留状态。如果服务器要在通过TCP接收到大量查询负载的情况下充分执行，它必须管理其可用资源，以确保所有已建立的TCP会话都得到充分利用，并且空闲连接在适当的时间后关闭。
UDP transport is stateless, and hence presents a much lower resource burden on a busy DNS server than TCP. An exchange of DNS messages over UDP can also be completed in a single round trip between communicating hosts, resulting in optimally short transaction times. UDP transport is not without its risks, however.
UDP传输是无状态的，因此在繁忙的DNS服务器上的资源负担比TCP低得多。通过UDP的DNS消息交换也可以在通信主机之间的一次往返中完成，从而使事务时间最短。然而，UDP传输并非没有风险。
A single-datagram exchange over UDP between two hosts can be exploited to enable a reflection attack on a third party. Response Rate Limiting [RRL] is designed to help mitigate such attacks against authoritative-only servers. One feature of RRL is to let some amount of responses "slip" through the rate limiter. These are returned with the TC (truncation) bit set, which causes legitimate clients to resend the same query using TCP transport.
可以利用两台主机之间通过UDP进行的单个数据报交换对第三方发起反射攻击。响应速率限制[RRL]旨在帮助缓解针对仅授权服务器的此类攻击。RRL的一个特点是让一定数量的响应“滑过”速率限制器。它们随TC（截断）位集一起返回，这会导致合法客户端使用TCP传输重新发送相同的查询。
[RFC1035] specified a maximum DNS message size over UDP transport of 512 bytes. Deployment of DNSSEC [RFC4033] and other protocols subsequently increased the observed frequency at which responses exceed this limit. EDNS0 [RFC6891] allows DNS messages larger than 512 bytes to be exchanged over UDP, with a corresponding increased incidence of fragmentation. Fragmentation is known to be problematic in general, and has also been implicated in increasing the risk of cache poisoning attacks [fragmentation-considered-poisonous].
[RFC1035]在UDP传输上指定了512字节的最大DNS消息大小。DNSSEC[RFC4033]和其他协议的部署随后增加了观察到的响应超过此限制的频率。EDNS0[RFC6891]允许通过UDP交换大于512字节的DNS消息，相应地碎片发生率增加。碎片通常是有问题的，并且还与增加缓存中毒攻击的风险有关[碎片被认为是有毒的]。
TCP transport is less susceptible to the risks of fragmentation and reflection attacks. However, TCP transport for DNS as currently deployed has expensive setup overhead, compared to using UDP (when no retry is required).
TCP传输不易受到碎片和反射攻击的风险。但是，与使用UDP（不需要重试）相比，当前部署的DNS TCP传输的设置开销非常大。
The overhead of the three-way TCP handshake for a single DNS transaction is substantial, increasing the transaction time for a single (request, response) pair of DNS messages from 1x RTT to 2x RTT. There is no such overhead for a session that is already established; therefore, the overhead of the initial TCP handshake is minimised when the resulting session is used to exchange multiple DNS message pairs over a single session. The extra RTT time for session setup can be represented as the equation (1 + N)/N, where N represents the number of DNS message pairs that utilize the session and the result approaches unity as N increases.
单个DNS事务的三向TCP握手开销很大，将单个（请求、响应）DNS消息对的事务时间从1x RTT增加到2x RTT。对于已经建立的会话，没有这样的开销；因此，当生成的会话用于在单个会话上交换多个DNS消息对时，初始TCP握手的开销最小化。会话设置的额外RTT时间可以表示为等式（1+N）/N，其中N表示利用会话的DNS消息对的数量，并且随着N的增加，结果接近统一。
With increased deployment of DNSSEC and new RR types containing application-specific cryptographic material, there is an increase in the prevalence of truncated responses received over UDP with retries over TCP. The overhead for a DNS transaction over UDP truncated due to RRL is 3x RTT higher than the overhead imposed on the same transaction initiated over TCP.
随着DNSSEC和包含特定于应用程序的加密材料的新RR类型部署的增加，通过UDP接收的截断响应（通过TCP重试）的流行率增加。由于RRL而被截断的UDP上的DNS事务的开销比通过TCP启动的同一事务的开销高3倍RTT。
This document proposes a signalling mechanism between DNS clients and servers that encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time.
本文档提出了DNS客户端和服务器之间的信令机制，该机制通过允许有效管理与TCP传输相关的状态而对DNS事务时间的影响最小，从而鼓励使用长寿命TCP连接。
This mechanism will be of benefit for both stub-resolver and resolver-authoritative TCP connections. In the latter case, the persistent nature of the TCP connection can provide improved defence against attacks including DDoS.
这种机制对存根解析器和解析器权威TCP连接都有好处。在后一种情况下，TCP连接的持久性可以提高对包括DDoS在内的攻击的防御能力。
The reduced overhead of this extension adds up significantly when combined with other EDNS0 extensions, such as [CHAIN-QUERY] and [DNS-over-TLS]. For example, the combination of these EDNS0 extensions make it possible for hosts on high-latency mobile networks to natively and efficiently perform DNSSEC validation and encrypt queries.
当与其他EDNS0扩展（如[CHAIN-QUERY]和[DNS over TLS]）结合使用时，此扩展减少的开销显著增加。例如，这些EDNS0扩展的组合使高延迟移动网络上的主机能够本机高效地执行DNSSEC验证和加密查询。
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]中所述进行解释。
This document specifies a new EDNS0 [RFC6891] option, edns-tcp-keepalive, which can be used by DNS clients and servers to signal a willingness to keep an idle TCP session open to conduct future DNS transactions, with the idle timeout being specified by the server. This specification does not distinguish between different types of DNS client and server in the use of this option.
本文档指定了一个新的EDNS0[RFC6891]选项edns tcp keepalive，DNS客户端和服务器可以使用该选项来表示愿意保持空闲tcp会话打开以进行未来的DNS事务，空闲超时由服务器指定。在使用此选项时，此规范不区分不同类型的DNS客户端和服务器。
[RFC7766] defines an 'idle DNS-over-TCP session' from both the client and server perspective. The idle timeout described here begins when the idle condition is met per that definition and should be reset when that condition is lifted, i.e., when a client sends a message or when a server receives a message on an idle connection.
[RFC7766]从客户端和服务器的角度定义了“通过TCP会话的空闲DNS”。此处描述的空闲超时从满足该定义的空闲条件时开始，并应在解除该条件时重置，即当客户端发送消息或服务器在空闲连接上接收消息时。
The edns-tcp-keepalive option is encoded as follows:
edns tcp keepalive选项的编码如下：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
! OPTION-CODE ! OPTION-LENGTH !
+-------------------------------+-------------------------------+
| TIMEOUT !
+-------------------------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
! OPTION-CODE ! OPTION-LENGTH !
+-------------------------------+-------------------------------+
| TIMEOUT !
+-------------------------------+
where:
哪里：
OPTION-CODE: the EDNS0 option code assigned to edns-tcp-keepalive, 11
选项代码：分配给edns tcp keepalive的EDNS0选项代码，11
OPTION-LENGTH: the value 0 if the TIMEOUT is omitted, the value 2 if it is present;
OPTION-LENGTH：如果省略超时，则值为0；如果存在超时，则值为2；
TIMEOUT: an idle timeout value for the TCP connection, specified in units of 100 milliseconds, encoded in network byte order.
超时：TCP连接的空闲超时值，以100毫秒为单位指定，以网络字节顺序编码。
DNS clients MUST NOT include the edns-tcp-keepalive option in queries sent using UDP transport.
DNS客户端不得在使用UDP传输发送的查询中包含edns tcp keepalive选项。
DNS clients MAY include the edns-tcp-keepalive option in the first query sent to a server using TCP transport to signal their desire to keep the connection open when idle.
DNS客户端可以在使用tcp传输发送到服务器的第一个查询中包含edns tcp keepalive选项，以表明其希望在空闲时保持连接打开。
DNS clients MAY include the edns-tcp-keepalive option in subsequent queries sent to a server using TCP transport to signal their continued desire to keep the connection open when idle.
DNS客户端可以在使用tcp传输发送到服务器的后续查询中包含edns tcp keepalive选项，以表明其在空闲时继续保持连接打开的愿望。
Clients MUST specify an OPTION-LENGTH of 0 and omit the TIMEOUT value.
客户端必须指定长度为0的选项，并忽略超时值。
A DNS client that receives a response using UDP transport that includes the edns-tcp-keepalive option MUST ignore the option.
使用包含edns tcp keepalive选项的UDP传输接收响应的DNS客户端必须忽略该选项。
A DNS client that receives a response using TCP transport that includes the edns-tcp-keepalive option MAY keep the existing TCP session open when it is idle. It SHOULD honour the timeout received in that response (overriding any previous timeout) and initiate close of the connection before the timeout expires.
使用包含edns TCP keepalive选项的TCP传输接收响应的DNS客户端可能会在现有TCP会话空闲时保持其打开状态。它应该遵守响应中接收到的超时（覆盖以前的任何超时），并在超时过期之前启动连接关闭。
A DNS client that receives a response that includes the edns-tcp-keepalive option with a TIMEOUT value of 0 SHOULD send no more queries on that connection and initiate closing the connection as soon as it has received all outstanding responses.
接收到包含超时值为0的edns tcp keepalive选项的响应的DNS客户端不应再发送有关该连接的查询，并在收到所有未完成响应后立即启动关闭连接。
A DNS client that sent a query containing the edns-keepalive-option but receives a response that does not contain the edns-keepalive-option SHOULD assume the server does not support keepalive and behave following the guidance in [RFC7766]. This holds true even if a previous edns-keepalive-option exchange occurred on the existing TCP connection.
发送包含edns keepalive选项的查询但收到不包含edns keepalive选项的响应的DNS客户端应假定服务器不支持keepalive，并按照[RFC7766]中的指导进行操作。即使在现有TCP连接上发生了以前的edns keepalive选项交换，这一点仍然成立。
A DNS server that receives a query using UDP transport that includes the edns-tcp-keepalive option MUST ignore the option.
使用包含edns tcp keepalive选项的UDP传输接收查询的DNS服务器必须忽略该选项。
A DNS server that receives a query using TCP transport that includes the edns-tcp-keepalive option MAY modify the local idle timeout associated with that TCP session if resources permit.
如果资源允许，使用包含edns TCP keepalive选项的TCP传输接收查询的DNS服务器可以修改与该TCP会话相关联的本地空闲超时。
A DNS server that receives a query sent using TCP transport that includes an OPT RR (with or without the edns-tcp-keepalive option) MAY include the edns-tcp-keepalive option in the response to signal the expected idle timeout on a connection. Servers MUST specify the TIMEOUT value that is currently associated with the TCP session. It
接收使用TCP传输发送的查询（包括OPT RR（带或不带edns TCP keepalive选项）的DNS服务器可以在响应中包括edns TCP keepalive选项，以指示连接上的预期空闲超时。服务器必须指定当前与TCP会话关联的超时值。信息技术
is reasonable for this value to change according to local resource constraints. The DNS server SHOULD send an edns-tcp-keepalive option with a timeout of 0 if it deems its local resources are too low to service more TCP keepalive sessions or if it wants clients to close currently open connections.
根据本地资源约束更改此值是合理的。如果DNS服务器认为其本地资源太少，无法服务更多tcp keepalive会话，或者希望客户端关闭当前打开的连接，则应发送超时为0的edns tcp keepalive选项。
Both DNS clients and servers are subject to resource constraints that will limit the extent to which TCP sessions can persist. Effective limits for the number of active sessions that can be maintained on individual clients and servers should be established, either as configuration options or by interrogation of process limits imposed by the operating system. Servers that implement edns-tcp-keepalive should also engage in TCP connection management by recycling existing connections when appropriate, closing connections gracefully, and managing request queues to enable fair use.
DNS客户端和服务器都受到资源限制，这将限制TCP会话可以持续的程度。应建立可在单个客户端和服务器上维护的活动会话数的有效限制，作为配置选项或通过询问操作系统施加的进程限制。实现edns tcp keepalive的服务器还应该参与tcp连接管理，在适当的时候回收现有连接，优雅地关闭连接，并管理请求队列以实现公平使用。
In the event that there is greater demand for TCP sessions than can be accommodated, servers may reduce the TIMEOUT value signalled in successive DNS messages to minimise idle time on existing sessions. This also allows, for example, clients with other candidate servers to query to establish new TCP sessions with different servers in expectation that an existing session is likely to be closed or to fall back to UDP.
如果对TCP会话的需求超过了可容纳的范围，服务器可以减少连续DNS消息中发出的超时值，以最大限度地减少现有会话上的空闲时间。例如，这还允许具有其他候选服务器的客户端查询以与不同的服务器建立新的TCP会话，以期望现有会话可能会关闭或退回到UDP。
Based on TCP session resources, servers may signal a TIMEOUT value of 0 to request clients to close connections as soon as possible. This is useful when server resources become very low or a denial-of-service attack is detected and further maximises the shifting of TIME_WAIT state to well-behaved clients.
基于TCP会话资源，服务器可能会发出超时值为0的信号，以请求客户端尽快关闭连接。当服务器资源变得非常低或检测到拒绝服务攻击时，这非常有用，并进一步最大限度地将等待时间状态转移到行为良好的客户端。
However, it should be noted that RFC 6891 states:
但是，应注意的是，RFC 6891规定：
Lack of presence of an OPT record in a request MUST be taken as an indication that the requestor does not implement any part of this specification and that the responder MUST NOT include an OPT record in its response.
请求中不存在OPT记录必须视为请求者未实施本规范任何部分的指示，且响应者不得在其响应中包含OPT记录。
Since servers must be faithful to this specification even on a persistent TCP connection, it means that (following the initial exchange of timeouts) a server may not be presented with the opportunity to signal a change in the idle timeout associated with a connection if the client does not send any further requests containing EDNS0 OPT RRs. This limitation makes persistent connection handling via an initial idle timeout signal more
由于即使在持久TCP连接上，服务器也必须遵守此规范，这意味着（在初始超时交换之后），如果客户端不发送任何包含EDNS0 OPT RRs的进一步请求，则服务器可能没有机会发出与连接相关联的空闲超时更改的信号。此限制使得通过初始空闲超时信号进行的持久连接处理更加复杂
attractive than a mechanism that establishes default persistence and then uses a connection close signal (in a similar manner to HTTP 1.1 [RFC7230]).
比建立默认持久性然后使用连接关闭信号的机制更有吸引力（与HTTP 1.1[RFC7230]的方式类似）。
If a client includes the edns-tcp-keepalive option in the first query, it SHOULD include an EDNS0 OPT RR periodically in any further messages it sends during the TCP session. This will increase the chance of the client being notified should the server modify the timeout associated with a session. The algorithm for choosing when to do this is out of scope of this document and is left up to the implementor and/or operator.
如果客户机在第一次查询中包含edns tcp keepalive选项，则它应在tcp会话期间发送的任何其他消息中定期包含EDNS0 OPT RR。如果服务器修改与会话相关联的超时，这将增加通知客户端的机会。选择何时执行此操作的算法超出了本文档的范围，由实现者和/或操作员决定。
DNS clients and servers MAY close a TCP session at any time in order to manage local resource constraints. The algorithm by which clients and servers rank active TCP sessions in order to determine which to close is not specified in this document.
DNS客户端和服务器可以随时关闭TCP会话以管理本地资源约束。本文档中未指定客户端和服务器排列活动TCP会话以确定关闭哪个会话的算法。
Many paths between DNS clients and servers suffer from poor hygiene, limiting the free flow of DNS messages that include particular EDNS0 options or messages that exceed a particular size. A fallback strategy similar to that described in [RFC6891], Section 6.2.2 SHOULD be employed to avoid persistent interference due to non-clean paths.
DNS客户端和服务器之间的许多路径的卫生状况不佳，限制了包括特定EDNS0选项或超过特定大小的消息的DNS消息的自由流动。应采用与[RFC6891]第6.2.2节中所述类似的回退策略，以避免由于非干净路径造成的持续干扰。
DNS servers of various types are commonly deployed using anycast [RFC4786].
各种类型的DNS服务器通常使用选播[RFC4786]进行部署。
Changes in network topology between clients and anycast servers may cause disruption to TCP sessions making use of edns-tcp-keepalive more often than with TCP sessions that omit it, since the TCP sessions are expected to be longer lived. It might be possible for anycast servers to avoid disruption due to topology changes by making use of TCP multipath [RFC6824] to anchor the server side of the TCP connection to an unambiguously unicast address.
客户端和选播服务器之间网络拓扑的更改可能会导致TCP会话中断，使用edns TCP keepalive的次数比使用省略它的TCP会话的次数要多，因为TCP会话的寿命预计会更长。通过使用TCP多路径[RFC6824]将TCP连接的服务器端锚定到明确的单播地址，anycast服务器可以避免由于拓扑更改而造成的中断。
It is RECOMMENDED that DNS intermediaries that terminate TCP connections implement edns-tcp-keepalive. An intermediary that does not implement edns-tcp-keepalive but sits between a client and server that both support edns-tcp-keepalive might close idle connections unnecessarily.
建议终止TCP连接的DNS中介实现edns TCP keepalive。不实现edns tcp keepalive但位于同时支持edns tcp keepalive的客户端和服务器之间的中介可能会不必要地关闭空闲连接。
The edns-tcp-keepalive option can potentially be abused to request large numbers of long-lived sessions in a quick burst. When a DNS server detects abusive behaviour, it SHOULD immediately close the TCP connection and free the resources used.
edns tcp keepalive选项可能被滥用，以在快速突发中请求大量长期会话。当DNS服务器检测到滥用行为时，它应该立即关闭TCP连接并释放所使用的资源。
Servers could choose to monitor client behaviour with respect to the edns-tcp-keepalive option to build up profiles of clients that do not honour the specified timeout.
服务器可以选择监控有关edns tcp keepalive选项的客户端行为，以建立不遵守指定超时的客户端的配置文件。
Readers are advised to familiarise themselves with the security considerations outlined in [RFC7766]
建议读者熟悉[RFC7766]中概述的安全注意事项
IANA has assigned an EDNS0 option code for the edns-tcp-keepalive option from the "DNS EDNS0 Option Codes (OPT)" registry as follows:
IANA已从“DNS EDNS0选项代码（OPT）”注册表为edns tcp keepalive选项分配了EDNS0选项代码，如下所示：
+-------+--------------------+----------+-----------+
| Value | Name | Status | Reference |
+-------+--------------------+----------+-----------+
| 11 | edns-tcp-keepalive | Standard | RFC 7828 |
+-------+--------------------+----------+-----------+
+-------+--------------------+----------+-----------+
| Value | Name | Status | Reference |
+-------+--------------------+----------+-----------+
| 11 | edns-tcp-keepalive | Standard | RFC 7828 |
+-------+--------------------+----------+-----------+
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[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>.
[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>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, <http://www.rfc-editor.org/info/rfc7766>.
[RFC7766]Dickinson，J.，Dickinson，S.，Bellis，R.，Mankin，A.，和D.Wessels，“TCP上的DNS传输-实施要求”，RFC 7766，DOI 10.17487/RFC7766，2016年3月<http://www.rfc-editor.org/info/rfc7766>.
[CHAIN-QUERY] Wouters, P., "Chain Query requests in DNS", Work in Progress, draft-ietf-dnsop-edns-chain-query-07, February 2016.
[CHAIN-QUERY]Wouters，P.，“DNS中的链查询请求”，正在进行的工作，草稿-ietf-dnsop-edns-CHAIN-QUERY-072016年2月。
[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-09, March 2016.
[DNS over TLS]Hu，Z.，Zhu，L.，Heidemann，J.，Mankin，A.，Wessels，D.，和P.Hoffman，“DNS over TLS规范”，正在进行的工作，草案-ietf-dprive-DNS-over-TLS-092016年3月。
[fragmentation-considered-poisonous] Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous", arXiv: 1205.4011, May 2012, <http://arxiv.org/abs/1205.4011>.
[碎片被认为有毒]Herzberg，A.和H.Shulman，“碎片被认为有毒”，arXiv:1205.401112012年5月<http://arxiv.org/abs/1205.4011>.
[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>.
[RRL] 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>.
[RRL]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>.
Acknowledgements
致谢
The authors acknowledge the contributions of Jinmei TATUYA and Mark Andrews. Thanks to Duane Wessels for detailed review and the many others who contributed to the mailing list discussion.
作者感谢Jinmei TATUYA和Mark Andrews的贡献。感谢Duane Wessels的详细评论以及其他许多参与邮件列表讨论的人。
Authors' Addresses
作者地址
Paul Wouters Red Hat
保罗·沃特斯红帽
Email: pwouters@redhat.com
Email: pwouters@redhat.com
Joe Abley Dyn, Inc. 103-186 Albert Street London, ON N6A 1M1 Canada
Joe Abley Dyn公司，地址：加拿大伦敦艾伯特街103-186号，邮编：N6A 1M1
Phone: +1 519 670 9327
Email: jabley@dyn.com
Phone: +1 519 670 9327
Email: jabley@dyn.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