什么时候要用 +tcp
DNS 主要走 UDP 53，但响应超过客户端通告的缓冲区大小时，服务器会在响应里置 TC（截断）标志，客户端改用 TCP 53 重新查询完整结果。dig +tcp 就是直接强制走 TCP：它能一次性验证「TCP 53 是否被防火墙放行」，这在企业网络里是最常见的拦截点之一——只放行 UDP 53 的环境下，普通查询看似正常，涉及 DNSSEC 或大量记录的响应就会失败或反复重试。
基本信息
| 适用平台 | dig（BIND 9 工具集，Linux/macOS） |
|---|---|
| 相关参数 | +tcp 强制 TCP、+bufsize=512 压低 UDP 缓冲触发截断、+ignore 忽略截断继续输出 |
| 触发截断的条件 | 响应大于 EDNS0 通告的缓冲大小（默认通常 1232 或 4096，取决于客户端与服务端） |
| 判据 | 响应 flags 中出现 tc 表示已被截断 |
| 协议依据 | RFC 1035：TC 标志与 TCP 回退机制 |
典型使用场景
- UDP 查询正常但某些域名解析超时：验证 TCP 53 是否被防火墙拦截
- DNSSEC 验证失败：签名相关的响应普遍较大，需要 TCP 回退可用
- 排查多记录或长 TXT 记录解析异常：先确认是否存在截断
- 压测或故障演练后回归验证：确认两条传输路径都可用
- 与安全策略对照：确认网络设备是否只放行 UDP 53
TCP 与截断测试
TCP 与截断测试
dig +tcp example.com # 强制走 TCP 53
dig example.com | grep -o ' flags: [^;]*' # 检查响应里是否有 tc 标志
dig +bufsize=512 example.com # 人为压低 UDP 缓冲，触发截断
dig +ignore example.com # 忽略截断标志，强制输出（可能不完整）
dig +tcp +noall +answer example.com # 只看答案段，验证 TCP 路径返回的内容
dig +time=2 +tries=1 +tcp @10.0.0.53 example.com # 逐台验证内网 DNS 的 TCP 可用性现象与含义
| 现象 | 含义 | 下一步 |
|---|---|---|
| 响应含 tc 标志 | UDP 响应被截断，客户端应改走 TCP | 确认 TCP 53 可达，否则解析会失败或反复重试 |
| +tcp 超时但 UDP 正常 | TCP 53 被防火墙或安全组拦截 | 放行 TCP 53，或修正安全设备策略 |
| 两者都超时 | 53 端口整体不可达 | 查网络可达性与上游服务器地址 |
| +tcp 返回内容比 UDP 多 | 典型的截断回退场景 | 确认 EDNS0 缓冲大小设置是否过小 |
| +bufsize=512 后大量截断 | 客户端通告缓冲偏小 | 检查 EDNS0 配置与中间设备是否剥离 OPT 记录 |
企业防火墙只放行 UDP 53 不放行 TCP 53 时，症状往往不是「全都不通」，而是大响应域名偶发失败或持续重试，很容易被误判为「DNS 服务器不稳定」。