DNS 安全 · 污染与规避

DNS 污染是什么？
原理、表现、检测与规避

为什么同一个域名，换个 DNS 就"活了"？问题往往不在域名本身，而在你查询的路上——有设备抢先递了一份假答案。

UDP 53明文传输 · 易被插假答案
抢先响应伪造包比真答案先到
DoH/DoT加密查询 · 根治手段
dig 对比一行命令即可检测
TL;DR · 核心结论

DNS 污染指位于你与正规解析器之间的中间设备，在明文 DNS 查询经过时抢先返回伪造响应，让你把目标域名解析到错误 IP（常见表现：特定域名打不开、跳转到广告页或可疑 IP）。它利用了传统 DNS（UDP 53）明文、无身份认证的缺陷。检测方法很简单：用 dig @A服务器 域名 对比不同 DNS 返回的 IP 是否一致；规避的根本办法是改用加密 DNS——DoH（RFC 8484）或DoT（RFC 7858），查询内容加密后，中间设备看不到你查了哪个域名，也就无法伪造针对性答案。

Mechanism

DNS 污染是怎么发生的？

明文 UDP 53 的设计缺陷，让"抢跑"变得极易实现

传统 DNS 查询走 UDP 53 端口，报文内容（你要查哪个域名）全程明文，且协议本身不对响应方做身份认证——客户端只认"先到达、事务 ID 对得上"的那一个包。这给了链路上的中间设备可乘之机。

典型过程是这样的：你的设备发出查询 dig www.example.com，报文在到达递归解析器之前，会经过运营商网络、骨干网等一系列中间节点。链路上的干扰设备识别出你查询了某个特定域名后，会立刻伪造一个 DNS 响应包（附上错误 IP，甚至把事务 ID 也猜出来），抢在真实解析结果返回之前递给你的设备。客户端先收到这个假包，就直接采信了——真实答案随后到达时反而被丢弃。

三种常见的"污染"场景

  • 运营商劫持：把未备案/失效域名的解析请求重定向到运营商的广告页或搜索引导页，访问不存在的域名时弹出运营商广告就是典型。
  • 中间设备篡改：网关、防火墙或审计设备对特定关键词域名返回伪造 IP，使这些域名解析失败或指向黑洞地址。
  • 特定网络环境干扰：在某些网络环境中，明文 DNS 查询会被基于域名关键词的规则匹配并干预，表现为特定域名异常、其余域名正常。

关键理解：污染是"被动监视 + 主动抢答"——它不需要劫持你的 DNS 设置，只需要你的查询报文从它眼皮底下明文经过。

Symptoms

被污染的典型表现

记住这些症状，下次遇到就知道从哪里查起

表现具体现象可能原因
解析到错误 IP访问某域名却打开了广告页、停车场页面或与内容无关的站点伪造响应指向了指定 IP
特定域名异常大部分网站正常，个别特定域名始终打不开、超时或证书报错基于域名关键词的针对性干预
换个 DNS 就好把 DNS 从运营商默认换成 223.5.5.5 / 1.1.1.1 后问题消失污染发生在原 DNS 之前的链路上
返回 0.0.0.0 / 黑洞 IPdig 结果出现 0.0.0.0、127.0.0.1 等不可能的地址伪造响应直接指向黑洞
结果不稳定同一域名多次解析，IP 时对时错、时而超时伪造包与真实包的到达顺序在竞争
Detection

如何检测 DNS 污染？

核心思路：用不同 DNS 查同一域名，对比结果

污染的本质是"同一份查询，在不同链路上得到不同答案"。所以最可靠的检测方法是指定不同的 DNS 服务器对比查询，而不是只看系统默认结果。

# 1) 用本地默认 DNS 查一次，记录返回 IP dig www.example.com +short # 2) 指定阿里公共 DNS 查同一域名 dig @223.5.5.5 www.example.com +short # 3) 指定 Cloudflare / Google 公共 DNS 再查一次 dig @1.1.1.1 www.example.com +short dig @8.8.8.8 www.example.com +short # 4) Windows 用户用 nslookup 指定服务器 nslookup www.example.com 223.5.5.5

判读方法：如果用 223.5.5.5、1.1.1.1 等加密/境外 DNS 查到的 IP 一致且能正常访问，而你本机默认 DNS 查到的是另一个可疑 IP，基本可以判定：你的默认 DNS 链路被污染了。也可以借助公共在线检测站点对比多地解析结果。注意：如果所有 DNS（包括加密 DNS）都返回同一错误 IP，那问题可能出在权威记录本身或路由层面，而不是污染。

Mitigation

如何规避 DNS 污染？

加密是釜底抽薪：让中间设备看不到你查了什么

方案做法能解决什么局限
DoH（推荐）把查询封装进 HTTPS，443 端口，按 RFC 8484 执行查询内容全程 TLS 加密，中间人看不到域名，无法伪造针对性答案；证书校验让伪造响应直接被拒依赖 DoH 服务商本身可信
DoTTLS 加密隧道，专用 853 端口，按 RFC 7858 执行同样加密查询内容，安卓私人 DNS、iOS、路由器原生支持853 端口在个别网络会被单独封锁
更换备用公共 DNS把默认 DNS 换成 223.5.5.5 / 119.29.29.29 等绕开被运营商劫持的默认 DNS，简单见效仍是明文 UDP，换汤不换药，仍可能被污染
自建递归解析器本地跑 Unbound / AdGuard Home，上游走 DoH/DoT查询内容与缓存完全自控需要一定运维能力

推荐落地路径：手机端在 Android 9+「私人 DNS」填 DoT 主机名；桌面浏览器开启「安全 DNS」填 DoH 地址（Firefox 操作见官方文档）；路由器上游换 https://dns.alidns.com/dns-query 或 Cloudflare DoH。换成加密 DNS 后，再用上面的 dig 对比法复测，确认结果稳定一致。

FAQ

常见问题

什么是 DNS 污染？+
DNS 污染指位于你与权威 DNS 之间的中间设备，在明文 DNS 查询经过时抢先返回伪造的解析结果，让你的设备把域名解析到错误 IP。它利用了传统 DNS（UDP 53）明文无认证的缺陷，不需要改动你的设备设置即可生效。
DNS 污染和 DNS 劫持是一回事吗？+
不完全相同：劫持通常指把你的解析请求整体引导到攻击者控制的 DNS（改你设备的 DNS 设置或路由器）；污染特指在链路上“插假答案”——你以为在问正规服务器，其实先收到的是伪造响应。两者效果相似（错误 IP），但技术位置不同，防护思路也都指向加密 DNS。
怎么检测自己是否遇到了 DNS 污染？+
用 dig 分别向不同公共 DNS 查询同一域名并对比：dig @223.5.5.5 域名 与 dig @8.8.8.8 域名，若返回 IP 不一致、或对特定域名总是解析到可疑 IP/0.0.0.0，而换加密 DNS 后恢复正常，基本可判定为链路污染。
DoH/DoT 能解决 DNS 污染吗？+
能显著缓解。污染依赖“看到明文查询内容”才能伪造针对性答案；DoH（443 端口）和 DoT（853 端口）把查询全程 TLS 加密，中间设备看不到你解析了哪个域名，也就无法构造针对性伪造响应；配合证书校验，伪造的加密响应会被客户端直接丢弃。
换成加密 DNS 后所有问题都消失了，是不是就不用管了？+
链路污染确实解决了，但加密 DNS 服务商本身仍能看到你的全部查询。如果它不可信，等于把隐私交给了另一个对象。对隐私要求高的场景，建议自建零日志解析器，或选择日志政策透明、经第三方审计的服务商。
References

参考来源