截断与回退是怎么回事
DNS 传统上跑在 UDP 53 上，单个响应长度受限；当答案解析后装不下时，服务器会在响应里置 TC 位，只把能容纳的部分返回，同时客户端看到 TC=1 就改用 TCP 53 重新发起同一次查询，直到拿到完整答案。这条链路是标准行为而不是异常，多记录域名、DNSSEC 签名、带大量附加记录的响应最容易触发，抓包中表现为「一条 UDP 查询、一条 TCP 查询」成对出现。
基本信息
| 适用平台 | Wireshark / tshark，Linux 与 Windows 客户端均适用 |
|---|---|
| 关键字段 | dns.flags.truncated |
| 涉及端口 | udp.port == 53 与 tcp.port == 53 |
| 触发条件 | 响应长度超过当前 UDP 承载上限，且未协商到足够大的尺寸 |
典型使用场景
- 防火墙只放行 UDP 53 时的解析间歇失败排查
- 多记录域名解析结果不完整，确认是否为截断所致
- 统计回退比例，评估是否值得调整 EDNS0 协商尺寸
- 对比 UDP 与 TCP 两条路径的响应时间，定位哪段更慢
- 在 DNSSEC 场景中确认签名是否把响应推过了 UDP 上限
- 为应用侧「偶尔拿不到全部地址」的反馈寻找证据
配对观察
配对观察
dns.flags.truncated == 1 # 先捞出被截断的响应
tcp.port == 53 # 看回退到 TCP 的那一次查询
# 两条件结合同一域名与相近时间戳，即为一次完整的回退
# 回退后仍截断 → 说明响应确实超过上限，而非协商值偏小观察项读法
| 观察项 | 含义 | 处置方向 |
|---|---|---|
| UDP 响应 TC=1 | 响应被截断 | 后续应出现同域名的 TCP 查询 |
| 有线 TCP 53 查询 | 客户端正常回退 | 确认防火墙与策略未拦截 TCP 53 |
| 只有 UDP 无 TCP | 回退未发生或抓包点看不到 | 检查过滤规则与抓包位置是否覆盖到对端 |
| TCP 响应仍截断 | 响应超出承载上限 | 属正常上限行为，与中间设备策略无关 |
回退是标准动作，看到 TCP 53 流量时不要当作异常流量拦截；把 TCP 53 关掉的策略会直接表现为解析间歇失败。
EDNS0 已经协商到较大尺寸仍然置 TC 位，说明这条响应确实超过了协商上限，方向应从记录数量或签名体积上去找，而不是继续调大协商值。