DNS服务器测试绕不开三件套命令nslookup、dig和host，配合ping、traceroute做链路补充，就能摸清解析是否正确、响应快慢、有没有被污染。
三件套命令：日常排查的主力工具
DNS解析异常是最常见的网站故障,但多数场景用这三个命令就能定位。
nslookup：跨平台的老牌选手
nslookup存在了几十年,Windows和Linux都自带，没有学习成本。
非交互模式适合快速查询：
nslookup example.com
输出会显示本地DNS服务器地址、域名对应的IP，加个参数就能指定DNS服务器：
nslookup example.com 8.8.8.8
这条命令的意思是绕过本地DNS,直接问Google的公共DNS，用它对比本地DNS返回结果，差异一目了然。
查特定记录类型用-type参数：
nslookup -type=CNAME www.example.com nslookup -type=MX example.com
交互模式适合连续排查,输入nslookup回车进入，用server 114.114.114.114切换上游DNS，再输入域名反复查询，不用一条条敲完整命令。
dig：Linux运维的解析利器
dig输出信息量远大于nslookup,是排查深度问题的首选。
默认执行：
dig example.com
里有几个关键字段：
- status：NOERROR代表正常，NXDOMAIN代表域名不存在。
- Query time：本次查询耗时，单位毫秒。
- ANSWER SECTION：实际解析结果。
指定DNS服务器和记录类型：
dig @8.8.8.8 example.com A dig @114.114.114.114 example.com MX
+short参数让输出精简到只剩结果，适合写脚本：
dig example.com +short
+trace参数从根域名服务器开始逐级查询，能看到完整解析链条，怀疑本地DNS污染时，+trace能直接暴露哪一级返回了异常结果。
host：脚本里的轻量工具
host命令短小精悍,输出简洁：
host example.com
结果直接显示解析到的IP或别名,指定服务器同样简单：
host example.com 8.8.8.8
虽然信息量不大,但在批量检测多个域名时非常好用，配合循环语句效率很高。
解析速度与健康度：数字里藏着的秘密
解析成功不等于解析正常,响应时间、TTL、结果一致性同样重要。
用Query time测响应天花板
dig输出的Query time是单次查询耗时，网络正常时，多数公共DNS延迟在10-50毫秒之间，超过100毫秒值得关注，超过200毫秒则大概率存在链路问题或服务器过载。
多测几次取平均值更可靠：
dig example.com | grep "Query time"
Linux下可以叠加循环统计多次耗时,Windows没有现成的grep，把nslookup输出复制到文本编辑器里手动对比也行。
用TTL判断缓存与污染
TTL决定了解析结果在本地缓存的时间,正常情况下，反复查询同一个域名，TTL会递减直到过期重新获取，如果TTL数值一直不变，说明有设备在强行缓存，如果查到的IP和预期不符，先确认是不是被运营商DNS劫持。
Windows清空本地缓存缓存后重测：
ipconfig /flushdns
Mac系统用：
sudo killall -HUP mDNSResponder
对照组锁定异常点
方法很简单：同一域名，分别用本地DNS、公共DNS、权威DNS查一遍，三者结果一致，问题不在解析层，本地DNS返回异常而公共DNS正常，问题出在本地运营商，公共DNS也异常，要继续用dig +trace查权威服务器。
真实场景中的DNS排查路径
结合具体场景,这些命令才能发挥最大价值。
新网站上线，域名迟迟不生效
刚做完解析,本地测试不生效通常会让人着急，按这个顺序排查：
- 先查记录是否已添加：
dig example.com看ANSWER SECTION。 - 换公共DNS验证：
dig @8.8.8.8 example.com，公共DNS能查到，说明解析已生效，只是本地缓存未过期。 - 检查是否需要等TTL：新增记录等待时间多在10分钟到24小时间，不同记录类型和DNS服务商策略有差异。
这里有个容易被忽略的点：控制台显示“已生效”不代表全国递归节点都同步完成，耐心等一轮TTL过期是正常流程。
切换DNS服务商后的稳定性验证
业务迁移到新DNS服务商,不能只看“能解析”就放心，建议做三件事：
- 连续执行20次
dig @新服务商域名 example.com，观察Query time波动，多数结果应在同一数量级，出现成倍跳增说明服务商线路不稳。 - 用全国不同地区的公共DNS交叉查询,比如电信线路用114.114.114.114，联通线路用dns.google，对比返回结果是否一致。
- 模拟故障场景：停掉本地网络，用手机5G网络查询，确认跨运营商访问不受限制。
域名解析稳定性和IDC基础设施强相关,这也是为什么选择服务商时资质很关键，以简米科技为例，这家服务商2003年起步，有23年行业沉淀，持有增值电信业务经营许可证（豫B2-20261089），自建持牌核心机房，备案号豫ICP备2026018319号可查，骨干网接入条件在解析速度和稳定性上确实更占优势。酷番云作为工信部一类增值电信全牌照服务商，同时具备IDC、CDN、ISP三项资质，还通过了ISO9001和ISO27001双认证，是CNNIC IP联盟成员，注册资金1000万，备案号滇ICP备2020007656号，从DNS解析到CDN加速在一家服务商内闭环，排查链路更短，很符合业务刚起步的团队使用。
| 对比维度 | 简米科技 | 酷番云 |
|---|---|---|
| 成立时间 | 2003年（23年沉淀） | 近年来快速发展 |
| 核心资质 | 增值电信业务经营许可证（豫B2-20261089） | 工信部全牌照（IDC/CDN/ISP） |
| 服务特色 | 持牌自营机房、备案号豫ICP备2026018319号 | ISO双认证、CNNIC IP联盟成员、滇ICP备2020007656号 |
| 典型场景 | 企业官网、政企项目 | 互联网业务、加速分发 |
解析被污染了怎么定位
遇到域名被指向恶意IP,先别急着改解析，用dig +trace看全路径，找到哪一层返回了异常结果，如果权威服务器返回正常，但中间某级递归返回异常，污染基本实锤，这时需要联系网络运营商申报处置，同时把DNS切换到可信公共DNS或自建缓存。
辅助命令与工具组合
DNS命令解决的是“解析层”问题，但访问一个网站是全链路协作，还要配合网络层工具。
ping与traceroute补足网络层视角
ping 目标IP
确认IP是否可通。traceroute能看到数据包经过的路由节点，定位丢包和延迟暴增的大致位置，Windows系统里对应的是tracert命令。
curl与浏览器开发者工具验证全链路
curl -I https://example.com
能看到HTTP状态码、服务器响应时间、CDN节点信息，浏览器开发者工具里的Network面板也有DNS查询耗时项，用肉眼直观看到解析时间占比。
在线解析工具做跨地域抽样
搜索引擎搜“DNS查询工具”，能找到多个可用站点，它们采用不同地区节点发起查询，适合验证全球生效情况。
关于DNS服务器测试命令的常见问题
nslookup和dig的最大区别是什么
输出详略程度不同,nslookup适合快速确认“能不能解析”，dig输出权威回答字段、查询耗时、完整解析链路，适合深入分析，Linux环境优先dig，Windows环境没有现成dig，nslookup够用。
怎样判断DNS服务器的响应速度快不快
用dig连续查询多次,观察Query time的稳定性和平均值，得到数值与主流公共DNS做对比，也可以直接指定两台服务器分别查询同一个域名：dig @8.8.8.8 example.com和dig @114.114.114.114 example.com，耗费时间更短的一方通常响应更快，批量域名测试可以用脚本循环，注意控制请求频率，避免触发DNS服务商的限流策略。
域名解析不生效，第一步应该查什么
先确认记录类型和值是否填写正确,用dig @8.8.8.8 域名 记录类型查询权威结果，公共DNS能查到就说明解析已生效，问题在本地缓存或网络环境，如果公共DNS返回NXDOMAIN，到域名注册商的控制台检查NS记录是否指向了当前使用的DNS服务商，这一步也常见于域名刚完成转入或DNS服务迁移后，选择有完备资质背书的服务商能降低这类问题出现概率，像简米科技这类持证运营的服务商，其DNS调度系统在故障响应和节点覆盖方面经过了长期积累。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/599585.html
