传统DNS解析把域名映射到IP地址时，默认使用UDP 53端口明文通信。客户端向本地配置的递归解析器发出查询，递归解析器逐级向根服务器、顶级域服务器和权威服务器询问。由于整个过程没有加密也没有签名校验，任何能够观察到查询报文的中间节点都可以构造伪造的应答。DNS污染正是在这条链路上发生的，而不是修改域名注册记录。理解这一点，是区分DNS污染与域名被劫持的关键。
一、DNS污染到底发生在哪一层
一次完整的DNS查询通常包含多个环节：客户端把域名发给本地递归解析器，递归解析器从根服务器开始迭代查询，最终从权威服务器获得结果。传统DNS报文使用UDP传输，没有握手过程，客户端只根据事务ID、源端口和查询域名来匹配响应。攻击者如果在链路中间能够看到查询报文，就可以抢在真实响应之前发送一个伪造的DNS应答包，把域名指向错误IP。
伪造响应之所以容易成功，主要是因为UDP协议的无连接特性以及传统DNS缺乏响应来源校验。客户端发起查询后，通常只会接受第一个到达的、事务ID和查询域名都对得上的响应。攻击者不需要建立TCP连接，也不需要伪装成权威服务器，只要能向客户端发送一个源地址看起来像递归解析器的UDP包即可。某些污染设备还会持续丢弃或延迟真实应答，让伪造包更容易胜出。
另外，污染也可能发生在递归解析器向上游查询的路径上。递归解析器向根服务器或顶级域服务器请求时，同样使用明文UDP，中间设备如果发现问题域名，也可能伪造一个上级响应返回给递归解析器。这样即便客户端信任本地递归解析器，最终拿到的结果仍然可能是被污染的。因此，只看客户端到递归解析器这一段并不完整，整条解析链路中的任何一跳都可能被利用。
二、如何确认自己遇到了DNS污染
排查DNS污染的第一步，是使用不同公共DNS服务器查询同一个域名，并对比返回的IP地址。可以使用dig、nslookup或PowerShell中的Resolve-DnsName命令。如果不同服务器返回的IP差异很大，而且某些结果明显是保留地址、固定拦截IP，或者同一个域名在不同地区查询结果不一致，就需要怀疑解析链路被污染。
dig @8.8.8.8 ipipp.com dig @223.5.5.5 ipipp.com nslookup ipipp.com 1.1.1.1
更准确的判断方式是抓包观察DNS响应。使用Wireshark抓取UDP 53端口流量时，可以观察是否存在多个针对同一查询的响应包，以及响应包的来源IP是否和所查询的递归服务器IP一致。正常情况下，一个查询通常只应该有一个权威响应。如果短时间内出现多个不同内容且来源可疑的响应，基本可以确认链路中存在伪造注入行为。
此外，还可以通过启用加密DNS前后的解析结果差异来判断。如果本地明文查询得到的IP不可达、无法建立HTTPS连接，而通过DoH或DoT查询同一域名得到的IP却可以正常访问，说明本地明文DNS查询被篡改。这种方法不需要额外抓包工具，适合普通用户快速验证。
三、改用加密DNS协议：DoH与DoT
DoH全称是DNS over HTTPS，它把DNS查询封装在HTTPS请求中，使用443端口传输。DoT则是DNS over TLS，使用853端口建立TLS隧道。两者的共同点是把DNS报文从明文UDP中移出，中间设备无法直接看到查询内容，也无法轻易向客户端注入伪造的UDP响应包。对于发生在客户端到递归解析器之间的大多数污染行为，启用加密DNS可以在很大程度上缓解。
DoH的优势在于查询流量与普通HTTPS流量混在一起，不太容易被单独识别或阻断。DoT则使用独立端口，部署上更直观，但端口更容易被针对。无论选哪种，都需要选择可信的无污染公共DNS服务，例如Cloudflare、Google或Quad9提供的加密DNS地址。需要清楚的是，加密DNS只保护客户端到递归解析器这一段，如果递归服务器本身返回错误结果，或者服务器到权威端的路径被污染，单靠DoH仍然不能完全解决问题。
curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=ipipp.com&type=A'
在操作系统中启用DoH也很简单。Windows 11可以在网络设置的DNS服务器分配中手动填入支持DoH的服务器地址，并选择加密方式。Chrome和Edge浏览器支持单独开启安全DNS，允许通过浏览器自身的DoH通道解析域名，从而绕过系统DNS设置。对于移动设备，Android和iOS也都在系统或浏览器层面提供了加密DNS选项。普通用户优先启用加密DNS，通常是最低成本且有效的第一步。
四、自建递归解析与上游加密
如果公共DoH或DoT服务器速度不稳定，或者不希望把全部查询交给第三方，可以考虑自建递归解析器。使用Unbound、BIND或PowerDNS等软件，在本地或可信服务器上配置递归解析，并让出站查询通过DoT或DoH转发到可信上游。这样既能保持解析链路的加密，也能自己掌控部分查询行为。
server:
interface: 127.0.0.1
port: 53
do-daemonize: no
access-control: 127.0.0.0/8 allow
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 1.1.1.1@853#cloudflare-dns.com
forward-addr: 8.8.8.8@853#dns.google
上述配置表示Unbound监听本机53端口，并把所有查询通过TLS转发到Cloudflare和Google的DoT服务器。本地网络中的其他设备只需把DNS设置为运行Unbound的主机地址，就能间接获得加密解析能力。对于技术团队来说，这种方案适合统一出口，避免在每台终端上分别配置。
自建递归解析的难点在于，如果本地网络对853端口或上游地址进行阻断，转发仍然可能失败。此时需要配合代理或VPN将递归查询流量先送出受限网络。另外，DNSSEC验证可以确认返回数据的完整性和来源，但无法防止响应被丢弃。因此，自建递归更适合作为加密DNS的补充，而不是唯一依赖。
五、本地Hosts与代理VPN方案
对于少量需要稳定访问的域名，直接写入本地Hosts文件可以绕过DNS查询环节，从根源上避免污染。Hosts文件在操作系统中优先级通常高于DNS服务器，客户端会直接使用文件中定义的IP地址。这种方式适合临时测试或固定IP的服务器，但缺点也很明显：一旦目标IP发生变化，必须手动更新，无法适应动态调度场景。
203.0.113.10 ipipp.com 198.51.100.20 www.ipipp.com
Windows下的Hosts文件路径为C:\Windows\System32\drivers\etc\hosts，Linux和macOS下通常位于/etc/hosts。修改后需要刷新DNS缓存，Windows可以使用ipconfig /flushdns命令。需要注意的是，Hosts只解决本地解析问题，如果目标IP本身被网络层封锁，仅改Hosts仍然无法建立连接。
代理和VPN方案则更为全面。代理工具可以把域名解析交给远端节点处理，本地只连接代理服务器IP，不直接查询真实域名。许多代理客户端提供远端解析或fake-ip模式，配合分流规则可以只对部分域名走代理。VPN方案则是把整个网络出口迁移到远端，DNS查询也随之在远端完成。使用代理或VPN时要注意防止DNS泄漏，确保查询不会回落到本地明文解析，否则污染仍然可能发生。
六、方案对比与选择建议
不同场景下，防污染方案的选择差异很大。加密DNS部署简单，适合普通用户；自建递归适合统一管理；Hosts适合少量临时解析；代理和VPN适合需要同时解决连接问题的场景。下面从防污染效果、配置难度、延迟和适用场景几个维度进行对比。
| 措施 | 防污染效果 | 配置难度 | 延迟 | 适用场景 |
|---|---|---|---|---|
| DoH/DoT | 中高 | 低 | 低 | 普通终端日常使用 |
| 自建递归 | 中高 | 中 | 中 | 团队统一出口 |
| 本地Hosts | 仅限个别域名 | 低 | 低 | 少量固定域名测试 |
| 代理/VPN | 高 | 中 | 中高 | 跨区访问和综合绕过 |
综合来看，个人用户优先开启系统或浏览器自带的DoH或DoT功能，再根据实际访问情况决定是否叠加代理。技术团队可以在内网部署Unbound并通过DoT转发，实现统一的加密递归解析。对于关键域名，还可以结合Hosts和DNSSEC验证进一步提高可靠性。DNS污染本质上是协议信任问题，单纯替换DNS服务器不一定能彻底解决，需要从加密、验证和远端解析多个层面组合应对。