域名解析工具选错，排查能熬你三天

解析出问题的第一反应，基本都是打开浏览器搜一个在线查询，输进去一看红的，心里咯噔一下，然后就开始动记录。这个顺序本身就错了。工具没选对，你查出来的那行结果根本不能当证据，改下去的东西反而把好好的配置弄乱了，后面谁接手谁头疼。域名解析工具这事，不是哪个界面好看就用哪个，是得知道每种工具在替你问谁。

我见过最典型的一幕：一个人拿着网页查询的结果说“记录没生效”，实际上那家在线站的缓存比他自己服务器的 TTL 还久。他信了，去改了 A 记录，改完真出问题了。

域名解析工具大致分三档，用途完全不同

第一档是操作系统自带的，dig、nslookup、host 这些，命令行里敲。第二档是系统层面的解析动作，浏览器、hosts 文件、本地 DNS 缓存都算。第三档才是网页版和 App 那种查询站，点一下就出结果，最省事也最容易骗人。三档不是替代关系，是层层递进的关系，你跳着用就会卡住。

dig 是这里面最值得花十分钟学的。格式不复杂，dig 空格域名，回车就完事。想指定用哪台 DNS 查，加个 @，比如 dig example.com @8.8.8.8，这就绕开了你本地那台可能已经缓存了旧记录的服务器。想看简短答案加 +short，只看邮件记录就 dig example.com MX。这些命令在 Linux 和 macOS 上基本都是现成的，Windows 上得自己想办法装。

Windows 用户最熟悉的是 nslookup。它也能用，但它有自己一套解析逻辑，不走系统的 DNS 缓存，所以有时候你在浏览器里打不开，nslookup 却能返回结果，别急着当成“网络恢复了”。反过来也成立，nslookup 报错而网页正常，多半是它在问一台你不该问的服务器。

查不到不等于没配，先分清递归和权威

解析这件事是一条链：你的电脑问本地递归服务器，递归服务器去问根、问顶级域、问权威服务器，拿到答案再一层层往回缓存。大部分“记录没生效”其实是递归服务器手里的旧缓存还没过期，权威那边早就改好了。这时候你要做的是直接问权威服务器，而不是继续在网页查询站上刷新。

怎么找权威？看域名的 NS 记录，dig NS 你的域名，会列出服务商给的几台名字服务器，然后 dig @ns1.xxx.com 你的域名，问的就是权威的答案。这个结果才是“真实配置”。递归那头看到的可能是几分钟甚至几小时前的旧数据，具体等多久，以服务商页面上标的 TTL 为准，各家给的值不一样。

换工具之前，先换掉查询的那台服务器

很多人排查到一半开始怀疑工具，其实工具没毛病，是默认帮你查的那台 DNS 有毛病。运营商的本地 DNS 出问题不算稀奇，返回个错误页的 IP，或者干脆把不存在的域名解析到广告页，都会让人误判成自己配错了。这时候临时把本机 DNS 换成公共的试试，能立刻分辨是配置问题还是链路问题。

换完记得换回来。我吃过这个亏，测完忘了改，后来本地开发环境访问内网域名一直失败，查了半天以为是 hosts 写错了。

还有一种情况是分线路解析。商业 DNS 会按访问者的来源返回不同结果，你用公共 DNS 或者 dig +trace 去查，看到的往往是默认线路，跟你实际用户拿到的不是一个东西。这种场景下别迷信命令行，找一台目标地区的机器实测，或者直接问服务商的技术支持要对应线路的解析结果。各家实现差异挺大，看官方文档比看别人的博客靠谱。

浏览器和系统缓存能把人骗一整天

改完记录，浏览器打开还是旧的，这种事占比很高。浏览器自己有 DNS 缓存，系统也有，路由器可能还有一层。清缓存的入口各版本位置不一样，找不到就用最笨的办法：开无痕窗口试一次，或者换一台设备换个网络访问。无痕窗口能排除掉插件和大部分缓存干扰，比你在设置里翻半天快。

系统层面，Windows 是 ipconfig /flushdns，macOS 要敲 sudo dscacheutil -flushcache 再 sudo killall -HUP mDNSResponder，Linux 上如果用 systemd-resolved 就是 sudo resolvectl flush-caches。全是半角字符，别抄错了。这几种命令不需要背，收藏一下，一年用不了几次，但每次都能救命。

hosts 文件也别忽略。路径是 /etc/hosts，Windows 在 C:\Windows\System32\drivers\etc\hosts，有时候是当年为了测试写进去的一条，后来忘了删，解析一直走本地，跟线上配置对不上。这个坑我踩过不止一次。

工具之外还得盯住两件事：TTL 和记录类型

TTL 设得太长，改记录等于给自己挖坑，改完要等到天荒地老；设得太短，权威服务器压力大，查询也慢。切换前把 TTL 调小，等旧值过期，再改指向，这套动作是老手的基本操作，跟用什么工具无关。

记录类型也是常见误判来源。CNAME 和 A 记录不能在同一主机名上共存，MX 记录要指向主机名而不是 IP，TXT 里多一个空格验证就过不去。这些问题用哪种工具查都会显示“有记录”，但结构不对，服务照样不通。看到记录存在但服务不通，先核对类型，别急着换工具。

一套能落地的排查顺序

顺序我是这么走的：先本地 hosts 和浏览器缓存排除掉；再用 dig 或 nslookup 问本地递归，看返回什么；再 @ 权威服务器问一遍，看配置本身对不对；最后拿一台外部机器实测。四步走完，问题落在哪一层基本就清楚了。中间任何一步“看着像没问题”都别跳过，跳过的那步往往就是问题所在。

至于在线查询站，我一般只用来快速看一眼 A 记录和 NS 有没有，图个方便，不拿它下结论。它的缓存策略你管不着，出了偏差你也没法验证。

最后提醒一句：动记录之前先截个图或者把当前配置导出，改坏了能回滚。这比任何工具都实在。