内容摘要：```html 运维群里有人甩了张截图，nslookup 返回了三个 IP，但浏览器死活打不开网站。底下立刻冒出七八条回复，从“清 DNS 缓存”到“换 8.8.8.8”全猜了一遍。折腾半小时才发现，

```html

运维群里有人甩了张截图，域名nslookup 返回了三个 IP，解析但浏览器死活打不开网站。查询底下立刻冒出七八条回复，命令从“清 DNS 缓存”到“换 8.8.8.8”全猜了一遍。域名折腾半小时才发现，解析那三个 IP 里有两个是查询 CDN 边缘节点，已经下线了，命令第三个才是域名源站——但被防火墙挡了。这场景太常见了。解析域名解析查询命令，查询说白了就是命令给你一双眼睛，让你看清楚一个域名到底被翻译成了什么地址，域名以及这个翻译过程走的解析是哪条路。

最老的查询工具是 nslookup。Windows、Linux、macOS 都自带，不用装。敲 nslookup example.com，它会告诉你默认 DNS 服务器是谁，然后返回 A 记录。但 nslookup 有个毛病——它太“智能”了，有时候会自作主张帮你查别的记录类型，输出格式也看人下菜碟。我一般只在对方机器上什么都没有的时候用它，图个方便。真要干活，还是 dig 更顺手。

dig 是 Linux 和 macOS 上的标配，Windows 得自己装 BIND 工具包。它的输出分五段：头部、问题段、答案段、权威段、附加段。大部分人只看 ANSWER SECTION，但真正有用的信息往往藏在 AUTHORITY 和 ADDITIONAL 里。比如你查一个 CNAME，dig 会把 CNAME 指向的目标和最终 A 记录都列出来，省得你手动再查一次。加个 +short 参数，输出只剩 IP，适合塞进脚本里做判断。

有个细节值得说。查 MX 记录的时候，dig example.com MX 返回的优先级数字越小越优先，但很多人记反。我见过一个运维把优先级 10 的邮件服务器停了，以为 20 的会顶上，结果邮件全卡在队列里——因为 DNS 缓存还没过期，发件方还在往 10 那个 IP 投递。这时候用 dig +trace 就能看到完整的递归路径，从根服务器一路问到权威服务器，每个环节的 TTL 一清二楚。TTL 是缓存时间，单位秒。改完解析记录别急着刷新浏览器，先看 TTL 还剩多少。

Windows 上有个命令叫 nslookup -type=all，能一次性拉出所有记录类型。但 Windows 的解析器缓存和 DNS 服务器缓存是两码事。你改了 hosts 文件，ipconfig /flushdns 刷的是本地缓存，但公司内网 DNS 服务器上的缓存你刷不了。这时候可以指定 DNS 服务器查询：nslookup example.com 8.8.8.8，绕过内网 DNS 直接问 Google 的公共 DNS。如果结果不一样，问题就出在内网 DNS 上。

还有一个冷门但好用的命令：host。它比 dig 简洁，比 nslookup 干净。host -t MX example.com 直接返回邮件交换记录，没有多余输出。macOS 上默认就有。我习惯在写 shell 脚本时用它，因为输出格式稳定，不用 grep 去抠字段。

查域名解析不只是看 A 记录。CNAME 用来看 CDN 配置对不对，TXT 用来验证 SPF 和 DKIM 记录，NS 用来看域名托管在谁家。有一次客户说网站间歇性打不开，我用 dig +short NS example.com 发现他用了四个 NS 服务器，其中两个是已经停服的 DNS 提供商。解析请求随机落到那两台死掉的服务器上，自然就超时。把 NS 记录改掉，问题消失。

最后提一句 dig +tcp。默认 DNS 查询走 UDP，53 端口。响应超过 512 字节或者被截断时，才会自动切 TCP。但有些防火墙只放行 UDP 53，TCP 53 被挡了，导致大响应查询失败。手动加 +tcp 强制走 TCP，如果这时候能查到但 UDP 查不到，就知道防火墙规则有问题。这种案例不多，但碰上一次能省你半天排查时间。

工具就这几个，翻来覆去用。关键是理解 DNS 查询的递归和迭代过程，知道每一步在问谁、缓存存在哪、TTL 什么时候过期。剩下的就是敲命令、看输出、对比结果。别迷信图形化工具，命令行给你的信息量永远更大。

```