DNS污染这件事，最迷惑人的地方在于它的表现和“网站挂了”几乎一样。你打不开一个站，第一反应是服务器宕了，或者自己网络断了。但DNS污染的特点是：换一个网络环境，同一个域名又能正常打开。这种“选择性故障”才是它的指纹。dig 之所以是排查这件事的首选工具，不是因为它有多高级，而是因为它能让你绕开本地运营商的解析链路，直接向可信的公共DNS发问，把“你被告知的结果”和“真实的结果”摆在一起对比。对比，才是判断污染的核心动作。

　　在动手之前，需要先厘清一个容易混淆的概念。DNS污染和DNS解析配置错误，在终端用户看来都是“解析结果不对”，但性质完全不同。配置错误是所有网络环境都会得到同一个错误结果，而污染的特征是因网络环境而异：你的联通宽带解析出一个奇怪的IP，切换到手机热点或者用公共DNS查，结果就变了。这个差异是后续所有判断的基础。

　　第一步：建立可信的参照系

　　判断污染的前提是你得知道“正确”的答案长什么样。这个正确答案不能从你本地的DNS服务器要，因为它可能正是遭遇干扰的对象。你需要直接向公共DNS，或者更彻底地，向域名的权威服务器发问。

　　最直接的做法是横向对比多个公共DNS的返回结果。在终端里依次执行：

dig @223.5.5.5 example.com A +short
dig @119.29.29.29 example.com A +short
dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short

　　+short 参数让输出只保留IP地址，方便肉眼比对。如果这四个来自不同运营商的公共DNS返回的A记录完全一致，说明这个域名在主流递归解析器上的结果是一致的。如果只有你本地运营商DNS返回了不同的IP，而公共DNS都指向另一个地址，那么本地链路遭遇干扰的可能性就很高了。

　　但这里有一个需要留意的例外：如果目标网站使用了CDN或者GeoDNS，不同地区的DNS返回不同IP是正常行为。判断方法是看这些IP是否属于同一个AS(自治系统)或者同一个已知的CDN厂商网段。你可以对返回的IP执行 whois 看看归属，如果公共DNS返回的是 Cloudflare 或 Akamai 的地址，而你本地DNS返回的是一个归属地不明的随机IP，那才值得警惕。

　　更严谨的做法是直接向权威服务器查询。权威服务器是域名记录最终存放的地方，递归DNS只是缓存。dig +trace 会从根服务器开始逐级追踪，展示每一级的响应：

dig +trace example.com A

　　如果 +trace 的输出里，权威服务器返回的A记录是正常的，而你在本地 dig example.com 拿到的却是另一个IP，那么问题就出在从你到递归DNS之间的某一段链路上，而不是域名配置本身。

　　第二步：识别污染的特征信号

　　拿到本地解析结果和参照结果之后，需要看几个具体的信号来判断这到底是污染，还是别的问题。

　　信号一：返回的IP本身是否“可疑”。 污染注入的IP通常有一些共同特征：保留地址(如 127.0.0.1、0.0.0.0)、链路本地地址、或者明显不属于目标服务商的随机公网IP。2025年8月联通DNS故障中，大量域名被指向 127.0.0.2，这是一个回环地址的变体，任何发往这个地址的数据包都会在本地消失。如果你在 dig 的 ANSWER SECTION 里看到这类地址，基本可以定性。

　　信号二：TTL值是否异常。 正常的递归DNS返回的TTL，是从权威服务器的TTL开始倒计时的，所以它应该小于或等于权威TTL。如果你用 dig example.com A 看到的TTL是一个极小的值(比如 5 秒或 1 秒)，而你从权威服务器查到的TTL是 300，这说明注入的响应在刻意缩短缓存时间，让污染结果更快被“刷新”以持续生效，或者让真实结果更快覆盖它。这种TTL倒挂是污染的一个辅助判据。

　　信号三：响应是否“抢先到达”。 DNS污染的技术本质是中间设备在真实响应到达之前，抢先返回一个伪造的应答。客户端通常只接受第一个到达的响应，于是被“投毒”。这个机制决定了污染往往具有不稳定性：同一个域名，连续 dig 几次，可能一次返回正常结果，下一次就变成了污染IP。如果你在短时间内多次查询同一域名，结果在正常IP和异常IP之间跳动，这比稳定返回一个错误IP更能说明问题出在链路上而非配置上。

　　第三步：排除缓存和CDN的干扰

　　在得出“被污染”的结论之前，有两个常见的误判来源需要排除。

　　本地缓存。 你的操作系统和路由器都会缓存DNS结果。如果之前某次查询被污染了，那个错误的IP可能还在缓存里，即使污染已经消失，你查到的仍然是旧结果。在Linux上，如果使用 systemd-resolved，可以执行 sudo resolvectl flush-caches；如果使用 nscd，执行 sudo systemctl restart nscd。清除缓存后再查一次，结果如果恢复正常，说明之前的异常是残留缓存而非持续污染。

　　CDN的正常地域差异。 很多大型网站和云服务商使用GeoDNS，根据查询来源的IP返回最近的节点。你用北京联通的DNS查和用广东电信的DNS查，返回不同IP是完全正常的。判断方法是看这些IP是否在同一个大的网段规划内，或者直接查域名的NS记录，看看它是否托管在支持GeoDNS的服务商上。如果域名确实用了CDN，单纯“IP不同”不能作为污染的证据，需要结合IP的归属和可达性来判断。

　　第四步：用可达性做交叉验证

　　dig 告诉你的是“解析到了哪里”，但解析到的地址是否真的能提供服务，是另一个维度的信息。对 dig 返回的可疑IP做一次 ping 或 traceroute，如果这个IP完全不可达，或者路由路径明显异常(比如指向了一个内网地址或者某个不相干的机房)，这就能佐证它是一个无效的污染注入结果。

　　但要注意，有些服务器禁用了ICMP，ping 不通不代表IP无效。更可靠的方式是尝试对目标端口发起TCP连接，比如 curl -I --connect-timeout 5 http://<可疑IP> 并带上Host头。如果连接超时或被重置，而用正常IP可以建立连接，差异就出来了。

　　另一个值得做的交叉验证是换网络。用手机热点(走的是不同运营商的链路)重新 dig 同一个域名。如果热点下解析正常，而宽带下解析异常，这几乎是污染或链路干扰的典型画像。联通的故障之所以能被快速定位，正是因为用户切换到WiFi或电信网络后服务恢复了。

　　如果确认了污染，接下来应该做什么?

　　dig 只能告诉你“有问题”，不能替你解决问题。如果排查下来确实是污染，可行的应对方向有几个。最直接的是切换到加密DNS：DoH或DoT把查询请求封装在TLS隧道里，中间设备无法看到你在查什么域名，也就无法针对性地注入伪造响应。Firefox 和 Chrome 都内置了DoH支持，系统层面也可以通过配置 systemd-resolved 或安装 cloudflared 来启用。

　　如果污染只针对特定域名，且你有权限修改该域名的DNS配置，启用DNSSEC是更根本的方案。DNSSEC给DNS记录加了密码学签名，递归解析器在返回结果前会验证签名，伪造的响应无法通过验证。但DNSSEC需要域名注册商和权威DNS服务商同时支持，且部署有一定门槛，不是所有场景都能立刻用上。

　　最后需要接受一个现实：DNS污染发生在你控制不了的链路上，你无法“修复”它，只能绕过它。dig 的价值在于帮你快速确认问题不在你的服务器上，不在你的配置里，从而把精力放到正确的方向上。下次遇到“网站打不开但换手机就能开”的情况，先跑一遍 dig @8.8.8.8 和本地默认解析的对比，答案通常几分钟内就会清晰。