摘要

  • TCP 是 DNS 的正常服务路径，并非只用于区域传送的例外手段。
  • EDNS 扩大了可用的 UDP 报文空间，但不能保证每条路径都能交付。
  • 就绪证据必须沿着同一查询，覆盖截断、TCP 建连、完整应答与安全复用。

最能暴露问题的事故，往往从全绿的仪表板开始。UDP/53 应答迅速，权威数据也是最新的。随后一个更大的应答带着 TC 返回。解析器建立 TCP，但服务站点的接受队列过浅，防火墙超时不适合这条连接路径，或者工作进程被慢速对端拖住。DNS 数据没有错，交付路径却没有准备好。

RFC 1035 同时规定了 53 端口上的 UDP 与 TCP 服务，并规定 TCP DNS 消息前置两个八位组的长度字段。它还要求服务器不能在等待 TCP 数据时阻塞其他工作。后来 EDNS 扩大了最初的 UDP 上限，但截断仍会改变完成同一问题所需的传输工作。

RFC 6891 允许请求方声明其能够在 DNS 环境中重组并交付的最大 UDP 负载。这是端点能力证据，不是对所有中间路径的承诺。实验室里没有出现 TC，不能因此把 TCP 从生产合同中删除。

RFC 7766 要求通用 DNS 实现支持 TCP，并把连接复用视为避免每次查询都重新建连的方法。容量问题因此不再只是端口能否打开，而是并发工作能否完成、慢连接是否拖累其他请求、关闭策略能否在保留有效会话的同时约束状态。RFC 9210 进一步明确：一次成功建连不能证明真实查询组合下的连接生命周期已经受控。