超时与重试的节奏
查询发出后没有响应时，客户端与解析器都按各自的节奏处理：先等一个超时窗口，重发一次或几次；再不行就改用 TCP 传输，或者切换到名单里的下一台服务器。抓包的价值在于把这套节奏显性化——时间线上能直接看到「发出、等待、再发」的间隔，据此判断超时窗口有多长、是否已切换到备用路径。需要记住的是域名解析没有连接概念，所谓重传其实是重新发起一次查询。
基本信息
| 适用平台 | Wireshark / tshark，客户端与解析器两侧均可观察 |
|---|---|
| 观察维度 | 同一查询名的报文时间间隔、传输方式变化、目标服务器变化 |
| 注意点 | 重发属于新查询，查询标识会变化 |
| 常见变化 | UDP 无响应后改用 TCP，或转向备选服务器 |
典型使用场景
- 解析偶发变慢，量化等待窗口在整体延迟中的占比
- 确认客户端是否会切换到备用服务器，验证冗余配置有效性
- 排查只放行 UDP 不放行 TCP 造成的间歇失败
- 对比不同客户端实现的超时策略差异
- 为解析器超时参数调整提供实测依据
- 区分「链路丢包」与「服务端不响应」这两类等待
观察要点
观察要点
# 首查发出 → 约数秒无响应 → 重发或切换传输方式
# 不同实现窗口不同，以实测间隔为准
dns.time > 1 # 筛出较慢的 DNS 应答作起点
# 重发时查询标识通常变化，属新查询而非重传
# 切换到 TCP 后仍无响应 → 故障在链路或服务端策略时间线逐段读法
| 时间线片段 | 含义 | 下一步 |
|---|---|---|
| 发出后长时间静默 | 等待超时窗口 | 确认窗口长度是否与业务容忍度匹配 |
| 同一名字再次出现 | 重发或切换服务器 | 看目标地址是否变化以区分两者 |
| 改走 TCP 传输 | UDP 路径不通或响应过大 | 检查 TCP 是否被策略拦截 |
| 多台服务器依次尝试 | 冗余机制生效 | 确认切换顺序与超时配置合理 |
单点抓包只能看到本机行为；要看清上游分支，需要在解析器侧同样采集。
两次查询之间应用可能已经超时返回错误，判断影响时要按应用的等待设定核对，而不是只看抓包间隔。