DNS解析慢不是网络差:一次应用卡顿排查实战

DNS解析慢不是网络差:一次应用卡顿排查实战

周一早上 9:10,某制造企业的 MES 系统突然被车间主管投诉"点开订单页面要转半天,有时甚至超时"。运维第一反应是带宽不够,网管怀疑核心交换机拥塞,应用开发则甩锅数据库。可奇怪的是:服务器 CPU 正常、链路利用率不高、数据库监控也没看到慢 SQL,唯独用户体感就是"系统很卡"。

这类问题最容易把团队带进一个经典误区:只盯着带宽、CPU、数据库,却忽略了应用访问的第一步--DNS 解析。很多时候,页面慢、接口慢、登录慢,根因根本不在"网络差",而在 DNS 响应异常、重试、递归超时或者错误的转发链路。

今天就用一个真实排查思路,拆解"应用卡顿其实是 DNS 解析慢"这种高频故障。

一、故障现象:业务慢,但传统指标都正常

现场症状通常长这样:

• MES、ERP、OA 打开首页明显变慢
• 同一个系统,有些终端慢,有些终端正常
• ping 目标服务器延迟不高
• 带宽利用率不到 30%
• 服务器资源正常,没有明显瓶颈
• 用户刷新几次后偶尔又恢复

如果你只做下面这些检查:

ping app.internal.local
traceroute app.internal.local
top
iftop

大概率会得到一个错误结论:

"链路没问题,服务器也没问题,可能是用户电脑卡。"

问题在于,应用访问之前往往先要做域名解析。如果 DNS 查询慢了 2~5 秒,即使后续 TCP 建连、HTTP 请求都很快,用户仍会感知到"系统响应慢"。

二、为什么 DNS 慢会表现成"整个系统都卡"

一个典型访问流程如下:

1. 客户端先查域名
2. 拿到 IP 后发起 TCP 三次握手
3. 建立 TLS 会话
4. 发 HTTP/HTTPS 请求
5. 应用返回数据

也就是说,只要 DNS 阶段延迟很高,整个请求链路前面就会多出一段"黑洞等待时间"。

更麻烦的是,DNS 问题经常呈现以下特征:

• 间歇性:某些请求快,某些请求慢
• 看起来像应用问题:因为用户只会说"系统卡"
• 普通监控抓不到:很多 NMS 只看 ping、端口存活,不看 DNS 事务耗时
• 容易误判为链路抖动:因为最终表现是页面转圈

三、第一步:先判断是不是 DNS 问题

遇到"业务慢但基础网络正常"的情况,先别急着抓全量大包,可以先做三组快速验证。

1. 用 nslookup / dig 直接测解析耗时

nslookup mes.company.local

或者:

dig mes.company.local

重点不是只看有没有解析成功,而是看:

• 查询耗时是否明显偏高
• 是否发生重试
• 是否偶尔超时
• 是否返回多个异常地址

如果你想更直观地看耗时:

dig mes.company.local @10.10.1.53

重点观察输出中的 Query time。

正常内网 DNS 往往在几毫秒到几十毫秒之间。如果你看到几百毫秒、上千毫秒,甚至超时重试,方向就很明确了。

2. 对比直连 IP 是否正常

如果应用支持直接 IP 访问,可以让现场临时测试:

• 用域名访问是否慢
• 用 IP 访问是否明显变快

如果 IP 访问快、域名访问慢,基本可以锁定在解析链路。

3. 抓客户端本地 DNS 查询

在客户端执行:

tcpdump -i any port 53 -nn

如果看到同一个域名查询出现:

• 多次重复请求
• 首次无响应后重发
• 查询发往错误的 DNS 服务器

那问题已经很接近根因了。

四、真实排查路径:慢不在应用,而在 DNS 转发

这次案例里,最终我们发现故障点根本不在 MES 系统,而在分支 DNS 转发配置。

排查过程是这样的:

阶段 1:应用和服务器侧排除

先看应用服务器:

top
vm_stat
netstat -an | grep 443

结果:

• CPU 正常
• 内存正常
• 监听端口正常
• 连接数没有堆积

数据库侧也没有出现慢查询暴涨。

阶段 2:网络链路排除

再看交换机、出口、核心链路:

• 端口无 error/drop 激增
• 广播率正常
• 上联带宽富余
• 服务器 ping 延迟稳定

说明真正的数据转发并不拥堵。

阶段 3:抓访问前的 DNS 行为

我们在一台故障终端抓包,过滤条件直接锁定 DNS:

tcpdump -i any host 10.10.1.53 and port 53 -vv

很快就看到异常:

• 客户端发出 DNS 查询后,本地 DNS 服务器没有立即响应
• 约 2 秒后客户端发起重试
• 再过 2 秒,DNS 才返回结果
• 解析成功后 TCP 建连和业务请求都非常快

这说明真正拖慢用户体验的,就是前面的 DNS 等待时间。

五、抓包里重点看什么

如果你用 Wireshark 看这类问题,建议重点关注这几类信息。

1. DNS Query / Response 间隔

过滤条件:

dns

重点看:

• Query 和 Response 的时间差
• 是否同一事务出现重复查询
• 是否先发到一个 DNS 服务器,超时后切到另一个

2. Retransmission / Duplicate Query

有些客户端在 DNS 未及时响应时会重发。你会看到:

• 同一个 Transaction ID 或相同 Query Name 重复出现
• 多个 DNS server 之间轮询尝试

这通常意味着:

• DNS 服务器性能不足
• DNS 转发链路超时
• 上游递归服务异常

3. NXDOMAIN / SERVFAIL / REFUSED

如果抓包里出现这些响应码,就不能只说"慢",而要继续追根:

• NXDOMAIN: 域名不存在
• SERVFAIL: 服务器内部失败或递归失败
• REFUSED: 被策略拒绝

这些返回码往往能直接告诉你问题不在客户端,而在 DNS 服务链路本身。

六、最常见的几个根因

这类 DNS 慢故障,现场最常见是以下几种。

1. 分支 DNS 转发器配置错误

例如把请求先转发到一个已经废弃的上游 DNS,导致每次先等超时,再走备用服务器。

现象就是:

• 第一次慢
• 后续偶尔正常
• 用户感觉"有时卡有时不卡"

2. DNS 服务器性能不足

虚拟机资源紧张、递归缓存命中率差、并发请求过多,都会导致响应时间拉长。

3. ACL / 防火墙拦截 UDP 53 或大包回包

尤其是跨 VLAN、跨区域访问时,有些策略只放通了一部分流量,导致 DNS 返回不完整或需回退 TCP 查询。

4. 错误的本地 Hosts、GPO 或客户端 DNS 配置

部分终端指向了错误的 DNS 服务器,于是同一个业务系统有人快、有人慢。

5. 上游公网 DNS 不稳定

内网业务如果错误依赖公网 DNS 或跨运营商解析,在高峰期特别容易抖动。

七、解决动作怎么落地

这次案例最终的修复动作并不复杂:

1. 清理失效的 DNS 转发器配置
2. 调整主备 DNS 顺序
3. 对核心业务域名启用本地缓存优化
4. 检查分支到主数据中心的 UDP/TCP 53 放通策略
5. 对关键业务域名建立解析耗时监控

修复后再次验证:

dig mes.company.local @10.10.1.53

查询时间从 2200ms 左右降到了 18ms,用户访问恢复正常。

这类问题最怕的不是难,而是根因藏得深,现象却像所有层都可能有问题。

八、为什么普通日志经常抓不到

很多团队会问:为什么应用日志里看不出来?

原因很简单,应用日志通常只记录:

• 接口处理耗时
• 数据库耗时
• 业务异常码

而 DNS 解析通常发生在更前面,尤其在客户端或中间件层完成。于是你会看到:

• 后端接口耗时正常
• 用户却反馈页面打开慢

这就是为什么只看应用日志,很容易误判。

九、排查这类问题的推荐方法

如果你的网络环境规模已经比较大,人工临时抓包不够用,建议把 DNS 事务放进持续可观测体系里。至少要具备:

• 能看到 DNS 查询/响应耗时
• 能还原请求来自哪个终端、去了哪个 DNS 服务器
• 能关联应用访问前后的网络行为
• 能回看故障发生时段的流量证据

像 AnaTraf 这类网络全流量分析工具,适合处理这种"不是断网,但就是业务慢"的灰色故障。它的价值不在于替代 DNS 服务器日志,而在于把客户端、DNS、TCP、应用请求放到一条时间线上,让你知道慢到底发生在哪一跳。对制造、校园、医院这类分支多、终端杂、应用链长的环境尤其有用。

十、结语

当用户说"系统卡",千万别条件反射只盯服务器和带宽。

很多时候,真正的问题发生在业务请求还没开始之前--DNS 解析就已经把时间耗掉了。

所以以后再遇到:

• 页面慢
• 登录慢
• 接口偶发超时
• ping 正常但业务不顺

记得先问自己一句:

这是网络差,还是 DNS 在偷偷拖后腿?

这个问题问对了,你排障速度至少能快一倍.