Internet Engineering Task Force (IETF) R. Bellis
Request for Comments: 5966 Nominet UK
Updates: 1035, 1123 August 2010
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Bellis
Request for Comments: 5966 Nominet UK
Updates: 1035, 1123 August 2010
Category: Standards Track
ISSN: 2070-1721
DNS Transport over TCP - Implementation Requirements
TCP上的DNS传输-实现要求
Abstract
摘要
This document updates the requirements for the support of TCP as a transport protocol for DNS implementations.
本文档更新了支持TCP作为DNS实现传输协议的要求。
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/rfc5966.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5966.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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. Terminology Used in This Document . . . . . . . . . . . . . . . 3
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Transport Protocol Selection . . . . . . . . . . . . . . . . . 4
5. Connection Handling . . . . . . . . . . . . . . . . . . . . . . 5
6. Response Reordering . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology Used in This Document . . . . . . . . . . . . . . . 3
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Transport Protocol Selection . . . . . . . . . . . . . . . . . 4
5. Connection Handling . . . . . . . . . . . . . . . . . . . . . . 5
6. Response Reordering . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Most DNS [RFC1034] transactions take place over UDP [RFC0768]. TCP [RFC0793] is always used for zone transfers and is often used for messages whose sizes exceed the DNS protocol's original 512-byte limit.
大多数DNS[RFC1034]事务通过UDP[RFC0768]进行。TCP[RFC0793]始终用于区域传输，通常用于大小超过DNS协议原始512字节限制的消息。
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 failure to support TCP restricts interoperability and limits 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协议实现的必要部分。
Whilst this document makes no specific recommendations to operators of DNS servers, it should be noted that failure to support TCP (or the blocking of DNS over TCP at the network layer) may result in resolution failure and/or application-level timeouts.
虽然本文档未向DNS服务器的运营商提出具体建议，但应注意，未能支持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]中所述进行解释。
In the absence of EDNS0 (Extension Mechanisms for DNS 0) (see below), the normal behaviour of any DNS server needing 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的扩展机制）（见下文）的情况下，需要发送超过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 DNS Security (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.
DNS安全性（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 (EDNS0 [RFC2671]) 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的扩展机制（EDNS0[RFC2671]）。这些扩展可用于指示客户端准备接收大于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 some 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的标准化机制已被发现不充分。
All general-purpose DNS implementations MUST support both UDP and TCP transport.
所有通用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 their interoperability with their own clients and with upstream servers.
o 存根解析器实现（例如，操作系统的DNS解析库）必须支持TCP，否则会限制它们与自己的客户端和上游服务器的互操作性。
Stub resolver implementations MAY omit support for TCP when specifically designed for deployment in restricted environments where truncation can never occur or where truncated DNS responses are acceptable.
存根解析器实现可能会忽略对TCP的支持，因为它是专门为在永远不会发生截断或可以接受截断DNS响应的受限环境中部署而设计的。
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查询。
That requirement is hereby relaxed. A resolver SHOULD send a UDP query first, but MAY elect to send a TCP query instead if it has good reason to expect the response would be truncated if it were sent over UDP (with or without EDNS0) or for other operational reasons, in particular, if it already has an open TCP connection to the server.
这项要求特此放宽。冲突解决程序应首先发送UDP查询，但如果有充分的理由认为通过UDP（有或没有EDNS0）发送响应会被截断，或者由于其他操作原因，特别是如果它已经与服务器建立了开放的TCP连接，则可能选择发送TCP查询。
Section 4.2.2 of [RFC1035] says:
[RFC1035]第4.2.2节规定：
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 a graceful close.
如果服务器需要关闭休眠连接以回收资源，则应等待连接空闲两分钟左右。特别是，服务器应该允许在单个连接上执行SOA和AXFR请求序列（开始刷新操作）。由于服务器无论如何都无法回答查询，因此可以使用单边关闭或重置来代替优雅关闭。
Other more modern protocols (e.g., HTTP [RFC2616]) have support for persistent TCP connections and operational experience has shown that long timeouts can easily cause resource exhaustion and poor response under heavy load. Intentionally opening many connections and leaving them dormant can trivially create a "denial-of-service" attack.
其他更现代的协议（例如HTTP[RFC2616]）支持持久TCP连接，运营经验表明，长时间超时很容易导致资源耗尽和重负载下的响应差。故意打开许多连接并使其处于休眠状态很容易造成“拒绝服务”攻击。
It is therefore RECOMMENDED that the default application-level idle period should be of the order of seconds, but no particular value is specified. In practise, the idle period may vary dynamically, and servers MAY allow dormant connections to remain open for longer periods as resources permit.
因此，建议默认应用程序级空闲时间应为秒级，但未指定特定值。实际上，空闲时间可能会动态变化，服务器可能允许休眠连接在资源允许的情况下保持更长时间的打开状态。
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. Similarly, servers MAY impose limits on the number of concurrent TCP connections being handled for any particular client.
为了降低服务器意外过载的风险，DNS客户端必须注意尽量减少与任何单个服务器的并发TCP连接数。类似地，服务器可能会对为任何特定客户机处理的并发TCP连接的数量施加限制。
Further recommendations for the tuning of TCP stacks to allow higher throughput or improved resiliency against denial-of-service attacks are outside the scope of this document.
有关调整TCP堆栈以提高吞吐量或增强抵御拒绝服务攻击的弹性的进一步建议不在本文档的范围内。
RFC 1035 is ambiguous on the question of whether TCP queries 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. Client resolvers MUST be able to process responses that arrive in a different order to that in which the requests were sent, regardless of the transport protocol in use.
为避免将来产生疑问，澄清了该要求。无论使用何种传输协议，客户端解析程序都必须能够处理以不同于发送请求的顺序到达的响应。
Some DNS server operators have expressed concern that wider use of DNS over TCP will expose them to a higher risk of denial-of-service (DoS) attacks.
一些DNS服务器运营商表示担心，通过TCP更广泛地使用DNS将使他们面临更高的拒绝服务（DoS）攻击风险。
Although there is a higher risk of such 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攻击的技术已经有了很大的改进。
At the time of writing, the vast majority of Top Level Domain (TLD) authority servers and all of the root name servers support TCP and the author knows of no evidence to suggest that TCP-based DoS attacks against existing DNS infrastructure are commonplace.
在撰写本文时，绝大多数顶级域（TLD）授权服务器和所有根名称服务器都支持TCP，并且作者不知道有证据表明针对现有DNS基础设施的基于TCP的DoS攻击是常见的。
That notwithstanding, readers are advised to familiarise themselves with [CPNI-TCP].
尽管如此，建议读者熟悉[CPNI-TCP]。
Operators of recursive servers should ensure that they only accept connections from expected clients, and do not accept them from unknown sources. In the case of UDP traffic, this will help protect against reflector 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.
递归服务器的操作员应该确保他们只接受来自预期客户端的连接，而不接受来自未知源的连接。在UDP通信的情况下，这将有助于防止反射器攻击[RFC5358]，在TCP通信的情况下，它将防止未知客户端耗尽服务器对并发连接数的限制。
The author would like to thank the document reviewers from the DNSEXT Working Group, and in particular, George Barwood, Alex Bligh, Alfred Hoenes, Fernando Gont, Olafur Gudmondsson, Jim Reid, Paul Vixie, and Nicholas Weaver.
作者要感谢DNSEXT工作组的文件审查员，特别是乔治·巴伍德、亚历克斯·布莱、阿尔弗雷德·霍恩斯、费尔南多·冈特、奥拉弗尔·古德蒙德森、吉姆·里德、保罗·维克西和尼古拉斯·韦弗。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[CPNI-TCP] CPNI, "Security Assessment of the Transmission Control Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/ tn-03-09-security-assessment-TCP.pdf>.
[CPNI-TCP]CPNI，“传输控制协议（TCP）的安全评估”，2009年<http://www.cpni.gov.uk/Docs/ tn-03-09-security-assessment-TCP.pdf>。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
[RFC5155]Laurie，B.，Sisson，G.，Arends，R.，和D.Blacka，“DNS安全（DNSSEC）哈希认证拒绝存在”，RFC 51552008年3月。
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, October 2008.
[RFC5358]Damas，J.和F.Neves，“防止在反射器攻击中使用递归名称服务器”，BCP 140，RFC 5358，2008年10月。
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009.
[RFC5625]Bellis，R.，“DNS代理实施指南”，BCP 152，RFC 56252009年8月。
Author's Address
作者地址
Ray Bellis Nominet UK Edmund Halley Road Oxford OX4 4DQ United Kingdom
Ray Bellis Nominet UK Edmund Halley Road OX4 4DQ英国牛津大学
Phone: +44 1865 332211
EMail: ray.bellis@nominet.org.uk
URI: http://www.nominet.org.uk/
Phone: +44 1865 332211
EMail: ray.bellis@nominet.org.uk
URI: http://www.nominet.org.uk/