访问同一个域名，手机流量能打开，换成家里Wi-Fi就跳到了其他页面；或者海外用户访问一切正常，国内部分地区却始终解析到一个完全不认识的IP。这类现象背后，往往不是域名解析配置写错了，而是DNS污染在链路中间篡改了应答。

DNS污染（也叫DNS缓存投毒）的本质是：攻击者或中间设备拦截了UDP 53端口的明文DNS查询，抢在权威服务器响应之前，注入一个伪造的应答包，把域名指向错误的IP。2026年10月，国家互联网应急中心披露的一起事件就是典型案例：境外自治域AS 402425通过宣告虚假路由劫持流量后，将DNS解析值直接篡改为其他网站地址，或指向恶意DNS服务器，影响范围涉及多个省份。

要防住它，需要先理解它的运作方式，再掌握判断方法，最后选择匹配的防护层级。

DNS污染的原理：为什么“改解析”没有用

很多站长遇到解析异常的第一反应是去域名后台改A记录。但如果问题是DNS污染，改A记录、调TTL、甚至换NS服务器，都可能完全无效。

原因在于污染发生在传输链路，而不是权威解析配置。你的域名在DNS服务商后台的解析记录是正确的，权威服务器也能返回正确结果，问题出在“应答包从权威服务器返回用户”的这段路上——中间设备在正确的应答到达之前，抢先塞入了一个伪造的应答。用户的操作系统或本地递归DNS接受了这个先到的伪造包，后续即使正确应答到达，也可能因为缓存机制被忽略。

这也是为什么污染往往表现出地域性和运营商差异性：同一条链路、同一段路由上的用户受影响，更换网络环境（比如切到手机流量或海外节点）后解析恢复正常。

判断：用dig做“交叉对比”

检测DNS污染最可靠的核心方法不是ping，而是用dig对比不同DNS服务器的解析结果。ping依赖系统当前的DNS设置，如果本地DNS已经被污染，ping返回的本身就是错误IP，无法作为判断依据。

第一步，查看本地默认DNS的解析结果：

dig 你的域名.com +short

记录返回的IP。这是“嫌疑样本”。

第二步，向可信的公共DNS发起查询：

dig @8.8.8.8 你的域名.com +short

dig @1.1.1.1 你的域名.com +short

dig @223.5.5.5 你的域名.com +short

将多个公共DNS的结果与本地默认DNS的结果对比。

第三步，判断结果：

- 本地与公共DNS返回的IP一致：大概率没有污染，问题可能出在服务器本身或路由。

- 本地返回异常IP，公共DNS返回正常IP：这是DNS污染的典型特征。

异常IP通常有几个可识别的特征：返回的是 `127.0.0.1`、`192.168.x.x` 等本地或内网地址；返回的IP ping不通（100%丢包）；TTL值极短（比如5秒），而正常记录通常是300秒左右。

如果需要进一步确认污染发生在链路的哪一段，可以使用 `dig +trace 你的域名.com`，从根服务器逐级追踪。如果权威服务器返回了正确IP，但中途某个节点突然出现异常解析，说明污染发生在中间转发环节，而不是你的DNS服务商。

防护：分层部署，没有单一“银弹”

DNS污染的防护需要根据你的角色（访客/站长）和污染程度来选择方案。不存在一种措施能解决所有场景，务实的做法是分层叠加。

第一层：加密DNS（DoH/DoT）——对访客最直接有效

明文UDP 53是污染能够生效的根本条件——中间设备可以看到并篡改查询内容。DoH（DNS over HTTPS）和DoT（DNS over TLS）将DNS查询封装在加密隧道中，DPI设备无法窥探和篡改查询内容，从机制上封堵了污染的实施路径。

在浏览器中开启“安全DNS”（Chrome/Edge/Firefox均支持），或在路由器层面全局部署DoH，可以让该网络下的所有设备受益。常用的DoH地址包括 Cloudflare的 `https://cloudflare-dns.com/dns-query` 和阿里云的 `https://dns.alidns.com/dns-query`。

第二层：DNSSEC——防篡改，但不防监听

DNSSEC通过对DNS应答做数字签名，让递归解析器可以验证解析结果是否来自权威服务器、是否在传输中被篡改。对于已签名且验证链完整的域名，攻击者无法把解析结果替换成伪造IP。

但DNSSEC有明确的边界：它不加密查询内容（别人仍然能看到你查询了哪个域名），不防DDoS攻击，也不防注册商账号被盗导致的NS记录变更。更现实的问题是，部分运营商的递归DNS不执行DNSSEC验证，或者丢弃DNSSEC报文，导致防护效果打折扣。因此，DNSSEC是“防篡改”的重要一环，但不能替代加密DNS。

第三层：Anycast与CDN——提升链路的抗污染韧性

普通单点DNS的解析链路相对固定，更容易被针对性拦截。接入Anycast分布式DNS，可以让解析请求从就近节点响应，缩短链路、增加攻击者精准篡改的难度。配合CDN代理隐藏源站IP，即使部分线路的解析被污染，其他节点的正常解析仍然可以支撑访问。

第四层：备用域名与业务分流——重度污染场景的兜底

如果主域名长期、大面积被污染，且前述措施无法在短期内恢复，准备备用域名进行业务分流是务实的兜底方案。在主域名解析异常时，通过已建立的用户渠道引导访问备用域名，避免业务完全中断。

一个常见误区：污染和劫持不是一回事

排查时需要注意区分：DNS污染的典型表现是解析结果被篡改（返回了错误的IP），而DNS劫持可能涉及解析请求本身被拦截并重定向到其他服务器。两者的检测方法有重叠，但根因和处置方向不完全相同。如果dig对比显示本地返回的是内网地址或明显的广告IP，且更换加密DNS后恢复正常，基本可以定位为污染；如果请求被整体劫持，则需要从路由和链路层面排查。

从判断到处置的完整流程

遇到解析异常时，按以下顺序操作，可以快速定位问题并选择匹配的防护措施：

第一步，用 `dig 你的域名 +short` 和 `dig @8.8.8.8 你的域名 +short` 对比结果，确认是否存在污染特征。第二步，在浏览器或设备上临时启用DoH，复测解析是否恢复正常——如果加密DNS能绕过问题，说明污染发生在明文DNS链路。第三步，如果域名已启用DNSSEC，确认解析器是否真正执行验证；如果未启用，评估开启的收益与运营商兼容性风险。第四层，对于业务域名，考虑接入Anycast DNS或CDN代理，提升链路韧性。第五步，重度污染场景下，准备备用域名作为兜底。

DNS污染防不住的原因，往往不是缺少某一项“神器”，而是只做了单层防护。 加密DNS阻断篡改的实施条件，DNSSEC保证解析结果的完整性，Anycast和CDN提升链路的抗干扰能力，备用域名兜住最坏情况——四层叠加，才能形成可用的防护纵深。