RFC7766：DNS Transport over TCP - Implementation Requirements，March 2016
梗概
本文档规定了支持 TCP 作为 DNS 实现的传输协议的要求，并提供了与 DNS-over-UDP 性能相当的 DNS-over-TCP 性能指南。本文档废弃了 RFC 5966，因此更新了 RFC 1035 和 RFC 1123。
本备忘录的状态
这是一份 Internet 标准跟踪文档。
本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已获互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 5741 的第 2 节。
有关本文档当前状态、勘误表以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc7766。
版权声明
版权所有 (c) 2016 IETF Trust 和文件作者。版权所有。
本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文件发布之日有效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且按照简化 BSD 许可中的说明在不保证的情况下提供。
1、 简介
大多数 DNS [RFC1034] 事务通过 UDP [RFC768] 进行。TCP [RFC793] 始终用于全区域传输（使用 AXFR），并且通常用于大小超过 DNS 协议原始 512 字节限制的消息。DNS 安全 (DNSSEC) 和 IPv6 的不断部署增加了响应大小，因此也增加了 TCP 的使用。增加 TCP 使用的需求也受到它提供的防止地址欺骗的保护以及因此在反射/放大攻击中利用 DNS 的驱动。它现在广泛用于响应率限制 [RRL1] [RRL2]。此外，最近关于 [DNS-over-TLS] 等 DNS 隐私解决方案的工作是重新审视 DNS-over-TCP 要求的另一个动机。
[RFC1123] 的第 6.1.3.2 节规定：
“DNS 解析器和递归服务器必须支持 UDP，并且应该支持 TCP，以发送（非区域传输）查询。”
然而，一些实现者认为上面引用的文本意味着 TCP 支持是 DNS 协议的一个可选特性。
大多数 DNS 服务器运营商已经支持 TCP，并且大多数软件实现的默认配置是支持 TCP。本文档的主要受众是那些对 TCP 的有限支持限制互操作性并阻碍新 DNS 功能部署的实施者。
因此，本文档更新了核心 DNS 协议规范，以便对 TCP 的支持从此成为完整 DNS 协议实现的必需部分。
增加 TCP 的使用（见附录 A）有几个优点和缺点，以及需要考虑的实施细节。本文档解决了这些问题，并将 TCP 作为 DNS 的有效传输替代方案。它扩展了 [RFC5966] 的内容，并从 DNS 和其他 Internet 协议中 TCP 的研究、开发和实施中吸取了额外的考虑和经验教训。
虽然本文档没有对 DNS 服务器的运营商提出具体要求，但它确实为运营商提供了一些建议，以帮助确保在其服务器和网络上对 TCP 的支持是最佳的。需要注意的是，不支持 TCP（或网络层 TCP 上的 DNS 阻塞）可能会导致解析失败和/或应用程序级超时。
2、 需求术语
本文档中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应该”、“不应”、“推荐”、“可以”和“可选”是按照 [RFC2119] 中的描述进行解释。
3、 术语
Persistent connection：持久连接，服务器在发送第一个响应后没有关闭，客户端收到第一个响应后也没有关闭的 TCP 连接。
Connection Reuse ：连接复用，通过单个 TCP 连接发送多个查询和响应。
Idle DNS-over-TCP session：空闲DNS-over-TCP会话，客户端和服务器以不同的方式查看应用程序级别的空闲。当 DNS 客户端没有待发送的查询并且没有未完成的响应时，DNS 客户端认为已建立的 DNS-over-TCP 会话处于空闲状态。当 DNS 服务器发送了对它在该连接上收到的所有查询的响应时，它认为已建立的 DNS-over-TCP 会话处于空闲状态。
Pipelining：流水线，通过单个 TCP 连接发送多个查询和响应，但在发送另一个查询之前不等待任何未完成的回复。
Out-of-Order Processing：无序处理，同时处理查询并在单个响应可用时立即返回，可能是无序的。这很可能发生在递归服务器中；但是，在具有不同后端数据存储的权威服务器中是可能的。
4、 讨论
在没有 EDNS0（DNS 0 的扩展机制 [RFC6891]；见下文）的情况下，任何需要发送超过 512 字节限制的 UDP 响应的 DNS 服务器的正常行为是服务器截断响应，以便它符合该限制，然后在响应标头中设置 TC 标志。当客户端收到这样的响应时，它会将 TC 标志作为它应该通过 TCP 重试的指示。
RFC 1123 还说：
“同样清楚的是，未来定义的一些新 DNS 记录类型将包含超过适用于 UDP 的 512 字节限制的信息，因此需要 TCP。因此，解析器和域名服务器现在应该实现 TCP 服务作为 UDP 的备份，并且知道它们将来会需要 TCP 服务。”
DNSSEC [RFC4033] 的现有部署表明，在 512 字节边界处截断现在很常见。例如，来自使用 NextSECure 3 (NSEC3) [RFC5155] 的 DNSSEC 签名区域的不存在域 (NXDOMAIN) (RCODE == 3) 响应几乎总是大于 512 字节。
自从编写了 DNS 的原始核心规范以来，就引入了 DNS 的扩展机制。这些扩展可用于指示客户端已准备好接收大于 512 字节的 UDP 响应。从 EDNS0 兼容客户端接收请求的 EDNS0 兼容服务器可以发送 UDP 数据包，直到该客户端宣布的缓冲区大小而不会截断。
但是，超过路径 MTU 大小的 UDP 数据包的传输会导致 IP 数据包分片，这在许多情况下被发现是不可靠的。许多防火墙通常会阻止分片的 IP 数据包，并且有些防火墙没有实施重组分片数据包所需的算法。更糟糕的是，一些网络设备故意拒绝处理包含 EDNS0 选项的 DNS 数据包。与 UDP 传输和数据包大小有关的其他问题在 [RFC5625] 中讨论。
在 Internet 核心中最常见的 MTU 约为 1500 字节，即使是 DNSSEC 签名的响应也经常超过这个限制。
RFC 1123 中预期的未来已经到来，并且发现可能已经解决了数据包大小问题的唯一标准化的基于 UDP 的机制是不够的。
5、 传输协议选择
[RFC1123] 的第 6.1.3.2 节已更新：所有通用 DNS 实现必须同时支持 UDP 和 TCP 传输。
“权威服务器实现必须支持 TCP，以便它们不会将响应的大小限制为适合单个 UDP 数据包的内容。”
“递归服务器（或转发器）实现必须支持 TCP，以便它们不会阻止来自支持 TCP 的服务器的大型响应到达支持 TCP 的客户端。”
“存根解析器实现（例如，操作系统的 DNS 解析库）必须支持 TCP，否则会限制它们自己的客户端和上游服务器之间的互操作性。”
关于何时使用 UDP 或 TCP 的选择，RFC 1123 的第 6.1.3.2 节还说：
“发送非区域传输查询的 DNS 解析器或服务器必须首先发送 UDP 查询。”
特此放宽这一要求。存根解析器和递归解析器可以根据本地操作原因选择发送 TCP 或 UDP 查询。在发送任何 UDP 查询之前可以使用 TCP。如果解析器已经有一个开放的 TCP 连接到服务器，它应该复用这个连接。从本质上讲，TCP 应该被视为 UDP 的有效替代传输，而不是纯粹的重试选项。
此外，请注意，所有递归和权威服务器必须使用与查询到达时相同的传输方式发送响应。在 TCP 的情况下，这也必须是同一个连接。
6、 连接处理
6.1、 目前的做法
[RFC1035] 的第 4.2.2 节说：
“服务器应假定客户端将启动连接关闭，并应延迟关闭其连接端，直到所有未完成的客户端请求都得到满足。”
“如果服务器需要关闭一个休眠连接来回收资源，它应该等到连接空闲大约两分钟。特别是，服务器应允许在单个连接上进行 SOA 和 AXFR 请求序列（开始刷新操作）。由于服务器无论如何都无法回答查询，因此可以使用单方面关闭或重置来代替正常关闭。”
其他更现代的协议（例如，HTTP/1.1 [RFC7230]、HTTP/2 [RFC7540]）默认支持所有请求的持久 TCP 连接。然后通常通过来自一方的“连接关闭”信号关闭连接。
[RFC1035] 中的描述很清楚，服务器应该将连接视为持久连接（尤其是在接收到 SOA 之后），但不幸的是，它没有提供足够的细节来明确解释除 SOA 之外的查询的客户端行为。此外，DNS 还没有用于连接超时或关闭的信号机制，尽管已经提出了一些。
6.1.1、 客户端
目前在任何 RFC 中都没有关于 DNS 客户端何时应关闭 TCP 连接的明确指导，也没有关于 DNS 客户端空闲超时的具体建议。但是，在撰写本文时，客户端通常会在发送单个请求后关闭 TCP 连接（SOA/AXFR 情况除外）。
6.1.2、 服务器
许多 DNS 服务器实现使用较长的固定空闲超时，并默认使用少量 TCP 连接。它们还提供很少的 TCP 连接管理选项。这样做的缺点包括：
“运营经验表明，长时间的服务器超时很容易导致资源枯竭，在重负载下响应不佳。”
“故意打开许多连接并让它们闲置很容易造成 TCP 拒绝服务 (DoS) 攻击，因为许多 DNS 服务器没有能力通过修改其空闲超时或其他连接管理策略来防御这种情况。”
“少量客户端同时尝试使用具有非零空闲超时的持久连接到此类服务器可能会无意中导致相同的 DoS 问题。”
请注意，此 DoS 仅在 TCP 服务上。但是，在这些情况下，它不仅会影响出于操作原因希望使用 TCP 进行查询的客户端，还会影响所有在收到 TC=1 标志后选择从 UDP 回退到 TCP 的客户端。
6.2、 建议
以下部分包括旨在使 DNS-over-TCP 实施更加一致和可扩展的建议。
6.2.1、 连接复用
DNS over TCP 的一个明显缺点是增加了连接建立延迟，通常等于一个 RTT。为了分摊连接建立成本，客户端和服务器都应该通过在单个持久 TCP 连接上发送多个查询和响应来支持连接复用。
当通过 TCP 连接发送多个查询时，客户端不得在该连接上复用正在进行的查询的 DNS 消息 ID 以避免消息 ID 冲突。如果服务器可能正在执行乱序处理，这一点尤其重要（参见第 7 节）。
6.2.1.1、 查询流水线
由于历史上 TCP 主要用于区域传输和截断响应，因此没有现有的 RFC 讨论通过 TCP 连接流水线化 DNS 查询的想法。
为了达到与 UDP 同等的性能，DNS 客户端应该管道他们的查询。当 DNS 客户端向服务器发送多个查询时，它不应该在发送下一个查询之前等待未完成的回复。在考虑发送特定查询的时间时，客户端应该同等对待 TCP 和 UDP。
DNS 服务器很可能需要同时处理流水线查询，并通过 TCP 发送无序响应，以提供 UDP 传输可能的性能水平。如果 TCP 性能很重要，客户端可能会发现使用服务器处理时间作为服务器和传输选择算法的输入很有用。
DNS 服务器（尤其是递归的）必须期望接收流水线查询。服务器应该同时处理 TCP 查询，就像处理 UDP 一样。服务器应该回答所有流水线查询，即使它们是快速连续收到的。第 7 节介绍了对流水线查询的响应的处理。
6.2.2、 并发连接
为了减轻服务器意外过载的风险，DNS 客户端必须注意尽量减少与任何单个服务器建立的并发 TCP 连接的数量。建议对于任何给定的客户端/服务器交互，对于常规查询，一个用于区域传输的连接，一个用于在 TCP 之上使用的每个协议（例如，如果解析器使用TLS）。但是，请注意，出于操作原因（例如，支持多个区域的并发传输），具有许多繁忙区域的某些主要/次要配置可能需要使用多个 TCP 连接进行区域传输。
同样，服务器可以对任何特定客户端 IP 地址或子网处理的并发 TCP 连接数施加限制。这些限制应该比上面的客户端指南宽松得多，因为服务器不知道，例如，如果客户端 IP 地址属于单个客户端，是否是单个机器上的多个解析器，或者是执行网络的设备后面的多个客户端地址转换 (NAT)。
6.2.3、 空闲超时
为了减轻服务器意外过载的风险，DNS 客户端必须注意尽量减少与任何单个服务器建立的 DNS-over-TCP 会话的空闲时间。DNS 客户端应该关闭空闲会话的 TCP 连接，除非使用其他一些信号机制建立了空闲超时，例如 [edns-tcp-keepalive]。
为了降低意外服务器过载的风险，建议默认服务器应用程序级别的空闲时间大约为秒，但没有指定特定值。在实践中，空闲时间可以动态变化，服务器可以允许空闲连接在资源允许的情况下保持打开更长时间。对于正常操作，建议至少几秒钟的超时，以支持那些期望 SOA 和 AXFR 请求序列在 [RFC1035] 中最初指定的单个连接上进行的客户端。服务器在承受重负载或受到攻击时可以使用零超时。
通过 TCP 传递的 DNS 消息可能会在多个段中到达。在接收到单个段后重置其空闲超时的 DNS 服务器可能容易受到“慢读攻击”的攻击。出于这个原因，服务器应该在收到完整的 DNS 消息时重置空闲超时，而不是在收到 DNS 消息的任何部分时。
6.2.4、 拆除
在正常操作下，DNS 客户端通常会在空闲连接上启动连接关闭；但是，如果超出本地策略设置的空闲超时，DNS 服务器可以关闭连接。此外，在防御攻击或系统故障/重启等异常情况下，任何一端都可以关闭连接。
如果连接在收到所有未完成的响应之前关闭，DNS 客户端应该重试未回答的查询。本文档中没有指定具体的重试算法。
如果 DNS 服务器在发送所有未决响应之前发现 DNS 客户端已关闭 TCP 会话（或会话已被中断），则服务器不得尝试发送这些响应。当然，DNS 服务器可以缓存这些响应。
7、 响应重新排序
RFC 1035 在 TCP 响应是否可以重新排序的问题上模棱两可——唯一相关的文本在第 4.2.1 节中，它与 UDP 相关：
“查询或其响应可能会被网络重新排序，或者通过域名服务器中的处理来重新排序，因此解析器不应依赖于它们按顺序返回。”
为避免将来产生疑问，此要求已明确。建议权威服务器和递归解析器支持并行准备响应并无序发送它们，而不管使用的传输协议如何。存根和递归解析器必须能够处理以不同于发送请求的顺序到达的响应，而不管使用的传输协议如何。
为了达到与 UDP 同等的性能，递归解析器应该并行处理 TCP 查询，并在它们可用时立即返回单个响应，可能是乱序的。
由于流水线响应可能会乱序到达，客户端必须使用消息 ID 将响应与同一 TCP 连接上的未完成查询匹配。如果响应包含问题部分，则客户端必须匹配 QNAME、QCLASS 和 QTYPE 字段。客户未能正确匹配对未决查询的响应可能会对互操作性产生严重后果。
8、 TCP报文长度字段
DNS 客户端和服务器应该同时将两个八位字节长度字段和由该长度字段描述的消息传递给 TCP 层（例如，在单个“写入”系统调用中），以使所有数据将在单个 TCP 段中传输。这是为了提高效率和避免由于某些 DNS 服务器实现在从 TCP 层读取数据时表现不佳（由于以前的文档中缺乏明确性）而导致的问题。例如，如果来自 TCP 层的第一次“读取”不包含长度字段和整个消息，则某些 DNS 服务器实现可能会中止 TCP 会话。
澄清一下，DNS 服务器不能仅仅因为从 TCP 层“读取”的第一个“读取”不包含整个 DNS 消息而关闭连接，并且服务器应该应用第 6.2.3 节中指定的连接超时。
9、 TCP 快速打开
本部分是非规范性的。
TCP 快速打开 (TFO) [RFC7413] 允许在 SYN 数据包中携带数据，从而降低重新打开 TCP 连接的成本。与标准 TCP 相比，它还最多可节省一个 RTT。
TFO 通过使用服务器提供的 cookie 减轻了在 SYN 中发送数据所固有的安全漏洞，尤其是在可能发生放大攻击的 DNS 等系统上。TFO 客户端在新连接开始时在初始 SYN 数据包中请求服务器 cookie。服务器在其 SYN-ACK 中返回一个 cookie。客户端缓存 cookie 并在打开与同一服务器的后续连接时复用它。
cookie 由客户端的 TCP 堆栈（内核）存储，并在客户端或服务器进程重新启动时保持不变。TFO 也优雅地回退到常规 TCP 握手。
在启用 TFO 时，利用 IP 任播 [RFC4786] 的 DNS 服务可能需要采取额外的步骤。来自 [RFC7413]：
“接受对同一服务器 IP 地址的连接请求的负载平衡器后面的服务器应使用相同的密钥，以便它们为特定客户端 IP 地址生成相同的快速打开 cookie。否则，客户端可能会通过连接获得不同的 cookie；它的快速开放尝试将退回到常规的 3WHS。”
当 DNS-over-TCP 是 DNS 私有交换的传输时，如在 [DNS-over-TLS] 中，实施者需要了解 TFO 并确保需要保护的数据（例如用于 DNS 查询的数据）不会意外清运。请参阅 [DNS-over-TLS] 进行讨论。
10、 安全注意事项
一些 DNS 服务器运营商表示担心，更广泛地推广和使用基于 TCP 的 DNS 将使他们面临更高的 TCP 拒绝服务攻击风险（包括意外和故意）。
尽管针对启用 TCP 的服务器的某些特定攻击的风险较高，但自从首次设计 DNS 以来，在网络级别缓解 DoS 攻击的技术已经有了很大的改进。
建议读者熟悉 [CPNI-TCP]，这是一种 TCP 安全评估，详细介绍了已知的 TCP 攻击和对策，并参考了有关该主题的大多数相关 RFC。
为了降低 DoS 攻击的风险，建议 DNS 服务器参与 TCP 连接管理。这可能包括维护现有连接的状态、复用现有连接以及控制请求队列以实现公平使用。提供可配置的连接管理选项可能是有利的，例如：
** TCP 连接总数
** 每个源 IP 地址或子网的最大 TCP 连接数
** TCP 连接空闲超时
** 每个 TCP 连接的最大 DNS 事务数
** 最大 TCP 连接持续时间
没有为这些参数推荐特定值。
建议操作员熟悉操作系统 TCP 堆栈中可用的配置和调整参数。但是，关于此的详细建议超出了本文档的范围。
建议递归服务器的操作员确保他们只接受来自预期客户端的连接（例如，通过使用访问控制列表ACL）并且不接受来自未知来源的连接。在 UDP 流量的情况下，这将有助于防止反射攻击 [RFC5358]；在 TCP 流量的情况下，它将防止未知客户端耗尽服务器对并发连接数的限制。
11、 参考文献
11.1、 规范性参考
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <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>. [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>. [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>. [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>. [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>. [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>. [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>. [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>. [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>. [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, <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>. [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>. [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>. [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>.
11.2、 参考资料
[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>. [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>. [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. [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. [fragmentation-considered-poisonous] Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous", May 2012, <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>. [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>. [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>. [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>. [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/>.
附录A、 将TCP用于DNS的优缺点总结
TCP 握手通常可以防止地址欺骗，因此可以防止UDP的反射/放大攻击的困扰。
与 UDP 相比，IP 分片对于 TCP 来说不是问题。TCP 堆栈通常实现路径 MTU 发现，因此它们可以避免 TCP 段的 IP 分片。另一方面，UDP 不提供重组；这意味着超过路径MTU大小的数据报必须经历分片[RFC5405]。众所周知，中间设备会阻止IP片段，从而导致超时并强制客户端实现“寻找”网络路径支持的 EDNS0 回复大小值。此外，碎片可能会导致缓存中毒 [fragmentation-considered-poisonous]。
与 UDP 查询相比，TCP 设置需要额外的 RTT。设置成本可以通过复用连接、流水线查询和启用 TCP 快速打开来分摊。
TCP 对客户端和服务器施加了额外的状态保持要求。TCP Fast Open 的使用降低了关闭和重新打开 TCP 连接的成本。
由于路由更改，与任播服务器的长期 TCP 连接可能会中断。使用 TCP 进行 DNS 的客户端需要始终准备好重新建立连接或以其他方式重试未完成的查询。多路径 TCP [RFC6824] 也可能允许服务器将连接从任播地址移交给单播地址。
今天有许多“中间设备”在使用通过端口 53 [RFC5625] 干扰 TCP。本文档没有提出任何解决方案，只是明确说明 TCP 是 DNS 的有效传输方式，并且支持它是所有实现的要求。
关于面向连接的 DNS 更深入的讨论可以在其他地方找到 [Connection-Oriented-DNS]。
附录B、 对RFC 5966的更改
本文档废弃了 [RFC5966] 并且在几个方面与它不同。下面概述了实施者应注意的最重要的更改/更新。
1. 添加了术语部分（第 3 部分），定义了几个新概念。
2. 第 5 节的第 3 段将 TCP 与 UDP 置于比 RFC 5966 更平等的地位。例如，它指出：
1. TCP 可以在发送任何 UDP 查询之前使用。
2. TCP 应该被认为是 UDP 的有效替代传输，而不是纯粹的后备选项。
3. 第 6.2.1 节增加了一个新的建议，即应该支持 TCP 连接复用。
4. 第 6.2.1.1 节添加了一条新建议，即 DNS 客户端应该管道其查询，并且 DNS 服务器应该同时处理管道查询。
5. 第 6.2.2 节添加了关于客户端/服务器交互的 TCP 连接数量和使用的新建议。
6. 第 6.2.3 节添加了一条新建议，即 DNS 客户端应该关闭空闲会话，除非使用信令机制。
7. 第 7 节阐明建议服务器并行准备 TCP 响应并无序发送响应。它还阐明了客户端应如何匹配 TCP 查询和响应。
8. 第 8 节添加了关于 DNS 客户端和服务器应如何处理 TCP 消息的 2 字节消息长度字段的新建议。
9. 第 9 节增加了关于 TCP Fast Open 使用的非规范性讨论。
10. 第 10 节添加了有关 DoS 缓解技术的新建议。
致谢
作者要感谢 Francis Dupont 和 Paul Vixie 的详细评论，以及 Andrew Sullivan、Tony Finch、Stephane Bortzmeyer、Joe Abley、Tatuya Jinmei 以及为邮件列表讨论做出贡献的许多其他人。此外，作者感谢 Liang Zhu、Zi Hu 和 John Heidemann 对 DNS-over-TCP 的广泛讨论和代码，以及 Lucie Guiraud 和 Danny McPherson 审阅了本文档的早期草稿版本。我们还要感谢所有为 RFC 5966 做出贡献的人。
