news 2026/4/20 2:26:56

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

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
DNS解析故障排查实战：从“网络不通“到定位根因的完整方法论

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

为什么 DNS 故障总是最难发现的那一类

网络故障里，DNS 问题有一个特殊的迷惑性：它让你以为是别的问题。

用户反馈"网络断了"——其实是 DNS 解析失败，HTTP 请求还没发出去就挂掉了。
用户反馈"网站打不开"——其实某个 CDN 域名解析返回了过期 IP，TCP 连接超时。
用户反馈"系统登录很慢"——其实内网 AD 域控的 DNS 响应延迟从 5ms 涨到了 800ms。

SNMP 看不见 DNS 问题，ping 测不出来，带宽利用率也完全正常。但用户就是用不了。

本文从实战角度整理 DNS 故障排查的完整方法：从现象识别，到工具使用，到根因定位，覆盖企业内网常见的 DNS 故障场景。

一、快速判断是否是 DNS 问题

遇到"网络不通"类投诉，第一步先排除 DNS：

# 直接用 IP 访问（绕过 DNS）curl-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 time：DNS 响应时间（毫秒）# SERVER：实际响应的 DNS 服务器

看 Query time：

  • <10ms：正常
  • 10-100ms：可接受，但值得关注

  • 100ms：明显偏高，可能有 DNS 服务器问题

  • 超时（;; connection timed out）：DNS 服务器不可达
# 批量测试多个域名的解析时间fordomaininerp.company.internal db.company.internal mail.company.internal;doecho-n"$domain: "dig$domain@192.168.1.1|grep"Query time"done

2. 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 里打开抓包文件，过滤 DNS：

dns

重点关注：

  • 没有 DNS Response 的 DNS Query：请求发出去了但没有回应——DNS 服务器宕机或网络不通
  • DNS Response 里 RCODE 不是 NOERROR：
    • NXDOMAIN：域名不存在（可能 DNS 记录配置错误）
    • SERVFAIL：DNS 服务器内部错误（可能上游 DNS 故障）
    • REFUSED：DNS 服务器拒绝响应（可能 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 解析正常。

排查步骤：

  1. 确认客户端 DNS 服务器配置
# Linuxcat/etc/resolv.conf# Windowsipconfig /all|findstr"DNS Servers"
  1. 确认内网 DNS 服务器上有没有对应的 Zone 和记录
# 在 DNS 服务器上查询digerp.company.internal @127.0.0.1# 列出所有 DNS 区域（Windows DNS Server）dnscmd /enumzones
  1. 常见根因：
    • 客户端 DNS 服务器配置错误，指向了不知道内部域名的 DNS（比如直接用 8.8.8.8）
    • 内网 DNS Zone 存在但记录已被删除或过期
    • 企业 DNS 分裂视图（Split DNS）配置错误

场景二：DNS 解析慢，影响应用响应时间

现象：用户反馈应用响应慢，但服务器本身响应时间正常。用 curl 加-w参数分析发现time_namelookup很高。

# 用 curl 分析各阶段时间curl-w"DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTotal: %{time_total}s\n"\-o/dev/null-shttp://erp.company.internal

排查步骤：

  1. 对比多个 DNS 服务器的响应时间
# 对比主备 DNS 服务器响应时间digerp.company.internal @192.168.1.1|grep"Query time"digerp.company.internal @192.168.1.2|grep"Query time"

  1. 检查 DNS 服务器的负载

    • DNS 服务器 CPU / 内存是否过高
    • 是否有异常大量 DNS 查询（DNS DDoS、蠕虫感染导致的 DNS 风暴）

  2. 抓包确认延迟来自哪个环节

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 Poisoning）：DNS 服务器缓存了错误的记录，可能是攻击也可能是配置失误
  • 旧 IP 的 DNS 记录没有清除：服务器 IP 变更后，DNS 记录更新了但 TTL 未到期，部分服务器还在缓存旧记录
  • 搭便车的内网 DHCP DNS 注册：某台机器意外注册了和业务系统相同的 DNS 名称

解决：

# 清除 DNS 服务器上特定记录的缓存（Windows DNS Server）dnscmd /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|grep"Query time"||echo"TIMEOUT"sleep30done>>/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 故障面前少走很多弯路。

版权声明: 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！
网站建设 2026/4/20 2:09:14

IDV云桌面vDisk机房课表联动部署方案

IDV云桌面vDisk机房课表联动部署方案学校机房按固定课表排课&#xff0c;不同时间段开设不同课程&#xff0c;需要切换不同教学镜像、启停终端、调控机房物联设备&#xff0c;人工操作重复繁琐&#xff0c;还易出现错漏影响正常教学。IDV云桌面vDisk方案原生支持院校机房课表联…

作者头像 李华
网站建设 2026/4/20 2:08:17

STM32 IAP升级后中断失灵？别慌，检查一下BootLoader里这个寄存器

STM32 IAP升级后中断失灵&#xff1f;深入解析FAULTMASK寄存器的关键作用 最近在嵌入式开发社区中&#xff0c;不少工程师反馈在进行STM32的IAP&#xff08;In-Application Programming&#xff09;升级后&#xff0c;应用程序的主循环能够正常运行&#xff0c;但所有中断都无法…

作者头像 李华
网站建设 2026/4/20 2:05:19

AGI去中心化不是理想主义——全球首个通过ISO/IEC 27001认证的分布式推理网络架构解密（含审计报告编号：AGI-DC-2024-089）

第一章&#xff1a;AGI去中心化不是理想主义 2026奇点智能技术大会(https://ml-summit.org) 将通用人工智能&#xff08;AGI&#xff09;构建在去中心化基础设施之上&#xff0c;正从学术构想加速演变为工程现实。区块链共识机制、联邦学习框架与零知识证明的成熟组合&#x…

作者头像 李华
网站建设 2026/4/20 2:03:14

如何彻底解决网盘下载限速：八大平台直链下载助手完整指南

如何彻底解决网盘下载限速&#xff1a;八大平台直链下载助手完整指南 【免费下载链接】Online-disk-direct-link-download-assistant 一个基于 JavaScript 的网盘文件下载地址获取工具。基于【网盘直链下载助手】修改 &#xff0c;支持 百度网盘 / 阿里云盘 / 中国移动云盘 / 天…

作者头像 李华
网站建设 2026/4/20 2:01:13

如何查询SQL数据库的连接数状态_查询全局运行参数

查MySQL连接数应根据需求选择&#xff1a;SHOW STATUS LIKE Threads_connected获当前打开连接数&#xff08;含空闲&#xff09;&#xff0c;轻量适合监控&#xff1b;SHOW PROCESSLIST列线程详情&#xff08;含SQL、用户、状态&#xff09;&#xff0c;但权限受限且默认仅前10…

作者头像 李华