DNS污染是中间设备或本地服务劫持解析结果，需用dig @8.8.8.8和@1.1.1.1对比响应，若返回私网IP且Status为NOERROR，则确认污染；systemd-resolved或路由器等多层转发常导致误判，须逐层隔离验证。
直接结论：这不是“DNS配置错了”，而是解析结果被中间设备或本地服务劫持，必须用 dig 强制指定服务器 + 对比多源响应来定位污染点。
怎么确认是不是被恶意内网解析污染
别信 nslookup 或浏览器表现——它们默认走系统 resolver 链路，可能已被 systemd-resolved、dnsmasq 或路由器 DNS 重定向悄悄改写。真正可靠的判断方式只有两个：
- 执行
dig @8.8.8.8 example.com +short和dig @1.1.1.1 example.com +short，看返回 IP 是否一致；如果不一致，且其中一方返回的是私网地址（如10.x.x.x、192.168.x.x、172.16.x.x），基本锁定污染 - 再补一句
dig @127.0.0.53 example.com +short（systemd-resolved 默认监听地址）：如果它返回的 IP 和@8.8.8.8不同，说明本机 resolver 层已介入并改写了结果 - 注意
Status字段：若为SERVFAIL或REFUSED，不是污染，是上游拒绝服务；若为NOERROR但 ANSWER SECTION 返回了私网 IP，才是典型污染特征
systemd-resolved 是不是在偷偷转发到内网 DNS
Ubuntu/Debian/RHEL 8+ 默认启用 systemd-resolved，它会把 DNS 请求自动转发给当前活跃网卡配置的 DNS，而双网卡环境下极易把内网 DNS（比如 10.0.0.2）设为首选，导致所有域名都被强制走内网解析链路。
- 运行
resolvectl status，重点看 “Global” 下的 “DNS Servers” 和各 Link 下的 “DNS Servers” —— 如果某个 Link（如 eth0）带了内网 DNS 且状态是 “configured”，它大概率正在参与解析 - 检查
/etc/systemd/resolved.conf：若FallbackDNS=被设成内网地址，或Domains=~.这类通配配置存在，就会让所有查询无条件转发到该 DNS - 临时禁用它验证：
sudo systemctl stop systemd-resolved && sudo systemctl disable systemd-resolved，然后手动改/etc/resolv.conf指向8.8.8.8，再测dig example.com—— 若恢复正常，问题就出在这里
怎么抓出是哪台设备在篡改 DNS 响应
污染不一定是本机软件干的，更常见的是局域网内的中间设备：路由器、防火墙、甚至某台被黑的 Windows 主机开了“DNS 代理服务”。这时候得用抓包定位：
- 在出问题的 Linux 机器上运行：
sudo tcpdump -i any port 53 -w dns.pcap，然后立刻执行一次dig example.com - 用 Wireshark 打开
dns.pcap，过滤dns && ip.dst == 127.0.0.1，看“Query”发出后，哪个 IP 回复了“A”记录 —— 如果回复方不是你配的 DNS（比如你配了8.8.8.8却收到192.168.1.1的响应），说明请求被中间设备截获并伪造了应答 - 特别留意 UDP 包的 TTL：如果响应包 TTL 是 64（Linux 默认），但来源 IP 是局域网地址，基本可断定是本地网络设备冒充 DNS 服务器发包
为什么改了 /etc/resolv.conf 还没用
因为很多发行版（尤其是 NetworkManager 管理的桌面环境）根本不读这个文件，它只是个软链接，真实配置由 NetworkManager 或 systemd-resolved 动态生成：
- 运行
ls -l /etc/resolv.conf：若指向/run/systemd/resolve/stub-resolv.conf或/var/run/NetworkManager/resolv.conf，说明你手动改的内容会被下次网络重连覆盖 - NetworkManager 场景下，需编辑对应连接配置：
nmcli connection modify "Wired connection 1" ipv4.dns "8.8.8.8"，再nmcli connection down && up - systemd-resolved 场景下，不能改
/etc/resolv.conf，得用resolvectl dns eth0 8.8.8.8显式设置某网卡的 DNS，否则它仍会按策略 fallback 到内网地址
真正的难点不在命令怎么敲，而在于污染往往跨层存在：systemd-resolved 把请求转给 NetworkManager，NetworkManager 又从 DHCP 拿到被篡改的 DNS，DHCP Server 又是路由器内置的……所以排查时必须一层层切掉中间环节，用 dig @xxx 直连验证，否则永远在猜。
