基于TCP的DNS传输：操作要求

本文档更新了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 许可中的说明提供无担保。

1、 简介

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 仅对区域传输有用的误解。

1.1、 需求语言

本文档中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应该”、“不应”、“推荐”、“不推荐”、“可以”和“可选”，当且仅当它们以全部大写字母出现时，将按照BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，如此处所示。

2、 DNS over TCP的历史

运营最佳实践与 DNS 传输协议指南之间的奇怪分歧源于运营商从其他运营商、实施者甚至 IETF 收到的相互冲突的消息。有时这些混合信号是明确的；在其他情况下，相互矛盾的信息是隐含的。本节介绍了导致本文档的传奇且相互矛盾的历史的解释。本节仅供参考。

2.1、不均匀传输的用途和偏好

在最初的 DNS 规范套件中，[RFC1034] 和 [RFC1035] 明确规定 DNS 消息可以在 UDP 或 TCP 中传输，但它们也声明在一般情况下优先选择 UDP 作为查询的最佳传输。如 [RFC1035] 中所述：

“虽然虚拟电路可用于任何 DNS 活动，但数据报更适合用于查询，因为它们的开销较低且性能更好。”

另一个早期的、重要的和有影响力的文件，[RFC1123]，更明确地标记了对传输协议的偏好：

“DNS 解析器和递归服务器必须支持 UDP，并且应该支持 TCP，以发送（非区域传输）查询。”

并进一步规定：

“域名服务器可以限制它用于 TCP 查询的资源，但它不应该仅仅因为它会通过 UDP 成功而拒绝为 TCP 查询提供服务。”

在 [RFC1536] 中达到高潮，基于 TCP 的 DNS 主要与区域传输机制相关联，而大多数 DNS 查询和响应被视为 UDP 的统治。

2.2、 等待大消息和可靠性

在原始规范中，最大 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 传输在消息事务中的主导地位。

2.3、 EDNS(0)

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 流量中仍然只占很小的一部分。

2.4、 分片和截断

尽管 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]。

（免费订阅,永久学习）学习地址: Dpdk/网络协议栈/vpp/OvS/DDos/NFV/虚拟化/高性能专家-学习视频教程-腾讯课堂

更多DPDK相关学习资料有需要的可以自行报名学习,免费订阅,永久学习,或点击这里加qun免费
领取,关注我持续更新哦! !   

2.5、 “仅区域传输使用 TCP”

今天，大多数 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 管理技术相当。

2.6、 复用、流水线和无序处理

TCP 连接可以支持多个事务的想法可以追溯到 [RFC0883]，其中指出：“可以通过虚拟电路发送多个消息。”尽管更新前者的 [RFC1035] 省略了这一特定细节，但人们普遍认为 TCP 连接可用于多个查询和响应。

[RFC5966] 阐明了服务器不需要在任何传输中保留查询和响应的顺序。[RFC7766] 更新了前者，进一步鼓励通过 TCP 进行查询流水线以达到与 UDP 相当的性能。当对较早查询的响应在对较早查询的响应之前准备好时，向流水线查询发送无序响应的服务器避免了线头阻塞。

但是，由于数据包丢失，TCP 可能会遇到不同的线头阻塞问题。由于 TCP 本身强制执行排序，单个丢失的段会延迟任何后续段中的数据传递，直到丢失的段被重新传输并成功接收。

3、 DNS-over-TCP 要求