如何追踪查看DNS解析的过程

打开终端，何追敲下 `dig example.com`，踪查几毫秒后你拿到一个IP地址。解析这中间发生了什么？何追大多数人只关心结果，但如果你想知道DNS解析到底走了哪条路、踪查在哪个环节卡住、解析有没有被污染，何追那就得把过程拆开看。踪查

DNS解析的解析本质是一串递归查询。你的何追设备先问本地DNS服务器（通常是路由器或运营商提供的），本地服务器如果没缓存，踪查就去问根服务器，解析根服务器告诉它去找.com的何追顶级域服务器，顶级域再指向example.com的踪查权威服务器，最终拿到A记录。解析每一步都可能出问题，所以追踪的意义在于定位。

dig 是最顺手的工具

Linux和macOS上自带dig，Windows可以用nslookup或者装个bind工具包。先看一个完整追踪：

dig +trace example.com

+trace 参数会让dig从根服务器开始，逐级显示每一跳的查询结果。输出大概长这样：先列出根服务器的几个IP，然后显示从根得到.com的NS记录，再从.com的NS查到example.com的权威服务器，最后拿到A记录。每一段都标明了查询的服务器和返回的响应。你一眼就能看出哪一级响应慢，或者哪一级返回了意外的结果。

我遇到过一种情况：某个域名在本地解析正常，但 +trace 显示根服务器返回的.com NS列表里有一个IP被污染了，导致后续查询全部超时。如果没有trace，你只会看到“解析失败”，根本不知道问题出在根这一层。

看缓存和TTL

本地DNS服务器会缓存结果。用 dig example.com 不带trace，看ANSWER SECTION里的TTL值。如果TTL是3600，说明缓存刚写入不久；如果TTL只剩几十秒，说明快过期了。想强制绕过缓存，可以指定一个公共DNS：

dig @8.8.8.8 example.com

对比不同DNS服务器的返回结果，能判断是本地缓存问题还是权威服务器配置问题。有一次我改完域名的A记录，本地死活不更新，用 @1.1.1.1 查已经是新IP了，说明是运营商DNS的缓存没到期。等TTL自然过期，问题消失。

用 tcpdump 看底层包

dig和nslookup是应用层工具，它们告诉你“问了谁、答了什么”。但如果你想看DNS查询报文本身——比如确认查询ID、flags、是否被中间设备篡改——就得抓包。

sudo tcpdump -i any port 53 -nn

然后在另一个终端跑 dig example.com。tcpdump会打印出UDP 53端口的请求和响应包。你能看到查询的域名、查询类型（A、AAAA、CNAME等）、响应码（NOERROR、NXDOMAIN、SERVFAIL）。如果响应包里出现了你不认识的IP，或者响应码异常，基本可以确定链路上有东西在捣乱。

我曾在某个公共WiFi下发现，所有DNS查询的响应包里都被插入了一个额外的A记录，指向一个广告服务器。tcpdump抓到的响应包比正常的多了一条ANSWER，这就是典型的DNS劫持。dig本身不会显示这种异常，因为它只解析第一个有效答案。

Windows上的替代方案

Windows没有dig，但可以用 nslookup -debug example.com 看到类似的逐级查询信息。或者装一个WSL，直接用Linux那套工具。PowerShell的 Resolve-DnsName -DnsOnly -Trace 也能做trace，输出格式不同但逻辑一样。

追踪DNS解析不是运维专属技能。你调API、连数据库、访问内部服务，背后都有DNS。知道怎么追，出问题时就不用干等“网络故障”的结论。工具就那几个，关键是有没有意识去用。