4. 讨论 (Discussion)

在没有 EDNS0 (Extension Mechanisms for DNS 0 [RFC6891]; 见下文) 的情况下, 任何需要发送超过 512 字节限制的 UDP 响应的 DNS 服务器, 其正常行为都是截断响应, 使其适应该限制, 然后在响应头中设置 TC 标志. 当客户端收到这样的响应时, 它会把 TC 标志视为应改用 TCP 重试的指示.

RFC 1123 还说:

... 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.

DNSSEC [RFC4033] 的既有部署已经表明, 在 512 字节边界处发生截断现在已很常见. 例如, 来自使用 NextSECure 3 (NSEC3) [RFC5155] 的 DNSSEC 签名区域的 Non-Existent Domain (NXDOMAIN) (RCODE == 3) 响应, 几乎总是大于 512 字节.

自 DNS 最初的核心规范编写以来, DNS 扩展机制已经被引入. 这些扩展可用于表明客户端已准备好接收大于 512 字节的 UDP 分组. 兼容 EDNS0 的服务器在收到来自兼容 EDNS0 客户端的请求时, 可以发送最大达到该客户端所公告缓冲区大小的 UDP 分组, 而无需截断.

然而, 传输超过路径 MTU 大小的 UDP 分组会导致 IP 分组分片, 而分片在许多情况下已被发现并不可靠. 许多防火墙通常会阻断分片 IP 分组, 一些防火墙也没有实现重组分片分组所需的算法. 更糟的是, 一些网络设备会故意拒绝处理包含 EDNS0 选项的 DNS 分组. [RFC5625] 中讨论了与 UDP 传输和分组大小有关的其他问题.

Internet 核心中最常见的 MTU 约为 1500 字节, 而 DNSSEC 签名响应甚至经常超过这个限制.

RFC 1123 所预见的未来已经到来, 而唯一可能解决分组大小问题的标准化 UDP 机制已被证明并不充分.