DNS小查询正常但大响应超时：EDNS、UDP分片与TCP回退排查指南
DNS小查询正常但大响应超时：EDNS、UDP分片与TCP回退排查指南
先确认症状与响应大小相关
对同一权威服务器或递归解析器执行小响应和大响应查询：
dig @192.0.2.53 example.com A
dig @192.0.2.53 example.com DNSKEY +dnssec
dig @192.0.2.53 example.com TXT记录状态、flags、MSG SIZE、SERVER、Query time 和是否超时。如果所有类型都失败，先检查一般可达性、ACL、委派和服务状态；只有小响应稳定而大响应失败，才重点进入尺寸/传输排查。
保存一张对照矩阵
至少测试以下组合：
dig @192.0.2.53 example.com DNSKEY +dnssec
dig @192.0.2.53 example.com DNSKEY +dnssec +tcp
dig @192.0.2.53 example.com DNSKEY +dnssec +bufsize=1232
dig @192.0.2.53 example.com DNSKEY +dnssec +noedns1232 这里只是常见诊断值，不是对所有网络的万能配置。将每组的响应大小、TC、UDP/TCP 和结果并排记录，能快速区分 EDNS 兼容、UDP 分片和 TCP 回退问题。
DNS为何同时使用UDP和TCP
DNS 常用 UDP 提高效率，但完整 DNS 实现也必须支持 TCP。RFC 7766 明确要求通用 DNS 实现支持两种传输；权威、递归/转发器和 stub resolver 任一环节不支持 TCP，都可能让大响应解析失败。
TCP 不是只用于区域传送。截断响应、较大 DNSSEC 答案和运维策略都可能使用 DNS over TCP，因此只开放 UDP/53 的防火墙规则是不完整的。
原始512字节限制与EDNS
传统 DNS over UDP 的消息大小受 512 字节限制。EDNS(0) 通过 OPT 伪资源记录让请求方声明它能够接收的 UDP payload size，并提供 DNSSEC DO 位等扩展能力。
声明的是接收能力上限，不是要求服务端必须返回该大小，也不是路径 MTU 探测结果。解析器声称能接收 4096 字节，不代表中间所有链路都能可靠转发对应 UDP 数据报。
如何识别EDNS协商
dig 输出的 OPT PSEUDOSECTION 会显示 EDNS 版本、flags 和 UDP size。对比带 EDNS 与 +noedns 查询：
dig @192.0.2.53 example.com A +edns=0
dig @192.0.2.53 example.com A +noedns若带 EDNS 超时而无 EDNS 成功，可能有旧式中间设备或服务端错误处理 OPT；若无 EDNS 得到 TC 后 TCP 成功，说明基本回退链可用。不要仅因一次失败就永久关闭 EDNS，DNSSEC 等能力依赖它提供的扩展信号。
UDP缓冲区越大不一定越好
较大 EDNS UDP size 能减少因 512 字节限制而触发 TCP，但也更容易超过路径 MTU并产生 IP 分片。RFC 6891 提醒，过大的声明可能被中间盒丢弃并造成无望重传。
调整时从可测路径和真实答案大小出发。服务端的最大 UDP 响应、解析器声明值和网络 MTU需要共同考虑；不要把值直接设到协议最大范围。
IP分片为何容易丢失
大 UDP 数据报超过路径 MTU 后可能被拆成多个 IP 分片。任何一个分片丢失，接收端都无法重组完整 DNS 消息。部分防火墙、NAT、负载均衡或 DDoS 防护会丢弃非首片，或无法正确跟踪分片状态。
RFC 8900 将 IP 分片视为脆弱机制。DNS 可通过更小的 EDNS 响应上限来减少分片，让超大答案在 DNS 层截断并改用 TCP。
TC位表示什么
DNS 响应头的 TC（Truncated）位表示消息被截断。解析器看到 TC 后应通过 TCP 重新查询以获得完整答案。用 dig 检查 flags：
flags: qr aa tc rdTC 不是 NXDOMAIN，也不是完整答案。应用或自研 stub 若忽略 TC 并继续使用部分数据，会产生间歇性缺记录或验证失败。
+tcp成功能证明什么
默认 UDP 查询超时而 +tcp 成功，强烈说明权威数据和基本名称路径存在，问题集中在 UDP 尺寸、分片或回退触发。但它不能单独证明所有递归解析器会正确回退，也不能排除某条路径只对测试客户端开放 TCP。
应从用户实际使用的递归服务器重复测试，并分别验证客户端→递归、递归→权威两段链路。
+tcp也失败时查TCP/53
若 TCP 查询连接拒绝或超时，检查权威/递归服务是否监听 TCP/53，主机防火墙、云安全组、网络 ACL、负载均衡和 NAT 是否允许双向 TCP。
ss -lntup | grep ':53'不要只确认 SYN 能到达。还要验证三次握手、DNS 长度前缀消息、响应返回和连接复用。TCP 成功率也需要容量和超时监控。
防火墙常见的错误规则
典型错误包括：只允许 UDP/53；只允许客户端到服务器的 TCP SYN 却阻断返回流量；分片规则只放行首片；对 EDNS OPT 误判；状态表容量不足；DDoS 清洗对大响应限速。
先做规则命中计数和短时、限定目标的抓包，再修改精确规则。不要清空整套防火墙，也不要把 53 端口无限制开放给不需要的来源。
递归器、转发器和权威链要分段
客户端通常查询递归器，递归器可能再经过一个或多个 forwarder 才到权威服务器。任一段的 UDP 大小、TCP 支持或超时配置不同，最终都可能表现为客户端 SERVFAIL。
逐段直查：客户端到递归、递归主机到权威、转发器到权威。记录每段源 IP 和网络命名空间，避免在管理机成功就认为生产递归路径也正常。
DNSSEC为何更容易触发问题
DNSSEC 会增加 DNSKEY、RRSIG、NSEC/NSEC3 等数据，响应通常比普通 A 记录大。启用签名后才出现超时，可能是传输尺寸问题，而非签名本身错误。
同时仍需用验证工具检查 DS/DNSKEY/RRSIG 链。传输失败和密码学验证失败都能造成 SERVFAIL，不能用“DNSSEC 响应大”替代完整验证。
TXT与HTTPS记录也可能放大响应
多个 TXT 字符串、邮件安全记录、大型 HTTPS/SVCB 参数、多个 AAAA 和 Additional section 都会增加响应。按 RR type 测量真实线长，避免只凭文本字符数估算。
DNS 不是存储大文件的渠道。能拆分到更合适服务的数据不应无限堆进一个 RRset，但修改记录结构前要遵守对应协议规范。
IPv4正常IPv6失败怎么查
IPv6 的分片由源节点完成，中间路由器不会像 IPv4 那样执行分片。路径 MTU、ICMPv6 Packet Too Big 被过滤、IPv6 ACL 或权威 AAAA 路径差异，都可能让同一大响应只在 IPv6 失败。
分别强制 IPv4/IPv6 查询并记录源与目标：
dig -4 @ns.example.net example.com DNSKEY +dnssec
dig -6 @ns.example.net example.com DNSKEY +dnssec不要通过全局禁用 IPv6 结束排障；应修复对应路径或明确受控降级。
Anycast会制造节点差异
权威或递归服务使用 Anycast 时，不同客户端可能到达不同节点、网络或防火墙策略。一个地区成功、另一个地区失败，需记录实际服务节点标识和路由路径。
确保各节点的软件版本、EDNS/TCP 配置、证书以外的 DNS 数据、MTU 和容量一致。不要只在离运维机最近的节点验收。
负载均衡和NAT的隐藏影响
DNS 负载均衡器需要同时正确处理 UDP 和 TCP，并保持响应回到相应客户端。仅为 UDP 配置虚拟服务，或 TCP 后端健康检查缺失，会让 TC 回退失败。
NAT 设备还可能在高并发下耗尽状态或错误处理分片。检查真实连接表、丢包计数和后端选择，不要只看前端 VIP 在线。
EDNS版本与FORMERR/BADVERS
EDNS 不兼容不一定表现为静默超时，也可能返回 FORMERR 或扩展错误码。对比 OPT 是否存在、RCODE 和服务端日志。RFC 6891 规定了不支持版本的处理方式，客户端也可在受控条件下尝试无 EDNS 回退。
若 DNSSEC 或其他必要选项依赖 EDNS，不应把无 EDNS 作为永久解决方案。
服务端限制响应大小的作用
权威和递归软件通常允许限制 UDP 响应上限。较小上限可减少 IP 分片，超出时设置 TC 并引导 TCP。但数值过小会增加 TCP 负载，数值过大则继续承担分片风险。
修改前统计响应尺寸、TCP 查询比例、连接容量和路径特征。分批调整并观察 TC、TCP 成功率、延迟与 SERVFAIL，不能只追求 UDP 命中率。
TCP容量也要纳入设计
从 UDP 转向 TCP 会增加连接状态、握手与资源消耗。RFC 7766 还讨论连接复用和流水线，以降低开销。服务端需要合理的连接上限、空闲超时、队列和抗滥用能力。
不要因为担心资源就阻断 TCP/53；这会破坏标准 DNS 互操作。应通过容量规划、速率控制和监控解决。
抓包如何证明分片或TC
在授权环境中对单个客户端、服务器和短时间窗口抓取 UDP/TCP 53，查看请求 EDNS size、响应总长、IP fragmentation、缺失分片、TC 位和后续 TCP SYN。
两端同时抓包最有价值：服务端已发送但客户端未收到，问题在路径；客户端收到 TC 但没有发 TCP，问题在 resolver；TCP 已发但握手无响应，则检查 ACL/服务监听。抓包包含查询名称，应限制访问和保存期限。
不要把所有SERVFAIL归因于MTU
SERVFAIL 还可能来自 DNSSEC bogus、上游超时、循环转发、权威不可达、格式错误和资源耗尽。尺寸问题必须由“大小相关、UDP/TCP差异或分片证据”支撑。
检查递归器日志和扩展 DNS 错误信息（若可用），不要只根据一个状态码猜测。
推荐排查顺序
1. 对比小 A 响应与大 DNSKEY/TXT 响应。
2. 对同一目标分别测试 UDP、TCP、EDNS 大小和 noedns。
3. 检查响应 MSG SIZE、OPT、TC、RCODE 与延迟。
4. 分段验证客户端、递归/转发器和权威链路。
5. 检查 TCP/53 监听与全路径 ACL。
6. 检查 UDP 分片、MTU、NAT、负载均衡和 Anycast 差异。
7. 评估服务端 UDP 上限与 TCP 容量。
8. 在多地区、IPv4/IPv6 和 DNSSEC 场景回归。
每次只改变一个尺寸或传输参数，并保存前后查询输出。
修复后的验收清单
普通与大响应均成功；TC 触发时 TCP 回退完成；UDP 分片丢失不再造成用户超时；TCP/53 只向预期来源开放且容量充足；IPv4/IPv6、不同递归器和 Anycast 节点行为一致；DNSSEC 验证仍通过；监控能区分 UDP 超时、TCP 失败和验证错误。
还应执行负向测试：阻断测试环境中的 TCP 后，较大截断响应必须被监控捕获，而不是静默返回部分数据。
常见错误
- 只测试 A 记录就宣布 DNS 正常。
- 只开放 UDP/53，认为 TCP 只用于 AXFR。
- 把 EDNS 缓冲区越调越大。
- 收到 TC 后仍把部分答案交给应用。
- 关闭 DNSSEC 来掩盖大响应传输失败。
- 清空防火墙规则而未定位具体丢包层。
- 只在一个 Anycast 节点或单一 IPv4 路径测试。
- 把所有 SERVFAIL 都归因于 MTU。
FAQ
dig加tcp成功说明权威数据没问题吗？
它证明该测试路径能通过 TCP 获得答案，但仍需验证数据正确、DNSSEC 有效，以及用户实际递归链能完成同样回退。
EDNS的UDP size是不是路径MTU？
不是。它是请求方声明可接收的 UDP payload 上限，不会自动探测中间路径 MTU，也不保证大包不会分片或被丢弃。
为什么DNSSEC启用后才失败？
DNSSEC 附加 DNSKEY、RRSIG、NSEC/NSEC3 等记录，响应变大，更容易触发截断、分片或 TCP；也可能是真正的签名链错误，两者需分别验证。
把UDP大小固定为1232就一定好吗？
不是。它是常见的保守诊断/部署取值之一，但最终应根据软件、网络路径、IPv4/IPv6 和容量测试决定，并确保 TCP 回退可靠。
TCP/53开放会不会带来攻击风险？
任何公开服务都需容量和滥用防护，但完整 DNS 实现必须支持 TCP。正确做法是合理限制、监控和扩容，而不是阻断标准传输。
总结
DNS 小查询正常而大响应失败，通常要沿“EDNS 声明→UDP 响应大小→路径分片→TC 截断→TCP 回退”逐层定位。用同一名称做 UDP/TCP、不同 bufsize、DNSSEC 和 IPv4/IPv6 对照，分段检查递归、转发器与权威链，再调整服务端 UDP 上限和 TCP 容量。只有大响应完整到达、截断能可靠回退且 DNSSEC 仍通过，修复才算完成。