DNS 响应被截断怎么办：TC 标志、EDNS0 缓冲区与 TCP 回退实战

DNS 响应被截断怎么办：TC 标志、EDNS0 缓冲区与 TCP 回退实战

摘要：DNS 查询偶尔超时、同一域名在不同网络返回结果不一致时，问题可能不是权威服务器故障，而是 UDP 响应超过路径允许的大小后被截断。本文从 DNS 报文、TC 标志、EDNS0、IPv4/IPv6 路径差异和 53/TCP 回退机制出发，给出可复现的 dig、tcpdump 与服务端配置方法。

DNS 查询通常被想象成"一问一答"：客户端发出 UDP 请求，服务器把地址记录放回响应。然而真实互联网中的 DNS 响应已经包含 DNSSEC、TXT、SVCB/HTTPS、多个 AAAA 和 CNAME 链，报文大小很容易超过传统 UDP 512 字节。只要中间链路、负载均衡器或防火墙处理不当，客户端看到的就可能是超时、SERVFAIL、解析结果缺少记录，甚至是只在某个运营商网络出现的访问故障。

本文把"响应截断"当成一个可观测的工程问题。排查时应先确认客户端到底收到了什么，再判断是权威端主动设置 TC，还是路径丢弃了大 UDP 包。理解这条边界，能够避免把 DNS 故障误判成域名未生效或缓存污染。

一、DNS 响应为什么会变大

传统 DNS over UDP 的协议约束是 512 字节，但这不是现代网络中唯一的上限。EDNS0 通过 OPT 伪记录让请求端声明可接受的 UDP 负载大小，常见值是 1232 或 4096。服务器会根据这个声明返回更大的响应，同时还要受到链路 MTU、IPv4 分片、IPv6 最小路径 MTU 和设备实现质量的共同影响。

响应大小增长通常来自四类内容。第一类是 DNSSEC 的 RRSIG、DNSKEY 和 DS，签名本身就可能占用数百字节；第二类是 TXT、SPF、DKIM 等长文本；第三类是多个地址记录与较长的 CNAME 链；第四类是 HTTPS、SVCB 等新记录携带的参数。一个只含 A 记录的域名可能一直正常，而增加邮件安全记录后突然触发截断。

DNS 响应还可能因为递归服务器附带 authority 和 additional 区域而变大。例如查询 MX 时，服务器可能同时返回目标主机的地址；查询 DNSKEY 时，响应内的签名链也会一并出现。因此不能只按"记录数量"估算报文大小，必须看实际 wire size。

二、TC 标志表达了什么

DNS 头部的 TC（Truncated）位只有一个含义：当前响应没有完整携带答案，接收方应换一种传输方式重新查询。它不等于服务器宕机，也不等于查询失败。权威或递归服务器在确认 UDP 响应放不下时，会返回一个较短的响应并置上 TC=1，客户端随后通常使用 TCP 连接 53 端口重试。

用 dig 可以直接观察这个位：

dig @1.1.1.1 example.com DNSKEY +dnssec +stats
# 查看 flags 行是否含 tc

dig @1.1.1.1 example.com TXT +bufsize=512 +stats

不同版本的 dig 会以 ;; Truncated, retrying in TCP mode. 或 flags 中的 tc 提示。为了确认服务端是否支持 TCP，可以显式执行 +tcp。如果 UDP 查询带 tc，而 TCP 查询得到完整答案，说明协议回退链路是通的；如果 TCP 也失败，就需要继续检查 53/TCP 的防火墙、监听和转发。

不要把"没有 tc"理解为"响应一定完整"。中间设备可能直接丢弃超大的 UDP 包，客户端最终只看到超时，根本没有机会收到带 TC 的短响应。此时要结合抓包和不同 bufsize 的对比，而不能只看应用日志。

三、EDNS0 缓冲区与 1232 字节经验值

EDNS0 的 UDP payload size 是请求端给出的上限，不是服务器必须使用的大小。+bufsize=1232 表示客户端希望服务器把 UDP 响应控制在 1232 字节以内；如果答案仍然更大，服务器应设置 TC 并让客户端回退 TCP。1232 这一数值常被采用，是因为它在常见 1500 字节以太网 MTU 下，为 IPv6 40 字节头和 UDP 8 字节头留下空间，避免 IP 分片。

4096 看起来更宽裕，却会增加分片概率。IPv4 分片可能被防火墙过滤，IPv6 路由器不能替终端分片，必须依赖源端的路径 MTU 发现。对于跨运营商或经过隧道的路径，允许 4096 字节 UDP 并不总能提升成功率。运营环境应根据实测路径、DNSSEC 使用情况和设备兼容性选择值，而不是盲目追求最大缓冲区。

递归服务器还可能对客户端声明的值做上限限制。例如客户端发 4096，服务器仍按 1232 生成响应。观察时应同时记录请求 OPT、响应实际长度和 TC 位，三者缺一不可。dig +noedns 可以模拟旧客户端，帮助定位是否是 EDNS0 协商导致的差异。

四、UDP 有答案、TCP 却失败的常见原因

第一类原因是只放通了 53/UDP。很多安全组规则只创建了 UDP 入站，平时小响应完全正常，遇到 DNSSEC 或 TXT 查询才暴露问题。第二类原因是四层负载均衡只把 UDP 转给后端，TCP 监听没有配置同样的后端池。第三类原因是 NAT 设备对 TCP 53 做了特殊拦截，或者连接建立后空闲超时过短。

第四类原因是权威服务器只在某个地址族上监听。客户端优先走 IPv6 时，UDP 请求可能到达 IPv6 地址，而 TCP 回退却连接了另一个地址，表现为"同一域名 UDP 正常、TCP 超时"。应分别使用 dig -4 +tcp 和 dig -6 +tcp 验证。

第五类原因是递归服务器的 TCP 回源策略不完整。客户端与递归之间可以建立 TCP，但递归服务器去权威端仍然因为防火墙或连接数限制失败，最终返回 SERVFAIL。此时要在递归服务器日志里区分 client-side fallback 和 upstream retry，不能只盯着客户端。

五、权威服务器的配置检查

权威服务至少要保证 UDP 和 TCP 53 端口都监听，并由同一套区域数据响应。BIND、Knot、PowerDNS 等软件的配置方式不同，但检查思路一致：查看监听套接字、确认防火墙策略、从多个网络发起 +tcp 查询，再核对响应中的 SOA、DNSKEY 和 serial。

ss -lntup | grep ':53'
 dig @ns1.example.net example.com SOA +tcp +stats
 dig @ns1.example.net example.com DNSKEY +tcp +dnssec +stats

区域传送使用 TCP 并不意味着普通查询可以忽略 TCP。AXFR/IXFR 只验证了某一类长连接场景，普通查询的 ACL、速率限制和连接复用仍可能单独出错。若前置防火墙启用了 DNS response rate limiting，要确认它不会把合法的 TCP 回退误判成攻击。

如果使用 Anycast，要在每个节点执行相同测试。某一 POP 放通 UDP 但未放通 TCP，会造成按地理位置变化的随机故障。比较不同节点的 SOA serial 和 TCP 连接耗时，能快速判断是数据不一致还是传输层缺陷。

六、递归服务器如何处理回退

现代 stub resolver 通常会在收到 TC 后自动重试 TCP，但应用并不一定直接使用系统 stub。浏览器、容器运行时、DNS 代理和服务网格都可能内置解析器。排查时要确认产生查询的实际组件，并观察它是否遵循 RFC 7766 对 DNS over TCP 的连接复用建议。

递归服务器收到客户端 UDP 查询后，若上游权威返回 TC，它会自己通过 TCP 取完整答案，再把结果按客户端能力返回。客户端与递归之间若仍是 UDP，递归服务器可能再次截断。于是一次查询包含两段独立的回退：递归到权威，以及终端到递归。任何一段的 TCP 不可达都会影响最终结果。

缓存也会掩盖问题。递归服务器缓存了完整 TCP 结果时，后续客户端看到的是小响应；缓存过期后才重新触发回退，故障就呈现为间歇性。应在低 TTL 或刚发布 DNSSEC 记录的时段观察，并记录缓存命中率、上游协议和失败原因。

七、用抓包区分截断与丢包

抓包是判断路径问题的关键。对客户端执行 tcpdump -ni any port 53，先发 UDP 查询，再发 +tcp 查询。若 UDP 报文返回且 DNS 头部 TC=1，说明服务端明确要求回退；若只有出站 UDP，没有任何入站响应，可能是分片被丢弃、ACL 拒绝或服务器没有返回。

sudo tcpdump -ni any -vv 'host 1.1.1.1 and port 53'

在 IPv4 中，过滤 ip fragments 可以发现分片；在 IPv6 中，要关注 ICMPv6 Packet Too Big 是否返回。若路径设备屏蔽 ICMP，源端无法正确降低包大小，表现为大响应持续超时。通过逐步降低 +bufsize，例如 4096、1500、1232、512，可以估计路径的可用上限。

抓包还要记录事务 ID、查询名和时间间隔。高并发环境下不能只按端口判断一问一答，否则容易把其他请求的响应误关联。对比客户端、递归和权威三处抓包，可以定位是哪一跳丢掉了大包。

八、IPv4、IPv6 与隧道的差异

IPv6 不允许中间路由器分片，端点必须依赖 PMTUD。若网络屏蔽 ICMPv6，DNS 大 UDP 响应比 IPv4 更容易失败。双栈客户端可能先通过 IPv6 访问递归服务器，失败后再切到 IPv4，用户只感受到偶发延迟增加。

VPN、GRE、VXLAN、PPPoE 等封装会减少有效 MTU。即使物理接口是 1500，隧道内层可能只有 1400 或更低。DNS 服务端若固定发送 1232 字节，经过多层隧道仍可能需要分片或触发 TC。应在真实链路上测量，而不能根据服务器网卡配置推断。

比较 dig -4、dig -6、+tcp 和不同 +bufsize 的结果，可建立一个四维矩阵。若只有 IPv6 UDP 失败，优先查 PMTUD；若两种地址族 UDP 都失败而 TCP 正常，优先查 EDNS 与设备策略；若 TCP 也失败，回到监听、防火墙和负载均衡。

九、DNS over TLS/HTTPS 是否能解决问题

DoT 和 DoH 把 DNS 查询封装在 TLS 或 HTTPS 中，传输层不再使用裸 UDP 53，因此客户端到递归服务器之间不会遇到传统 UDP 截断。但递归服务器访问权威时仍可能使用 UDP/TCP，权威端的截断问题依旧存在。加密协议解决的是观测和中间篡改问题，不会自动修复上游 TCP 不通。

DoH 还可能把多个查询放入 HTTP/2 或 HTTP/3 连接，应用看到的是 HTTP 错误或超时，DNS 层的 TC 信息被隐藏。服务端应提供 upstream protocol、fallback reason 等可观测字段，方便把 HTTP 连接问题与 DNS 回源问题分开。

在企业网络中，强制 DoH 可能绕过内部递归策略，也可能让分流规则失效。部署前应确认内部域名、DNSSEC 验证、审计和故障切换策略都能覆盖加密解析路径。

十、监控指标与告警阈值

建议为递归和权威分别监控 UDP 查询成功率、TCP 查询成功率、TC 比例、响应大小分布、SERVFAIL 比例和连接建立耗时。TC 比例突然升高通常意味着记录膨胀、DNSSEC 变更或 EDNS 配置变化；TCP 成功率下降则更像防火墙、负载均衡或容量问题。

按域名和记录类型拆分更有价值。DNSKEY、TXT、HTTPS 的大响应是预期现象，不应与 A 记录的小响应混在同一阈值中。可以用 p95/p99 响应大小触发容量预警，用 TCP fallback error rate 触发故障告警。

监控探针应覆盖多个运营商和 IPv4/IPv6。多地区 DNS 检测工具只能提供观测证据，最终仍要结合权威日志和抓包确认原因。使用 dnspup.com 的 DNS 查询功能时，可把不同地区的响应记录、TTL 和记录类型作为外部基线，再在服务端验证 TC 与 TCP 回退。

十一、典型故障的排查顺序

第一步，保存一个能稳定复现的域名、记录类型、查询服务器和时间。第二步，用默认 EDNS、+bufsize=1232、+noedns 和 +tcp 做四次对照。第三步，记录 flags、answer 数量、响应大小、TC 位和状态码。第四步，分别测试 IPv4、IPv6 以及递归服务器到权威服务器的 TCP。

如果只有大 bufsize 失败，检查路径 MTU、分片和设备上限；如果返回 TC 但 TCP 成功，协议工作正常，关注客户端是否误报失败；如果返回 TC 且 TCP 不通，检查 53/TCP 防火墙和负载均衡；如果 UDP 无响应且没有 TC，优先按丢包或 ACL 处理；如果不同地区结果不同，比较 Anycast 节点配置与运营商路径。

排查结束后要保留原始 dig 输出和抓包摘要。单纯记录"改小 EDNS 后恢复"不足以解释根因，因为这可能只是绕开了某个设备。修复应包括端口策略、MTU、服务器配置和回归测试，确保下一次 DNSSEC 或 TXT 变更不会再次触发同类故障。

十二、实践建议与结论

生产环境建议同时开放 53/UDP 和 53/TCP，采用 1232 左右的保守 EDNS0 上限，并对 TCP 回退设置容量监控。对权威 DNS 做双栈、Anycast 和节点一致性检查，对递归 DNS 记录上游协议、TC 和 SERVFAIL 的关联。发布 DNSSEC、DKIM 或 HTTPS 记录前，先测量不同网络的 wire size。

客户端排查不要只重复刷新页面。通过 dig 的四组对照、抓包和服务端日志，可以把"域名偶尔打不开"拆成截断、分片、回退、监听和路径五类可验证问题。该 DNS 查询页面适合做外部多地区观测，但真正的修复仍需要掌握协议字段和基础设施证据。

DNS 截断不是一个神秘的网络黑盒，而是一个有明确标志位和回退路径的协议事件。只要把 UDP 响应大小、TC、53/TCP、EDNS0 和路径 MTU 放在同一张排查表里，就能在记录变更、DNSSEC 启用或网络迁移后快速判断影响范围，并用可重复的测试证明修复有效。

十三、权威与递归的测试矩阵

为了避免一次偶然成功，建议建立固定的测试矩阵：至少选择两个公共递归、一个企业递归和两个权威地址，分别从 IPv4 与 IPv6 网络执行 A、AAAA、DNSKEY、TXT、HTTPS 五种查询。每条结果保存响应大小、TC、状态码、查询耗时和是否通过 TCP。矩阵的价值在于能把"某个解析器偶尔失败"与"所有路径都不能回退"区分开。

测试不应只在空闲时执行。发布 DNSSEC、切换权威、增加 DKIM 或改变 CDN 解析策略后，立即运行一次；TTL 过半时再运行一次，确认缓存刷新后仍然稳定。对于 Anycast 权威，应把每个观测到的地址写入记录，避免不同 POP 的结果被平均值掩盖。

递归服务器还要观察缓存前后差异。先用随机子域触发完整回源，再重复查询已有名称，分别记录 client-to-recursive 与 recursive-to-authoritative 的协议。若只有随机名称失败，通常与上游 TCP、区域数据或 DNSSEC 验证有关；若缓存命中也失败，才更像客户端到递归的传输问题。

十四、响应大小的工程控制

控制响应大小首先从数据建模开始。DNSSEC 密钥轮换应避免在同一时刻叠加过多旧键；TXT 记录可以拆成多个字符串，但拆分不一定降低 wire size，因为每段仍有长度字段；HTTPS 记录中的参数应去掉无效的重复项。变更前用 dig +dnssec +tcp 取原始响应，计算最大长度，再评估最差链路。

递归服务可以配置最大 UDP 响应、最小 EDNS 缓冲和 TCP 连接上限。最大值太小会让 TC 比例上升，太大则增加分片风险。更重要的是要让不同节点使用同一配置，配置中心发布后通过探针验证实际 wire size，而不是只检查配置文件是否同步。

当业务必须返回大量 TXT 或地址时，可以把数据迁移到 HTTPS API，让 DNS 只承载发现信息。DNS 适合短小、可缓存、容错优先的记录，不适合传输大块应用数据。通过分层 CNAME、短链或服务发现记录控制响应规模，通常比单纯调大 UDP 缓冲更稳妥。

十五、故障复盘应记录哪些证据

一次 DNS 截断事故的复盘至少应包含：受影响域名与记录类型、首次变化的发布时间、不同递归的响应大小、TC 比例、53/TCP 成功率、IPv4/IPv6 差异、边缘设备配置和修复后的回归结果。没有这些字段，后续只能重复"把 EDNS 调小"这种经验性操作。

还要记录客户端实现。glibc、Go resolver、Java、浏览器和容器内的本地代理对 TC 与 TCP 回退的处理不同。某些应用把 SERVFAIL 缓存几秒，某些应用直接把超时放大成页面不可用。把客户端版本纳入时间线，能解释为什么只有部分用户受影响。

最终验证应包含一次故意制造大响应的测试，例如临时增加 TXT 或使用 DNSSEC 测试区域，确认监控能看到 TC 和 TCP 回退，并在删除测试记录后恢复。通过可控演练验证，比等待下一次自然故障更可靠。

十六、面向运营的检查清单

日常检查可以压缩为八项：权威 UDP/TCP 都可达；递归支持 EDNS0；响应大于路径上限时会设置 TC；客户端收到 TC 会回退；IPv4/IPv6 都有一致结果；Anycast 节点配置一致；DNSSEC、TXT 和 HTTPS 记录变更有大小评估；监控覆盖 TC、SERVFAIL 和 TCP 成功率。

每项都应有自动化命令和阈值。例如连续五分钟 TC 比例高于历史 p99，或 TCP 回退失败率超过 0.5%，就触发告警。告警消息要带域名、记录类型、递归节点和最近一次配置变更，值班人员才能直接复现。

如果业务对解析极度敏感，可以准备备用递归或 DoT/DoH 通道，但备用路径也要测试权威回源。冗余的意义是缩小影响面，不是绕过协议基本约束。

十七、把回退测试纳入发布门禁

DNS 区域发布可以增加一个简单门禁：对变更前后分别执行默认 UDP、+bufsize=1232、+noedns 和 +tcp 查询，并比较 answer、authority、additional、TC 和 wire size。若新增记录让响应超过预设上限，发布系统应提示需要评估 TCP 回退，而不是静默上线。

门禁还要覆盖负缓存和失败响应。一个域名的 A 记录正常，不代表 DNSKEY、TXT、MX 和 HTTPS 都正常；递归服务器可能对不同类型采用不同缓存和验证路径。将这些类型纳入同一份报告，可以在业务上线前发现只有邮件、证书自动发现或 IPv6 访问会失败的隐患。

当站点使用多级 CNAME 时，应从最终权威开始测量每一段链路，记录每次跳转和响应大小。链路越长，递归服务器越可能需要额外查询，任何一段 TCP 不通都会把问题放大成最终 SERVFAIL。

排查完成后，将最小复现命令、抓包过滤器和阈值写入运行手册，并由值班人员定期演练。这样即使下一次故障发生在凌晨，也能先判断是 TC 回退、分片丢失还是权威配置错误。

十八、常见问题的回答

有人会问"把所有 DNS 查询改成 TCP 是否最安全"。TCP 能避免 UDP 分片，但会引入连接建立、状态维护和连接数上限；对小响应而言，UDP 仍然更高效。合理做法是让 UDP 承载常规查询，让 TC 触发 TCP，并为 TCP 回退设置容量和监控。

"EDNS0 关闭后恢复，是否说明 EDNS0 有问题？"通常不是。关闭 EDNS0 会把响应限制在旧的 512 字节范围，服务器更早返回 TC，客户端如果 TCP 可达就可能恢复。真正的问题往往是大 UDP 包被路径丢弃，或服务端没有正确实现回退。

"只有某一运营商失败，是不是 DNS 污染？"也不能直接下结论。运营商路径的 MTU、IPv6、递归缓存和防火墙都可能不同。应比较相同递归、不同递归、UDP/TCP 和 IPv4/IPv6 的结果，再判断是否存在篡改。

将这些问答写进运维手册，可以帮助一线人员先收集协议证据，再决定是否升级为安全事件或基础设施故障。

十九、把结果写成可审计的记录

建议为每次 DNS 变更生成一份机器可读记录，字段包括查询名、类型、递归地址、权威地址、transport、EDNS bufsize、响应长度、TC、RCODE、answer 数量和耗时。文本输出便于人工阅读，结构化字段便于趋势分析和回归比较。

当发现异常时，先把失败结果与最近一次成功结果并排保存，避免只截取错误行。对比 flags、OPT、SOA serial 和证书式 DNSSEC 记录，可以确认是数据变化、传输变化还是缓存状态变化。

经过多次运行后，能够建立每个域名的正常响应大小和 TCP 回退比例。阈值应来自历史分布并留出变更余量，不能照搬另一个区域的固定数字。这样，DNS 截断会在用户感知前被发现，修复也有可验证的完成标准。