DNS解析故障排查实战：从“网络不通“到定位根因的完整方法论

DNS解析故障排查实战从网络不通到定位根因的完整方法论为什么 DNS 故障总是最难发现的那一类网络故障里DNS 问题有一个特殊的迷惑性它让你以为是别的问题。用户反馈网络断了——其实是 DNS 解析失败HTTP 请求还没发出去就挂掉了。用户反馈网站打不开——其实某个 CDN 域名解析返回了过期 IPTCP 连接超时。用户反馈系统登录很慢——其实内网 AD 域控的 DNS 响应延迟从 5ms 涨到了 800ms。SNMP 看不见 DNS 问题ping 测不出来带宽利用率也完全正常。但用户就是用不了。本文从实战角度整理 DNS 故障排查的完整方法从现象识别到工具使用到根因定位覆盖企业内网常见的 DNS 故障场景。一、快速判断是否是 DNS 问题遇到网络不通类投诉第一步先排除 DNS# 直接用 IP 访问绕过 DNScurl-vhttp://192.168.10.50:8080/health# 用 nslookup 测试解析nslookuperp.company.internal# 指定 DNS 服务器测试nslookuperp.company.internal192.168.1.1# 测试公网 DNSnslookupbaidu.com8.8.8.8判断逻辑用 IP 能访问、用域名不行 → DNS 问题内网域名解析失败、公网正常 → 内网 DNS 服务器问题内网和公网都失败 → DNS 服务器本身不可达或上游 DNS 故障解析正常但访问慢 → 不是 DNS 问题往应用层或路由层查二、DNS 排查核心工具1. nslookup / dig基础诊断# dig 查询详细信息推荐用 dig比 nslookup 信息更全digerp.company.internal 192.168.1.1# 关注输出字段# QUESTION SECTION你查询的是什么# ANSWER SECTION解析结果是什么# Query timeDNS 响应时间毫秒# SERVER实际响应的 DNS 服务器看 Query time10ms正常10-100ms可接受但值得关注100ms明显偏高可能有 DNS 服务器问题超时;; connection timed outDNS 服务器不可达# 批量测试多个域名的解析时间fordomaininerp.company.internal db.company.internal mail.company.internal;doecho-n$domain: dig$domain192.168.1.1|grepQuery timedone2. tcpdump抓 DNS 流量DNS 走 UDP 53 端口大响应会回退到 TCP 53# 抓所有 DNS 流量tcpdump-ieth0 port53-w/tmp/dns_capture.pcap# 实时显示 DNS 查询不保存文件tcpdump-ieth0 port53-n# 只抓特定客户端的 DNS 请求tcpdump-ieth0 srchost192.168.50.100 and port53在 Wireshark 里打开抓包文件过滤 DNSdns重点关注没有 DNS Response 的 DNS Query请求发出去了但没有回应——DNS 服务器宕机或网络不通DNS Response 里 RCODE 不是 NOERRORNXDOMAIN域名不存在可能 DNS 记录配置错误SERVFAILDNS 服务器内部错误可能上游 DNS 故障REFUSEDDNS 服务器拒绝响应可能 ACL 配置问题3. Wireshark DNS 过滤技巧# 只看解析失败的响应 dns.flags.rcode ! 0 # 只看响应时间超过 200ms 的 DNS 请求 dns.time 0.2 # 看特定域名的 DNS 解析 dns.qry.name contains company.internal # 找没有对应 Response 的 DNS Query孤立请求 dns.flags.response 0 and !dns.response_in三、企业内网常见 DNS 故障场景场景一内网域名解析失败公网正常现象内部 ERP/OA 系统域名解析 NXDOMAIN但 baidu.com 解析正常。排查步骤确认客户端 DNS 服务器配置# Linuxcat/etc/resolv.conf# Windowsipconfig /all|findstrDNS Servers确认内网 DNS 服务器上有没有对应的 Zone 和记录# 在 DNS 服务器上查询digerp.company.internal 127.0.0.1# 列出所有 DNS 区域Windows DNS Serverdnscmd /enumzones常见根因客户端 DNS 服务器配置错误指向了不知道内部域名的 DNS比如直接用 8.8.8.8内网 DNS Zone 存在但记录已被删除或过期企业 DNS 分裂视图Split DNS配置错误场景二DNS 解析慢影响应用响应时间现象用户反馈应用响应慢但服务器本身响应时间正常。用 curl 加-w参数分析发现time_namelookup很高。# 用 curl 分析各阶段时间curl-wDNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTotal: %{time_total}s\n\-o/dev/null-shttp://erp.company.internal排查步骤对比多个 DNS 服务器的响应时间# 对比主备 DNS 服务器响应时间digerp.company.internal 192.168.1.1|grepQuery timedigerp.company.internal 192.168.1.2|grepQuery time检查 DNS 服务器的负载DNS 服务器 CPU / 内存是否过高是否有异常大量 DNS 查询DNS DDoS、蠕虫感染导致的 DNS 风暴抓包确认延迟来自哪个环节tcpdump-ieth0 port53-n# 对比 DNS Query 和 Response 的时间戳确定延迟是网络层还是 DNS 服务器处理层场景三DNS 解析结果错误返回了错误 IP现象域名能解析但解析结果是错的连接建立后立即失败或行为异常。# 对比不同 DNS 服务器的解析结果digerp.company.internal 192.168.1.1digerp.company.internal 192.168.1.2digerp.company.internal 8.8.8.8# 公网 DNS 作为参照常见根因DNS 缓存中毒Cache PoisoningDNS 服务器缓存了错误的记录可能是攻击也可能是配置失误旧 IP 的 DNS 记录没有清除服务器 IP 变更后DNS 记录更新了但 TTL 未到期部分服务器还在缓存旧记录搭便车的内网 DHCP DNS 注册某台机器意外注册了和业务系统相同的 DNS 名称解决# 清除 DNS 服务器上特定记录的缓存Windows DNS Serverdnscmd /clearcache# 强制刷新客户端 DNS 缓存# Windows:ipconfig /flushdns# Linux:systemctl restart systemd-resolved# macOS:sudodscacheutil-flushcache场景四特定时间段 DNS 解析失败现象每天上午 9-10 点内网 DNS 解析偶发超时其他时间正常。这类间歇性问题最难排查靠临时抓包往往抓不到。需要持续监控。监控方法# 脚本每 30 秒测一次 DNS 解析记录时间和耗时whiletrue;doecho-n$(date%H:%M:%S)- digerp.company.internal 192.168.1.1|grepQuery time||echoTIMEOUTsleep30done/tmp/dns_monitor.log用全流量分析工具则更直接可以看到每一次 DNS 查询的完整时序哪个时间点开始出现超时、超时的 Query 发往哪个 DNS 服务器、有没有对应的 Response——这些信息在事后也可以回溯查询不需要在故障发生时恰好在抓包。四、DNS 故障排查检查清单□ 客户端 DNS 服务器配置是否正确 □ DNS 服务器本身是否可达ping/telnet 53 □ 内网 Zone 是否存在Zone 内记录是否正确 □ DNS 响应时间是否正常10ms 为优 □ DNS Response RCODE 是否为 NOERROR □ 有没有大量 NXDOMAIN 或 SERVFAIL 响应可能是 DNS 风暴 □ 主备 DNS 服务器解析结果是否一致 □ TTL 是否合理内网记录建议 300-600s太长导致变更慢太短增加 DNS 查询频率 □ 是否存在 DNS 缓存不一致不同客户端解析结果不同五、持续 DNS 监控的价值单次 dig / tcpdump 排查解决的是已知故障。真正让运维省心的是在问题变成用户投诉之前就发现它。建议在核心链路上持续监控 DNS 流量实时统计 DNS 解析成功率、平均响应时间、NXDOMAIN 比例对解析时间 100ms 的查询实时告警保留历史 DNS 查询记录支持事后回溯AnaTraf 网络全流量分析仪 在核心交换机 SPAN 口部署后自动解析 DNS 协议可以实时展示各 DNS 服务器的响应时间分布、解析失败率并支持按域名、客户端 IP、时间段检索历史 DNS 记录——把 DNS 故障从靠猜变成有数据。总结现象优先排查方向工具域名不通但 IP 可达DNS 解析失败nslookup / dig应用响应慢DNS 解析延迟curl -w / dig Query time解析结果不稳定DNS 缓存不一致对比多台 DNS 服务器特定时间段失败间歇性 DNS 超时持续监控脚本 / 全流量分析SERVFAIL 错误上游 DNS 故障dig 各级DNS服务器DNS 是所有应用的基础设施。它出问题的时候表现往往是应用层症状所以很容易被误诊。掌握这套排查方法能让你在 DNS 故障面前少走很多弯路。