DNS 小查询正常却偶发超时：用 dig 对照 UDP、TCP 与截断回退

发布日期：2026-10-29。

适用场景

某台主机能解析常见网站，但部分 DNS 查询偶尔超时，或者更换网络后恢复，这时只检查 UDP 53 端口可能遗漏线索。本教程使用 dig 向同一台获准使用的 DNS 服务器发送少量查询，对照 UDP、TCP 和响应截断后的回退行为。

适合在 Linux 运维终端执行。最终成果是一组可以交给网络或 DNS 管理员复核的查询记录，而不是直接修改服务器配置。示例查询公开域名与根区记录，不需要账户或密钥。

原理：DNS 也需要 TCP

DNS 经常使用 UDP，但不能因此把 TCP 当作可有可无。响应无法完整装入允许的 UDP 消息时，服务器可以设置截断标志，客户端再使用 TCP 获取完整结果。相关实现要求见 IETF RFC 7766。

dig 默认会在收到截断的 UDP 响应后尝试 TCP。如果只看最终答案，可能没意识到发生过传输方式切换。本教程先临时禁止自动回退观察 UDP，再主动使用 TCP，最后恢复默认回退行为进行比较。

这里检查的是客户端到所选 DNS 服务器的路径。即使客户端使用 UDP，该服务器查询上游时也可能使用 TCP；仅凭本机结果不能判断上游的全部行为。

准备工作

准备已经安装 dig 的 Linux 终端。先查看版本：

dig -v

如果命令不存在，通过所用发行版的官方软件仓库安装包含 dig 的工具包。不同发行版包名不同，不要从不明下载站获取单个可执行文件。

确认你获准查询的 DNS 服务器 IP，并在交互提示中输入。这里使用服务器地址而不是主机名，避免查询目标本身还需要 DNS 解析。

read -r -p '请输入获准使用的 DNS 服务器 IP：' dns_server

dns_server 保存实际输入的地址。下文的 example.com. 是公开保留示例域名，结尾的点表示完整域名；单独一个点表示 DNS 根区。它们都不需要替换成内部域名。

分步骤操作

第一步：对照小响应的两种传输

dig -r @"$dns_server" example.com. A +notcp +ignore +bufsize=1232 +time=3 +tries=1
dig -r @"$dns_server" example.com. A +tcp +bufsize=1232 +time=3 +tries=1

-r 用于忽略个人 dig 配置文件，使比较更容易复现。+notcp 从 UDP 开始，+ignore 在收到截断响应时不自动改用 TCP；第二条的 +tcp 则直接使用 TCP。+time=3 设置查询等待时间，+tries=1 限制 UDP 尝试次数，避免诊断命令反复等待。

+bufsize=1232 声明可接收的 UDP 消息大小，用于明确本次对照条件，不是要求系统全局调整网络设置。这些参数的准确含义见 BIND 9 的 dig 官方手册。

观察响应状态、服务器地址和答案。如果 UDP 有正常答案，TCP 却超时，已经有理由调查 TCP 查询路径；但仍不能仅凭这一组命令断定是防火墙阻断。

第二步：观察较小接收上限下的响应

dig -r @"$dns_server" . DNSKEY +dnssec +bufsize=512 +notcp +ignore +time=3 +tries=1

这次查询根区的 DNSKEY 记录，并声明较小的 UDP 接收上限，目的是增加观察到截断的机会。响应头中的标志区如果出现 tc，表示响应被截断，不能将其当作完整记录集。

是否出现截断取决于当时记录大小、服务器实现及其策略，不保证每次都出现。服务器也可能拒绝某类查询，或返回解析失败；这些结果应原样记录，不应为了得到预想现象而修改安全策略。

+dnssec 请求返回相关 DNSSEC 数据，不代表 dig 已经完成签名验证，也不能用它单独证明答案可信。

第三步：主动使用 TCP 获取同类记录

dig -r @"$dns_server" . DNSKEY +dnssec +bufsize=512 +tcp +time=3 +tries=1

保持服务器、查询名称和记录类型不变，仅主动改用 TCP。UDP 接收大小声明不用于限制 TCP 响应的总长度。

如果前一步出现截断，而这一步能够得到完整响应，说明 TCP 路径在本次查询中可用。如果小响应的 TCP 查询正常，大响应却失败，还要考虑服务器处理、连接中断或中间设备行为，不能简单归结为端口完全关闭。

第四步：允许 dig 自动回退

dig -r @"$dns_server" . DNSKEY +dnssec +bufsize=512 +notcp +noignore +time=3 +tries=1

+noignore 允许在收到截断响应后重试 TCP。如果 UDP 响应带有截断标志，dig 通常会提示随后尝试 TCP。保留这条提示和最终响应一起看，才能理解请求经过了哪些阶段。

如果没有发生截断，就不会出现这次回退。此时直接使用 TCP 的对照结果仍然有价值，不需要人为制造网络故障。

验证方法

每组记录都保留查询时间、服务器地址、名称、类型、响应状态、截断标志和是否超时。不要只保存简短答案，因为它会省略诊断所需的响应头与说明。

UDP 和 TCP 都成功，只能证明这两次请求成功，不能排除间歇故障。UDP 成功而 TCP 连续失败时，可在另一个获准使用的客户端重复同样的小响应对照，帮助区分单机问题与共享路径问题。每组少量重复即可，不要持续高频查询。

还要分清传输结果和解析结果：域名不存在、服务器拒绝查询或服务器处理失败，都可能通过正常传输返回。收到这类状态并不等于网络超时。

常见错误

仅做 Ping 测试不能证明 DNS 的 UDP 或 TCP 查询可用。换服务器后恢复，也不能直接证明原服务器损坏，因为查询路径、访问策略和缓存同时发生了变化。

不要把根区 DNSKEY 的具体条数或响应长度写成固定验收条件，它们可能变化。两次响应的缓存剩余时间不同也很常见，应先比较状态和记录语义，不要求全文逐字一致。

本教程针对传统 DNS 查询，不适用于直接判断浏览器的加密 DNS 功能。浏览器可能使用不同的解析服务和传输协议，需要另外确认其实际配置。

安全与回退

所有参数仅作用于当前 dig 调用，不会修改系统 DNS、网卡或防火墙配置。完成查询后无需恢复系统设置，也不要为了验证猜测直接关闭防火墙。

若后续确需调整访问规则，应由负责人员限定客户端和目标服务器范围，保存原规则，并重新进行同样的 UDP、TCP 对照。分享原始输出前检查其中的实际服务器地址，按组织要求处理内部网络信息。

参考资料与转载说明

• BIND 9 官方手册：dig DNS lookup utility
• IETF RFC 7766：DNS Transport over TCP — Implementation Requirements

本文依据上述公开资料进行中文原创整理，不是逐句翻译，也不替代厂商手册。操作前请核对自己的版本、型号和备份。