RFC9210：DNS Transport over TCP -Operational Requirements，March 2022
本文档更新了RFC 1123和RFC 1536。本文档要求将允许DNS消息在Internet上通过TCP传输的操作实践作为当前最佳实践。此操作要求与RFC 7766中的实施要求一致。TCP的使用包括基于未加密TCP的DNS以及加密的TLS会话。该文件还考虑了这种形式的DNS通信的后果，以及在不支持当前最佳实践时可能出现的潜在运营问题。
本备忘录记录了 Internet 最佳当前实践。
本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已获互联网工程指导小组 (IESG) 批准出版。有关 BCP 的更多信息，请参见 RFC 7841 的第 2 节。
有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc9210。
版权所有 (c) 2022 IETF Trust 和文件作者。版权所有。
本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定 (https://trustee.ietf.org/license-info) 的约束，该条款在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节所述的修订版 BSD 许可文本，并且按照修订版 BSD 许可中的说明提供无担保。
DNS消息使用 UDP 或 TCP 通信传送。虽然大多数 DNS 事务都是通过 UDP 进行的，但一些运营商认为对于一般的 DNS 操作来说，任何基于 TCP 的 DNS 流量都是不需要或不必要的。当DNS over TCP受到限制时，经常会出现各种通信故障和调试挑战。随着 DNS 和新的域名系统功能的发展，TCP 作为一种传输方式对于 Internet DNS 的正确和安全运行变得越来越重要。反映现代用法，DNS 标准声明对 TCP 的支持是 DNS 实现规范 [RFC7766] 的必需部分。本文档相当于运营社区的正式要求，鼓励系统管理员、网络工程师和安全人员确保 DNS-over-TCP 通信支持与 DNS-over-UDP 通信相同。它更新了 [RFC1123] 的第 6.1.3.2 节以阐明所有 DNS 解析器和递归服务器必须支持和服务 TCP 和 UDP 查询，并更新 [RFC1536] 以消除 TCP 仅对区域传输有用的误解。
本文档中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应该”、“不应”、“推荐”、“不推荐”、“可以”和“可选”，当且仅当它们以全部大写字母出现时，将按照BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，如此处所示。
运营最佳实践与 DNS 传输协议指南之间的奇怪分歧源于运营商从其他运营商、实施者甚至 IETF 收到的相互冲突的消息。有时这些混合信号是明确的；在其他情况下，相互矛盾的信息是隐含的。本节介绍了导致本文档的传奇且相互矛盾的历史的解释。本节仅供参考。
在最初的 DNS 规范套件中，[RFC1034] 和 [RFC1035] 明确规定 DNS 消息可以在 UDP 或 TCP 中传输，但它们也声明在一般情况下优先选择 UDP 作为查询的最佳传输。如 [RFC1035] 中所述：
“虽然虚拟电路可用于任何 DNS 活动，但数据报更适合用于查询，因为它们的开销较低且性能更好。”
另一个早期的、重要的和有影响力的文件，[RFC1123]，更明确地标记了对传输协议的偏好：
“DNS 解析器和递归服务器必须支持 UDP，并且应该支持 TCP，以发送（非区域传输）查询。”
并进一步规定：
“域名服务器可以限制它用于 TCP 查询的资源，但它不应该仅仅因为它会通过 UDP 成功而拒绝为 TCP 查询提供服务。”
在 [RFC1536] 中达到高潮，基于 TCP 的 DNS 主要与区域传输机制相关联，而大多数 DNS 查询和响应被视为 UDP 的统治。
在原始规范中，最大 DNS-over-UDP 消息大小规定为 512 字节。然而，即使 [RFC1123] 更喜欢 UDP 进行非区域传输查询，它也预见到 DNS over TCP 将在未来变得更加流行，以克服这个限制：
“很明显，未来定义的一些新 DNS 记录类型将包含超过适用于 UDP 的 512 字节限制的信息，因此需要 TCP。”
至少有两个新的、被广泛期待的发展提高了对 DNS-over-TCP 事务的需求。第一个是 [RFC2136] 中定义的动态更新，第二个是统称为“DNSSEC”的扩展集，其操作注意事项最初在 [RFC2541] 中给出（注意 [RFC2541] 已被 [RFC6781] 废弃）。前者建议需要准确响应代码的请求者必须使用 TCP。
而后者警告说，较大的密钥会增加 KEY 和 SIG RR 的大小。这增加了 DNS UDP 数据包溢出的可能性以及在响应中使用更高开销 TCP 的可能必要性。
然而，出乎一些人的意料，在 1990 年代后期，基于 TCP 的 DNS 在互联网上的实际流量中仍然很少使用。动态更新在自治网络之间几乎没有部署。大约在首次定义 DNSSEC 的时候，另一个新功能帮助巩固了 UDP 传输在消息事务中的主导地位。
1999 年，IETF 在 [RFC2671] 中发布了 DNS 扩展机制 (Extension Mechanisms for DNS，EDNS(0))（在 2013 年被 [RFC6891] 废弃）。该文档标准化了一种用于通信 DNS 节点以执行基本功能协商的方式。写入基本规范并出现在每个与 EDNS(0) 兼容的消息中的此类功能之一是发送方可以支持的最大 UDP 有效负载大小的值。这个无符号的 16 位字段以字节为单位指定节点能够通过 UDP 接收的最大（可能是分段的）DNS 消息大小。在实践中，典型值是 512 到 4096 字节范围的子集。在接下来的几年中，EDNS(0) 得到了广泛的部署，大量调查（参见 [CASTRO2010] 和 [NETALYZR]）表明，许多系统通过 EDNS(0) 支持更大的 UDP MTU。
EDNS(0) 部署的自然效果意味着大于 512 字节的 DNS 消息对 TCP 的依赖程度将低于其他情况。虽然不可忽略的 DNS 系统群体缺少 EDNS(0) 或在必要时回退到 TCP，但 DNS 客户端仍然强烈倾向于使用 UDP 而不是 TCP。例如，截至 2014 年，DNS-over-TCP 事务在根域名服务器 [VERISIGN] 接收的整体 DNS 流量中仍然只占很小的一部分。
尽管 EDNS(0) 为端点提供了一种表示支持超过 512 字节的 DNS 消息的方法，但 Internet 的多样化和不一致部署的现实可能导致一些大型消息无法到达其目的地。任何大小超过其传输的链路的 MTU 的 IP 数据报都将被分片，然后由接收主机重新组合。不幸的是，中间设备和防火墙阻止 IP 片段的情况并不少见。如果一个或多个片段没有到达，应用程序不会收到消息，请求超时。
对于 IPv4 连接的主机，MTU 通常是 1500 字节的以太网负载大小。这意味着可以通过 IPv4 发送的最大未分段 UDP DNS 消息可能是 1472 字节，尽管在某些情况下隧道封装可能会减小最大消息大小。
对于 IPv6，情况稍微复杂一些。首先，IPv6 报文头为 40 个字节（而 IPv4 中为 20 个字节）。其次，大约三分之一的 DNS 递归解析器使用 1280 字节的最小 MTU [APNIC]。第三，IPv6 中的分段只能由发起数据报的主机完成。分段的需要在 ICMPv6“数据包太大”消息中传达。始发主机指示带有 IPv6 扩展头的分段数据报。不幸的是，ICMPv6 和 IPv6 扩展报文头都被中间设备阻止是很常见的。根据 [HUSTON]，大约 35% 的支持 IPv6 的递归解析器无法接收分段的 IPv6 数据包。当始发主机收到需要分段的信号时，它应该为该目的地填充其路径 MTU 缓存。应用程序将在超时后重试查询，因为主机通常不会保留通过 UDP 发送的消息副本以用于可能的重传。
所有这一切的实际后果是 DNS 请求者必须准备好使用不同的 EDNS(0) 最大消息大小值重试查询。[BIND] 的管理员可能熟悉在他们的系统日志中看到以下消息：“成功解析……在将通告的 EDNS(0) UDP 数据包大小减少到 512 个八位字节后”。
通常，减小 EDNS(0) UDP 数据包大小会导致成功响应。也就是说，必要的数据适合较小的消息大小。但是，当数据不适合时，服务器会在其响应中设置截断标志，指示客户端应通过 TCP 重试以接收整个响应。从客户端的角度来看，这是不可取的，因为它增加了更多的延迟，并且从服务器的角度来看，由于 TCP 的资源需求增加，这可能是不可取的。
请注意，接收方无法区分由于拥塞而丢失的数据包和防火墙或中间设备故意丢弃的数据包（片段）。在具有大量丢包的网络路径上，与较小的未分段响应相比，较大的分段 DNS 响应更有可能永远不会到达并超时。由于错误的原因，客户端可能会被误导使用不同的 EDNS(0) UDP 数据包大小值重试查询。
围绕碎片、截断和 TCP 的问题正在推动 DNS 中的某些实施和政策决策。值得注意的是，Cloudflare 实施了一种技术，可最大限度地减少 DNSSEC 拒绝存在记录的数量（针对其在线签名平台）[CLOUDFLARE]，并使用椭圆曲线数字签名算法 (Elliptic Curve Digital Signature Algorithm，ECDSA)，使其签名响应轻松放入 512 个字节。密钥签名密钥 (Key Signing Key，KSK) 翻转设计团队 [DESIGNTEAM] 花了很多时间思考和担心响应大小。DNSSEC 社区越来越多的观点认为，超过 2048 位的 RSA 密钥大小是不切实际的，关键基础设施区域应过渡到椭圆曲线算法以保持响应大小可管理 [ECDSA]。
最近，关于分段 DNS 消息的新安全问题（参见 [AVOID_FRAGS] 和 [FRAG_POISON]）导致实施者考虑更小的响应和更低的默认 EDNS(0) UDP 有效负载大小值，用于查询器和响应器 [FLAGDAY2020]。
今天，大多数 DNS 社区都希望，或者至少希望看到 DNS-over-TCP 事务在不受干扰的情况下发生 [FLAGDAY2020]。然而，一些运营商长期以来一直认为，尤其是出于安全相关的原因，DNS-over-TCP 服务应该被故意限制或根本不提供 [CHES94] [DJBDNS]。一个流行的梗是 TCP 上的 DNS 仅用于区域传输，否则通常是不必要的，过滤所有 TCP 上的 DNS 流量甚至被描述为最佳实践。
鉴于 DNS 域名服务器的历史实现几乎没有提供 TCP 连接管理的方式（例如，有关更多详细信息，请参阅 [RFC7766] 的第 6.1.2 节），限制基于 TCP 的 DNS 的立场是有道理的。然而，现代标准和实施已接近与 HTTP(S) 服务器和负载均衡器等采用的更复杂的 TCP 管理技术相当。
TCP 连接可以支持多个事务的想法可以追溯到 [RFC0883]，其中指出：“可以通过虚拟电路发送多个消息。”尽管更新前者的 [RFC1035] 省略了这一特定细节，但人们普遍认为 TCP 连接可用于多个查询和响应。
[RFC5966] 阐明了服务器不需要在任何传输中保留查询和响应的顺序。[RFC7766] 更新了前者，进一步鼓励通过 TCP 进行查询流水线以达到与 UDP 相当的性能。当对较早查询的响应在对较早查询的响应之前准备好时，向流水线查询发送无序响应的服务器避免了线头阻塞。
但是，由于数据包丢失，TCP 可能会遇到不同的线头阻塞问题。由于 TCP 本身强制执行排序，单个丢失的段会延迟任何后续段中的数据传递，直到丢失的段被重新传输并成功接收。
DNS 消息大小的平均增加（例如，由于 DNSSEC）、新 DNS 功能的持续开发（附录 A）以及拒绝服务缓解技术（第 8 节）都表明 DNS-over-TCP 事务是对于 Internet DNS 的正确和安全运行，与以往一样重要，甚至更重要。此外，有研究认为面向连接的 DNS 事务可能比 UDP 传输 [TDNS] 提供安全和隐私优势。事实上，DNS over TLS [RFC7858] 的标准就是这种规范。因此，本文档明确指出网络运营商不希望人为地禁止 DNS-over-TCP 传输。
[RFC1123] 的第 6.1.3.2 节更新如下：
之前是“DNS 解析器和递归服务器必须支持 UDP，并且应该支持 TCP，以发送（非区域传输）查询。”
现在是“所有 DNS 解析器和服务器必须支持和服务 UDP 和 TCP 查询。”
注意：
* DNS 服务器（包括转发器）必须支持和服务 TCP 以接收查询，以便客户端可以可靠地接收大于任何一方认为对于 UDP 来说太大的响应。
* DNS 客户端必须支持 TCP 发送查询，以便它们可以在必要时重试截断的 UDP 响应。
此外，[RFC1123] 的第 6.1.3.2 节中关于限制服务器用于查询的资源的要求在此更新：
之前是“域名服务器可以限制它用于 TCP 查询的资源，但它不应该仅仅因为它会通过 UDP 成功而拒绝为 TCP 查询提供服务。”
现在是“域名服务器可以限制它用于查询的资源，但它绝不能仅仅因为它可以使用另一个传输协议成功而拒绝为查询提供服务。”
最后，更新了 [RFC1536] 的第 1 节，以消除 TCP 仅对区域传输有用的误解：
之前是“DNS 实现了客户端-服务器交互的经典请求-响应方案。因此，UDP 是选择的通信协议，尽管 TCP 用于区域传输。”
现在是“DNS 实现了客户端-服务器交互的经典请求-响应方案。”
在一般情况下，通过 TCP 过滤 DNS 是有害的。DNS 解析器和服务器运营商必须支持并通过 UDP 和 TCP 传输提供 DNS 服务。同样，网络运营商必须允许通过 UDP 和 TCP 传输的 DNS 服务。众所周知，DNS-over-TCP 服务可能会带来单独运行 DNS over UDP 时不存在的操作挑战，反之亦然。但是，与允许使用 DNS 相比，禁止 DNS-over-TCP 服务所带来的潜在损害对 DNS 的持续实用性和成功更为不利。
本节介绍系统和应用程序可以采取哪些措施来优化 TCP 的性能并保护自己免受基于 TCP 的资源耗尽和攻击。
解析器和其他 DNS 客户端应该知道某些服务器可能无法通过 TCP 访问。出于这个原因，客户端可以跟踪和限制对单个服务器的 TCP 连接和连接尝试的数量。可达性问题可能是由靠近服务器、靠近客户端或它们之间路径上的任何地方的网络元素引起的。缓存连接失败的移动客户端可以在每个网络的基础上这样做，或者可以在网络更改时清除这样的缓存。
此外，DNS 客户端可以对未建立的连接强制执行短暂的超时，而不是依赖主机操作系统的 TCP 连接超时，这通常约为 60-120 秒（即，由于 1 秒的初始重传超时，指数回退[RFC6298] 的规则，以及六次重试的限制，这是 Linux 中的默认值）。
SYN 泛洪攻击是一种拒绝服务方法，影响运行 TCP 服务器进程的主机 [RFC4987]。如果不加以缓解，这种攻击可能非常有效。最有效的缓解技术之一是 SYN cookie，在 [RFC4987] 的第 3.6 节中进行了描述，它允许服务器避免分配任何状态，直到成功完成三次握手。
不打算供公共 Internet 使用的服务，例如大多数递归域名服务器，应该受到访问控制的保护。理想情况下，这些控件放置在网络中，远在任何不需要的 TCP 数据包到达 DNS 服务器主机或应用程序之前。如果这是不可能的，可以将控件放置在应用程序本身中。在某些情况下（例如，攻击），可能有必要为原本应该可以全局访问的 DNS 服务部署访问控制。另见 [RFC5358]。
FreeBSD 和 NetBSD 操作系统有一个“接受过滤器”特性（[accept_filter]），它可以推迟向应用程序发送 TCP 连接，直到收到完整、有效的请求。dns_accf(9) 过滤器确保接收到有效的 DNS 消息。如果没有，虚假连接永远不会到达应用程序。Linux TCP_DEFER_ACCEPT 功能虽然范围更有限，但可以提供与 BSD 接受过滤器功能相同的一些好处。这些功能是作为低级套接字选项实现的，不会自动激活。如果应用程序希望使用这些功能，他们需要进行特定调用以设置正确的选项，并且管理员可能还需要配置应用程序以适当地使用这些功能。
根据 [RFC7766]，建议应用程序和管理员记住在发送任何 UDP 查询之前可以使用 TCP。不得将网络和应用程序配置为拒绝前面没有 UDP 查询的 TCP 查询。
TCP 快速打开 (TCP Fast Open，TFO) [RFC7413] 允许 TCP 客户端缩短与同一服务器的后续连接的握手。TFO 在连接设置中节省了一次往返时间。DNS 服务器应该尽可能启用 TFO。此外，集群在单个服务地址后面的 DNS 服务器（例如，任播或负载均衡）应该在所有实例上使用相同的 TFO 服务器密钥，或者为集群的所有成员禁用 TFO。
DNS 客户端也可以启用 TFO。在撰写本文时，它尚未在某些操作系统上实现或默认禁用。[WIKIPEDIA_TFO] 描述了支持 TFO 的应用程序和操作系统。
由于 TCP 状态的主机内存是有限资源，DNS 客户端和服务器应该主动管理它们的连接。不主动管理其连接的应用程序可能会遇到资源耗尽导致拒绝服务。对于 DNS，与在其他协议中一样，在保持连接开放以供未来可能使用和需要为即将到来的新连接释放资源之间进行权衡。
DNS 服务器软件的运营商应该知道，操作系统和应用程序供应商可能会对已建立的连接总数施加限制。这些限制可能旨在防止 DDoS 攻击或性能下降。运营商应该了解如何在必要时增加这些限制以及这样做的后果。应用程序施加的限制应该低于操作系统施加的限制，以便应用程序可以将自己的策略应用于连接管理，例如首先关闭最旧的空闲连接。
DNS 服务器软件可以对每个源 IP 地址或子网的已建立连接数提供可配置的限制。这可用于确保单个或一小组用户不能消耗所有 TCP 资源并拒绝向其他用户提供服务。但是请注意，如果启用此限制，它可能会限制客户端性能，同时使某些 TCP 资源未被使用。运营商应该意识到这些权衡，并确保根据用户的数量和多样性以及用户是从唯一的 IP 地址还是通过共享的网络地址转换器 (Network Address Translator，NAT) [RFC3022] 来适当设置此限制（如果已配置） .
DNS 服务器软件应该为空闲 TCP 连接提供可配置的超时。这可用于为新连接释放资源并确保最终关闭空闲连接。同时，它可能会限制客户端性能，同时使一些 TCP 资源未被利用。对于非常繁忙的域名服务器，这可能会设置为较低的值，例如几秒钟。对于不太繁忙的服务器，它可能会设置为更高的值，例如几十秒。DNS 客户端和服务器应该使用 edns-tcp-keepalive EDNS(0) 选项 [RFC7828] 来通知它们的超时值。
DNS 服务器软件可以对每个 TCP 连接的事务数量提供可配置的限制。这有助于防止不公平的连接使用（例如，不向其他客户端释放连接槽）和网络规避攻击。
同样，DNS 服务器软件可以对 TCP 连接的总持续时间提供可配置的限制。这有助于防止不公平的连接使用、慢读攻击和网络规避攻击。
由于客户端可能不知道服务器施加的限制，因此使用 TCP 进行 DNS 的客户端需要始终准备好重新建立连接或重试未完成的查询。
发起连接关闭的 TCP 对等体将套接字保持在 TIME_WAIT 状态一段时间，可能是几分钟。通常最好由客户端发起关闭 TCP 连接，这样繁忙的服务器就不会积累很多处于 TIME_WAIT 状态的套接字，这可能会导致性能问题甚至拒绝服务。edns-tcp-keepalive EDNS(0) 选项 [RFC7828] 可用于鼓励客户端关闭连接。
在 TIME_WAIT 中观察到大量套接字（作为客户端或服务器）并影响应用程序性能的系统上，调整本地 TCP 参数可能很诱人。例如，Linux 内核有一个名为 net.ipv4.tcp_tw_reuse 的“sysctl”参数，它允许在特定情况下复用处于 TIME_WAIT 状态的连接。但是请注意，这仅影响传出（客户端）连接，对服务器没有影响。在大多数情况下，不建议更改与 TIME_WAIT 状态相关的参数。它只能由对 TCP 和受影响的应用程序有详细了解的人员来完成。
DNS 消息可以通过 TLS 发送，以在存根和递归解析器之间提供隐私。[RFC7858] 是一个标准跟踪文档，描述了它是如何工作的。尽管 DNS over TLS 使用 TCP 端口 853 而不是端口 53，但本文档同样适用于 DNS over TLS。但是请注意，在撰写本文时，仅在存根和递归之间定义了基于 TLS 的 DNS。
TLS 的使用给 DNS 客户端和服务器带来了更大的运营负担。用于身份验证和加密的加密功能需要额外的处理。与 TCP 相比，使用 TLS 1.3 [RFC8446] 的未优化连接设置需要多一次往返。使用 TLS 1.2 的 TCP Fast Open 和 TLS False Start [RFC7918] 可以减少连接设置时间。TLS 1.3 会话恢复不会减少往返延迟，因为在撰写本文时尚未发布使用 DNS 的 TLS 0-RTT 数据的应用程序配置文件。但是，TLS 会话恢复可以减少加密操作的数量，并且在 TLS 1.2 中，会话恢复确实将额外的往返次数从两次减少到一次。
在撰写本文时，对流行的开源 DNS 服务器实施进行了功能和默认设置的调查。本节记录了这些默认值，并就可在没有任何其他信息的情况下使用的可配置限制提出建议。本文档中的任何推荐值仅供不确定哪种限制可能是合理的管理员的起点。运营商应该使用特定于应用程序的监控、系统日志和系统监控工具来衡量他们的服务是否在这些限制范围内或超过这些限制范围内运行，并进行相应的调整。
大多数开源 DNS 服务器实现对已建立的连接总数提供了可配置的限制。默认值范围从 20 到 150。在大多数情况下，大多数查询通过 UDP 进行，150 是一个合理的限制。对于大多数查询通过 TCP 或 TLS 进行的服务或环境，5000 是更合适的限制。
只有一些开源实现提供了一种方法来限制每个源 IP 地址或子网的连接数，但默认设置是没有限制。对于可能需要启用此限制的环境或情况，每个源 IP 地址 25 个连接是一个合理的起点。当按子网聚合或大多数查询通过 TCP 或 TLS 进行的服务时，应增加限制。
大多数开源实现都提供了可配置的连接空闲超时。默认值范围为 2 到 30 秒。在大多数情况下，10 秒是此限制的合理默认值。更长的超时时间可以提高连接复用，但繁忙的服务器可能需要使用下限。
只有一些开源实现提供了一种方法来限制每个连接的事务数，但默认设置是没有限制。本文档不提供有关此类限制的特定值的建议。
只有一些开源实现提供了一种限制连接持续时间的方法，但默认情况下是没有限制的。本文档不提供有关此类限制的特定值的建议。
通过 TCP 过滤 DNS 的网络可能会失去对 DNS 域名空间的重要或重要部分的访问权限。由于各种原因，DNS 应答可能需要 DNS-over-TCP 查询。这可能包括大型消息、缺乏 EDNS(0) 支持或 DDoS 缓解技术（包括响应速率限制 [Response Rate Limiting，RRL]）；此外，也许一些尚未预见的未来能力也将需要 TCP 传输。
例如，[RFC7901] 描述了一种在 DNS 响应中发送额外数据的延迟避免技术。这使得响应更大，并可能提高 DDoS 反射攻击的有效性。该规范要求使用 TCP 或 DNS cookie [RFC7873]。
即使过去使用 UDP 成功返回了任何或所有特定响应，但在自治系统之间交换 DNS 消息时，无法保证这种持续行为。因此，通过 TCP 过滤 DNS 被认为是有害的，并且与 Internet 的安全和成功运行背道而驰。本节列举了在撰写本文时网络通过 TCP 过滤 DNS 时的一些已知风险。
通过 TCP 过滤 DNS 的网络可能会无意中导致第三方解析器出现问题，正如 [TOYAMA] 所经历的那样。例如，解析器接收对中等流行域的查询。解析器将查询转发到域的权威域名服务器，但这些服务器以设置的 TC 位进行响应。解析器通过 TCP 重试，但权威服务器通过 TCP 阻止 DNS。挂起的连接会消耗解析器上的资源，直到超时。如果这些被截断然后阻塞的查询的数量和频率足够高，那么解析器会将宝贵的资源浪费在永远无法回答的查询上。受影响的 DNS 解析器运营商通常不会轻易或完全缓解这种情况。
为根区域部署 DNSSEC KSK 的计划突出了检索根区域密钥集 [LEWIS] 的潜在问题。在 KSK 翻转过程的某些阶段，根区域 DNSKEY 响应大于 1280 字节，这是承载 IPv6 流量的链路的 IPv6 最小 MTU [RFC8200]。有人担心任何无法通过 UDP 接收大型 DNS 消息或任何通过 TCP 的 DNS 消息的 DNS 服务器在执行 DNSSEC 验证时会遇到中断 [KSK_ROLLOVER_ARCHIVES]。
但是，在长达一年的 KSK 轮转延期期间，当新旧密钥都在区域中发布时，没有报告可归因于 1414 八位字节 DNSKEY 响应的问题。此外，在旧密钥发布为已撤销且 DNSKEY 响应大小为 1425 个八位字节 [ROLL_YOUR_ROOT] 的两个月期间，没有报告任何问题。
记录或监控 DNS 的应用程序开发人员不应因为认为 TCP 很少使用或难以处理而忽略它。运营商应确保其监控和日志记录应用程序通过 TCP 正确捕获 DNS 消息。否则，可能无法检测到攻击、渗透尝试和正常流量。
TCP 上的 DNS 消息不能保证在单个段中到达。事实上，聪明的攻击者可能会试图通过将某些消息强制通过非常小的 TCP 段来隐藏某些消息。捕获网络数据包的应用程序（例如，使用 libpcap [libpcap]）应该实现并执行完整的 TCP 流重组并分析重组后的流而不是单个数据包。否则，它们很容易受到网络规避攻击 [phrack]。此外，此类应用程序需要通过限制分配给跟踪未确认的连接状态数据的内存量来保护自己免受资源耗尽攻击。dnscap [dnscap] 是实现 TCP 流重组的 DNS 日志记录程序的开源示例。
在构建和测试 DNS 监控应用程序时，开发人员还应该牢记连接复用、查询管道和乱序响应。
作为数据包捕获的替代方案，一些 DNS 服务器软件支持 dnstap [dnstap] 作为旨在促进大规模 DNS 监控的集成监控协议。
本文档没有 IANA 操作。
本文档提供了操作要求，是 [RFC7766] 中提供的基于 TCP 的 DNS 实施要求的配套文件。[RFC7766] 中的安全考虑仍然适用。
具有讽刺意味的是，返回截断的 DNS-over-UDP 响应以诱导客户端查询切换到基于 TCP 的 DNS 已成为对源地址欺骗、DNS 拒绝服务攻击 [RRL] 的常见响应。从历史上看，运营商一直对基于 TCP 的攻击保持警惕，但近年来，基于 UDP 的泛洪攻击已被证明是最常见的 DNS 协议攻击。然而，TCP 上的高速率短期 DNS 事务可能会带来挑战。事实上，如果可以预测 IP 标识符字段（IPv4 中的 16 位和 IPv6 中的 32 位）并且系统被强制分片而不是重传消息，则 [DAI21] 详细介绍了针对 DNS 事务的一类 IP 分片攻击。尽管许多运营商多年来一直在毫无胁迫地提供 DNS-over-TCP 服务，但过去的经验并不能保证未来的成功。
基于 TCP 的 DNS 类似于许多其他 Internet TCP 服务。TCP 威胁和许多缓解策略已在 [RFC4953]、[RFC4987]、[RFC5927] 和 [RFC5961] 等一系列文档中详细记录。
如第 6 节所述，实现 TCP 流重组的应用程序需要限制分配给连接跟踪的内存量。不这样做可能会导致日志记录或监控应用程序完全失败。强加资源限制在允许某些流重组继续和允许某些规避攻击成功之间进行权衡。
本文档建议 DNS 服务器尽可能启用 TFO。[RFC7413] 建议负载均衡器后面的服务器池与共享服务器 IP 地址共享用于生成快速打开 cookie 的密钥，以防止过度回退到三次握手 (three-way handshake，3WHS)。该指南仍然准确，但有一个警告：破坏一台服务器会泄露此组共享密钥，并允许通过伪造无效的快速打开 cookie 来进行涉及池中其他服务器的攻击。
由于 UDP 和 TCP 上的 DNS 使用相同的底层消息格式，使用一种传输而不是另一种传输不会改变消息内容的隐私特征（即被查询的名称）。最近开发了许多协议来提供 DNS 隐私，包括基于 TLS 的 DNS [RFC7858]、基于 DTLS 的 DNS [RFC8094]、基于 HTTPS 的 DNS [RFC8484]，还有更多协议正在开发中。
因为 TCP 比 UDP 稍微复杂一些，所以 TCP 对话的某些特征可能会启用 DNS 客户端指纹识别和跟踪，而这在 UDP 中是不可能的。例如，初始序列号、窗口大小和选项的选择可能能够识别特定的 TCP 实现，甚至可以识别共享资源（如 NAT）后面的单个主机。
[] Mockapetris, P., "Domain names -implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.[] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.[] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/info/rfc2181>.[] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.[] 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, <https://www.rfc-editor.org/info/rfc7766>.[] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/RFC7828, April 2016, <https://www.rfc-editor.org/info/rfc7828>.[] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, <https://www.rfc-editor.org/info/rfc7873>.[] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[] FreeBSD, "FreeBSD accept_filter(9)", June 2000, <https://www.freebsd.org/cgi/man.cgi?query=accept_filter>.[] Huston, G., "DNS XL", October 2020, <https://labs.apnic.net/?p=1380>.[] Fujiwara, K. and P. Vixie, "Fragmentation Avoidance in DNS", Work in Progress, Internet-Draft, draft-ietf-dnsop-avoid-fragmentation-06, 23 December 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-06>.[] Internet Systems Consortium, "BIND 9", <https://www.isc.org/bind/>.[] Castro, S., Zhang, M., John, W., Wessels, D., and K. claffy, "Understanding and Preparing for DNS Evolution", DOI 10.1007/978-3-642-12365-8_1, April 2010, <https://doi.org/10.1007/978-3-642-12365-8_1>.[] Cheswick, W. and S. Bellovin, "Firewalls and Internet Security: Repelling the Wily Hacker", First Edition, 1994.[] Grant, D., "Economical With The Truth: Making DNSSEC Answers Cheap", June 2016, <https://blog.cloudflare.com/black-lies/>.[] Dai, T., Shulman, H., and M. Waidner, "DNS-over-TCP Considered Vulnerable", DOI 10.1145/3472305.3472884, July 2021, <https://doi.org/10.1145/3472305.3472884>.[] ICANN, "Root Zone KSK Rollover Plan", March 2016, <https://www.iana.org/reports/2016/root-ksk-rollover-design-20160307.pdf>.[] Bernstein, D., "When are TCP queries sent?", November 2002, <https://cr.yp.to/djbdns/tcp.html#why>.[] DNS-OARC, "DNSCAP", February 2014, <https://www.dns-oarc.net/tools/dnscap>.[] "dnstap", <https://dnstap.info>.[] van Rijswijk-Deij, R., Sperotto, A., and A. Pras, "Making the Case for Elliptic Curves in DNSSEC", DOI 10.1145/2831347.2831350, October 2015, <https://dl.acm.org/doi/10.1145/2831347.2831350>.[] DNS Software and Service Providers, "DNS Flag Day 2020", October 2020, <https://dnsflagday.net/2020/>.[] Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous", May 2012, <https://arxiv.org/pdf/1205.4011.pdf>.[] Huston, G., "Dealing with IPv6 fragmentation in the DNS", August 2017, <https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/>.[]ICANN, "KSK Rollover List Archives", January 2019,<https://mm.icann.org/pipermail/ksk-rollover/2019-January/date.html>.[] Lewis, E., "2017 DNSSEC KSK Rollover", RIPE 74, May 2017, <https://ripe74.ripe.net/presentations/25-RIPE74-lewis-submission.pdf>.[] The Tcpdump Group, "Tcpdump and Libpcap", <https://www.tcpdump.org>.[] Kreibich, C., Weaver, N., Nechaev, B., and V. Paxson, "Netalyzr: Illuminating The Edge Network", DOI 10.1145/1879141.1879173, November 2010, <https://doi.org/10.1145/1879141.1879173>.[] horizon, "Defeating Sniffers and Intrusion Detection Systems", Phrack Magazine, December 1998, <http://phrack.org/issues/54/10.html>.[] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.[] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.[] Mockapetris, P., "Domain names: Implementation specification", RFC 883, DOI 10.17487/RFC0883, November 1983, <https://www.rfc-editor.org/info/rfc883>.[] Mockapetris, P., "Domain names -concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.[] Braden, R., Ed., "Requirements for Internet Hosts -Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>.[] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller, "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993, <https://www.rfc-editor.org/info/rfc1536>.[] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, DOI 10.17487/RFC1995, August 1996, <https://www.rfc-editor.org/info/rfc1995>.[] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, <https://www.rfc-editor.org/info/rfc1996>.[] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/info/rfc2136>.[] Eastlake 3rd, D., "DNS Security Operational Considerations", RFC 2541, DOI 10.17487/RFC2541, March 1999, <https://www.rfc-editor.org/info/rfc2541>.[] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, DOI 10.17487/RFC2671, August 1999, <https://www.rfc-editor.org/info/rfc2671>.[] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, DOI 10.17487/RFC2694, September 1999, <https://www.rfc-editor.org/info/rfc2694>.[] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <https://www.rfc-editor.org/info/rfc3022>.[] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, DOI 10.17487/RFC3225, December 2001, <https://www.rfc-editor.org/info/rfc3225>.[] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, DOI 10.17487/RFC3226, December 2001, <https://www.rfc-editor.org/info/rfc3226>.[] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, DOI 10.17487/RFC4472, April 2006, <https://www.rfc-editor.org/info/rfc4472>.[] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, DOI 10.17487/RFC4953, July 2007, <https://www.rfc-editor.org/info/rfc4953>.[] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, <https://www.rfc-editor.org/info/rfc4987>.[] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, DOI 10.17487/RFC5358, October 2008, <https://www.rfc-editor.org/info/rfc5358>.[] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, DOI 10.17487/RFC5452, January 2009, <https://www.rfc-editor.org/info/rfc5452>.[] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, Ed., "Design Choices When Expanding the DNS", RFC 5507, DOI 10.17487/RFC5507, April 2009, <https://www.rfc-editor.org/info/rfc5507>.[] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, <https://www.rfc-editor.org/info/rfc5625>.[] Gont, F., "ICMP Attacks against TCP", RFC 5927, DOI 10.17487/RFC5927, July 2010, <https://www.rfc-editor.org/info/rfc5927>.[] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, <https://www.rfc-editor.org/info/rfc5936>.[] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, DOI 10.17487/RFC5961, August 2010, <https://www.rfc-editor.org/info/rfc5961>.[] Bellis, R., "DNS Transport over TCP -Implementation Requirements", RFC 5966, DOI 10.17487/RFC5966, August 2010, <https://www.rfc-editor.org/info/rfc5966>.[] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.[] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.[] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, <https://www.rfc-editor.org/info/rfc6781>.[] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, "Architectural Considerations on Application Features in the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, <https://www.rfc-editor.org/info/rfc6950>.[] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.[] Hardaker, W., "Child-to-Parent Synchronization in DNS", RFC 7477, DOI 10.17487/RFC7477, March 2015, <https://www.rfc-editor.org/info/rfc7477>.[] Abley, J. and W. Sotomayor, "AS112 Nameserver Operations", RFC 7534, DOI 10.17487/RFC7534, May 2015, <https://www.rfc-editor.org/info/rfc7534>.[] Blanchet, M. and L-J. Liman, "DNS Root Name Service Protocol and Deployment Requirements", BCP 40, RFC 7720, DOI 10.17487/RFC7720, December 2015, <https://www.rfc-editor.org/info/rfc7720>.[] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.[] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, DOI 10.17487/RFC7901, June 2016, <https://www.rfc-editor.org/info/rfc7901>.[] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", RFC 7918, DOI 10.17487/RFC7918, August 2016, <https://www.rfc-editor.org/info/rfc7918>.[] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy, "DNSSEC Roadblock Avoidance", BCP 207, RFC 8027, DOI 10.17487/RFC8027, November 2016, <https://www.rfc-editor.org/info/rfc8027>.[] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-editor.org/info/rfc8094>.[] Hoffman, P. and J. Schlyter, "Using Secure DNS to Associate Certificates with Domain Names for S/MIME", RFC 8162, DOI 10.17487/RFC8162, May 2017, <https://www.rfc-editor.org/info/rfc8162>.[] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.[] Klensin, J., "DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?", RFC 8324, DOI 10.17487/RFC8324, February 2018, <https://www.rfc-editor.org/info/rfc8324>.[] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.[] Mayrhofer, A., "Padding Policies for Extension Mechanisms for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, October 2018, <https://www.rfc-editor.org/info/rfc8467>.[] Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt, "Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January 2019, <https://www.rfc-editor.org/info/rfc8482>.[] Song, L., Ed., Liu, D., Vixie, P., Kato, A., and S. Kerr, "Yeti DNS Testbed", RFC 8483, DOI 10.17487/RFC8483, October 2018, <https://www.rfc-editor.org/info/rfc8483>.[] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.[] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., Lemon, T., and T. Pusateri, "DNS Stateful Operations", RFC 8490, DOI 10.17487/RFC8490, March 2019, <https://www.rfc-editor.org/info/rfc8490>.[] Howard, L., "Reverse DNS in IPv6 for Internet Service Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018, <https://www.rfc-editor.org/info/rfc8501>.[] Kumari, W. and P. Hoffman, "Running a Root Server Local to a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020, <https://www.rfc-editor.org/info/rfc8806>.[] Andrews, M. and R. Bellis, "A Common Operational Problem in DNS Servers: Failure to Communicate", BCP 231, RFC 8906, DOI 10.17487/RFC8906, September 2020, <https://www.rfc-editor.org/info/rfc8906>.[] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and A. Mankin, "Recommendations for DNS Privacy Service Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932, October 2020, <https://www.rfc-editor.org/info/rfc8932>.[] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., Gudmundsson, O., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", STD 93, RFC 8945, DOI 10.17487/RFC8945, November 2020, <https://www.rfc-editor.org/info/rfc8945>.[] Müller, M., Thomas, M., Wessels, D., Hardaker, W., Chung, T., Toorop, W., and R. van Rijswijk-Deij, "Roll, Roll, Roll Your Root: A Comprehensive Analysis of the First Ever DNSSEC Root KSK Rollover", DOI 10.1145/3355369.3355570, October 2019, <https://dl.acm.org/doi/10.1145/3355369.3355570>.[] Vixie, P. and V. Schryver, "DNS Response Rate Limiting (DNS RRL)", ISC-TN-2012-1-Draft1, April 2012.[] Zhu, L., Heidemann, J., Wessels, D., Mankin, A., and N. Somaiya, "Connection-Oriented DNS to Improve Privacy and Security", DOI 10.1109/SP.2015.18, May 2015, <https://doi.org/10.1109/SP.2015.18>.[] Toyama, K., Ishibashi, K., Toyono, T., Ishino, M., Yoshimura, C., and K. Fujiwara, "DNS Anomalies and Their Impacts on DNS Cache Servers", NANOG 32, October 2004.[] Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in Root Server DITL Data", DNS-OARC 2014 Fall Workshop, October 2014.[] Wikipedia, "TCP Fast Open", February 2022, <https://en.wikipedia.org/w/index.php?title=TCP_Fast_Open&oldid=1071397204>.
本节列举了所有已知的 RFC，其状态为 Internet 标准、提议的标准、信息性、最佳当前实践或实验性，这些 RFC 隐含或明确地对使用 TCP 作为与本文档密切相关的 DNS 传输做出假设或陈述。
Internet 标准 [RFC1035] 是基本 DNS 规范，明确定义了对基于 TCP 的 DNS 的支持。
信息文档 [RFC1536] 指出 UDP 是“选择的通信协议，尽管 TCP 用于区域传输”。该声明现在应该在其历史背景下考虑，不再是现代期望的正确反映。
提议的标准 [RFC1995] 记录了当增量区域传输 (Incremental Zone Transfer，IXFR) 响应不适合单个 UDP 响应时使用 TCP 作为回退传输。与权威传输 (Authoritative Transfer，AXFR) 一样，IXFR 消息通常在实践中默认通过 TCP 传递。
提议的标准 [RFC1996] 建议主服务器可以决定通过 TCP 发出 NOTIFY 消息。在实践中，NOTIFY 消息通常通过 UDP 发送，但该规范留下了传输协议的选择取决于主服务器的可能性。因此，辅助服务器应该能够通过 UDP 和 TCP 运行。
提议的标准 [RFC2181] 包括阐明客户端应如何对响应中设置的 TC 位作出反应的文本。建议丢弃响应并使用 TCP 重新发送查询。
信息文档 [RFC2694] 列举了 NAT 设备正确处理 DNS 流量的注意事项。值得注意的是，该文档的建议“[t] 通常，TCP 用于 AXFR 请求”，作为进一步的证据，有助于解释为什么 DNS over TCP 的处理方式通常与 DNS over UDP 在运营网络中的处理方式截然不同。
提议的标准 [RFC3225] 声明表明基于 TCP 的 DNS 由于流量、延迟和服务器负载的增加而“有害”。本文档是 RFC 系列中的下一个文档的配套文档，该文档描述了对 DNSSEC 的 EDNS(0) 支持要求。
尽管被后来的 DNSSEC RFC 更新，提议的标准 [RFC3226] 强烈主张支持 UDP 消息而不是 TCP，主要是出于性能原因。该文档声明 EDNS(0) 是 DNSSEC 服务器的一项要求，并主张在某些情况下，数据包分段可能比 TCP 更可取。
信息文档 [RFC4472] 指出，IPv6 数据可能会增加 DNS 响应，超出 UDP 消息的范围。特别值得一提的是，但今天可能比撰写本文档时少见的是，它指的是在不设置 TC 位的情况下截断数据以鼓励客户端使用 TCP 重新发送查询的实现。
提议的标准 [RFC5452] 应运而生，因为公共 DNS 系统开始遭受来自欺骗性查询的广泛滥用，从而导致对不知情的受害者进行放大和反射攻击。[RFC5452]（“欺骗检测和对策”）的第 9.3 节简要描述了支持基于 TCP 的 DNS 以阻止这些攻击的主要理由之一。
信息文档 [RFC5507] 主要是试图阻止新的 DNS 数据类型使 TXT 资源记录类型过载。在此过程中，它总结了 DNS 设计和实施实践的传统智慧。作者认为，与 UDP 相比，TCP 开销和有状态属性构成了挑战，并暗示 UDP 通常更适合性能和健壮性。
Best Current Practice 文档 [RFC5625] 提供了 DNS 代理实施指南，包括要求代理“必须 […] 准备通过 TCP 接收和转发查询”，尽管它表明，从历史上看，TCP 传输并未严格在存根解析器或递归服务器中是必需的。
提议的标准 [RFC5936] 提供了区域传输协议的详细规范，正如早期 DNS 标准中最初概述的那样。AXFR 操作仅限于 TCP，而不是为 UDP 指定。本文档详细讨论了 TCP 的使用。
信息文档 [RFC7534] 列举了 AS112 项目 DNS 服务器的操作要求。测试了新的 AS112 节点在 UDP 和 TCP 传输上提供服务的能力，这意味着 TCP 服务是正常操作的预期部分。
在提议的标准 [RFC6762] 中，TC 位被认为具有与原始 DNS 规范中描述的基本相同的含义。也就是说，如果接收到设置了 TC 位的响应，“[…] 查询器应该使用 TCP 重新发出其查询，以便接收更大的响应。”
Internet 标准 [RFC6891] 有助于减缓 DNS-over-TCP 消息的使用和需求。本文档强调了广泛使用基于 TCP 的 DNS 时对服务器负载和可扩展性的担忧。
信息文档 [RFC6950] 提请注意 DNS 中的大数据。TCP 在上下文中被引用为一种常见的回退机制并对抗一些欺骗攻击。
提议的标准 [RFC7477] 指定了一个 RRType 和一个协议，以发信号通知和同步从子到父区域的 NS、A 和 AAAA 资源记录更改。由于该协议可能需要多个请求和响应，因此建议使用基于 TCP 的 DNS 来确保在一对一致的端节点之间进行对话。
Best Current Practice 文档 [RFC7720] 声明根名称服务“必须支持 DNS 查询和响应的 UDP [RFC0768] 和 TCP [RFC0793] 传输”。
提议的标准 [RFC7766] 指示 DNS 实施者为在其软件中承载 DNS-over-TCP 消息提供支持，并且可能被认为是此操作要求文档的直接祖先。实施要求文档规定了在兼容的 DNS 软件中对 DNS-over-TCP 的强制支持，但没有向运营商提供任何建议，我们在此寻求解决。
提议的标准 [RFC7828] 定义了一个 EDNS(0) 选项来协商长期 DNS-over-TCP 连接的空闲超时值。因此，本文档仅适用于和相关的 DNS-over-TCP 会话以及支持此选项的实现之间。
提议的标准 [RFC7858] 定义了一种使用 TLS 将 DNS 消息放入基于 TCP 的加密通道的方法。该规范值得注意的是明确针对存根到递归的流量，但不排除其应用从递归到权威的流量。
提议的标准 [RFC7873] 描述了一个 EDNS(0) 选项，以提供额外的保护以防止查询和应答伪造。当 DNS cookie 不可用时，该规范提到基于 TCP 的 DNS 作为替代机制。该规范确实在两种特定情况下提到了 DNS-over-TCP 处理。一方面，当服务器在请求中仅接收到客户端 cookie 时，服务器应考虑请求是否通过 TCP 到达，如果是，则应考虑接受 TCP 足以验证请求并做出相应的响应。在另一种情况下，当客户端使用新的服务器 cookie 接收到 BADCOOKIE 回复时，客户端应使用 TCP 作为传输重试。
实验规范 [RFC7901] 描述了一个 EDNS(0) 选项，一个安全感知验证解析器可以使用该选项来请求和获取任何单个查询的完整 DNSSEC 验证路径。本文档要求使用基于 TCP 的 DNS 或由源 IP 地址验证的传输机制，例如 EDNS-COOKIE [RFC7873]。
最佳当前实践文档 [RFC8027] 详细说明了 DNSSEC 部署和缓解技术所观察到的问题。网络流量阻塞和限制，包括 DNS-over-TCP 消息，被强调为 DNSSEC 部署问题的原因之一。虽然本文档表明此类问题是由“不合规的基础设施”引起的，但该文档的范围仅限于检测和缓解技术，以避免所谓的 DNSSEC 障碍。
实验规范 [RFC8094] 详细说明了使用数据报传输 (UDP) 的协议，但规定“在 DTLS 上实现 DNS 的 DNS 客户端和服务器必须也通过 TLS 实现 DNS，以便为需要严格隐私的客户端提供隐私 [.. .]。”此要求意味着必须支持基于 TCP 的 DNS，以防消息大小大于路径 MTU。
实验规范 [RFC8162] 描述了一种通过 DNS 在 S/MIME 系统中验证用户 X.509 证书的技术。该文件指出，新的实验性资源记录类型预计会携带大量有效载荷，因此建议“应用程序应该使用 TCP——而不是 UDP——来执行对 SMIMEA 资源记录的查询”。
信息文档 [RFC8324] 简要讨论了 DNS over TCP 在整个 DNS 历史中的共同作用和挑战。
实验文档 [RFC8467] 提醒实现者在使用 EDNS(0) 填充选项人为增加 DNS 消息大小时，在计算填充长度时考虑底层传输协议（例如 TCP）。
提议的标准 [RFC8482] 描述了 DNS 服务器可以响应 ANY 类型的查询的替代方式，这些查询有时用于在 DDoS 攻击中提供放大。规范指出，响应者的行为可能会有所不同，具体取决于传输方式。例如，最小大小的响应可以通过 UDP 传输使用，而完整的响应可以通过 TCP 给出。
信息文档 [RFC8483] 描述了一个测试平台环境，该环境突出了一些 DNS-over-TCP 行为，包括涉及数据包分段和 TCP 流组装的操作要求的问题，以便进行 DNS 测量和分析。
提议的标准 [RFC8484] 定义了一种通过 HTTPS 发送 DNS 查询和响应的协议。本规范假设底层安全层和传输层分别使用 TLS 和 TCP。DoH 自称是一种更类似于隧道机制的技术，但在某种意义上，即使不是直接的，也可能暗示 DNS over TCP。
提议的标准 [RFC8490] 使用新的 OPCODE 更新了基本协议规范，以帮助管理持久会话中的有状态操作，例如 DNS over TCP 可能使用的那些操作。
信息文档 [RFC8501] 确定了动态 DNS 的潜在运营挑战，包括拒绝服务威胁。该文档建议 TCP 可能提供一些优势，但更新主机需要明确配置为使用 TCP 而不是 UDP。
信息文档 [RFC8806] 描述了如何获取和操作根区域的本地副本，并举例说明了如何使用 DNS-over-TCP 区域传输从权威来源中提取。
Best Current Practice 文档 [RFC8906] 讨论了许多 DNS 操作失败场景以及如何避免它们。这包括涉及 DNS-over-TCP 查询、EDNS over TCP 和测试方法的讨论，其中包括关于验证 DNS-over-TCP 功能的部分。
Best Current Practice 文档 [RFC8932] 向 DNS 隐私服务运营商介绍了隐私注意事项。这些机制有时包括 TCP 的使用，因此容易受到信息泄露的影响，例如基于 TCP 的指纹识别。本文档还引用了本文档的早期草稿版本。
Internet 标准 [RFC8945] 建议客户端在收到截断的 TSIG 消息时使用 TCP。