STELINK · 隐私与解析
DNS污染
DNS 污染指的是域名解析结果被中途篡改：查询发出去了，回来的却是一个错误甚至不存在的 IP 地址。它可能让你打不开网站、被引到错误位置，或让访问速度异常缓慢。好消息是，它有成熟的排查与防护方法。
- 加密 DNS（DoH/DoT）
- DNSSEC 验证
- 解析随隧道转发
DNS 污染是怎么发生的
打开一个网站前，设备要先把域名解析成 IP 地址。传统 DNS 查询使用明文、无连接的协议，应答与请求的匹配只依赖很弱的标识信息，路径上的设备完全可以抢在真实应答之前，伪造一个“看起来正确”的结果塞给解析器。
这类干扰有两种常见形式：一种是在查询路径上实时注入伪造应答，让每一次解析都拿到错误 IP；另一种是往解析服务器的缓存里投放错误记录（缓存投毒），影响范围更大、持续更久。与之相关的还有“DNS 劫持”——查询被直接引导到其他服务器处理，往往伴随广告页或错误跳转。
三种情况的共同结果都一样：解析结果不再可信。轻则网站打不开、解析到很远的节点导致龟速，重则被引导到仿冒站点，带来账号与支付风险。
怎么判断 DNS 被污染
最直接的方法，是拿两个不同的解析器查同一个域名，看结果是否一致：
- macOS / Linux：
dig +short @8.8.8.8 example.com - 对照一次：
dig +short @114.114.114.114 example.com，两个结果不同就要警惕 - 强制走 TCP 再查：
dig +tcp @8.8.8.8 example.com - Windows：
nslookup example.com 8.8.8.8
典型的污染特征包括：
- 返回
0.0.0.0、127.0.0.1这类明显异常的地址； - 同一域名短时间内多次查询，结果互相矛盾；
- 返回的 IP 归属地与网站实际部署地区完全不符；
- 解析记录的有效时间（TTL）与正常结果差异明显。
防止 DNS 污染的 5 种做法
1. 加密 DNS：DoH / DoT / DoQ
把解析查询放进加密通道，是防污染的基础。DoH 走 HTTPS（443 端口），DoT 走独立 TLS（853 端口），路径上的设备既看不到查询内容，伪造的应答也过不了加密校验。Windows 11、Android 较新版本和主流浏览器都已内置支持，无需安装额外软件。
需要了解的局限：加密 DNS 保护的是“解析过程不被篡改”，如果解析服务器本身连不上，加密也无从谈起——在受限网络里通常要让加密 DNS 流量一起走代理，见第 4 条。
2. 选择可信的解析服务
Cloudflare（1.1.1.1）、Google（8.8.8.8）、Quad9（9.9.9.9）等公共解析服务都提供
DoH /
DoT；国内阿里、腾讯等也提供加密解析，速度更快，但按合规要求会做内容过滤，查部分域名未必能拿到真实结果。需要更细粒度控制（去广告、防追踪、查询统计）的话，可以考虑
NextDNS、AdGuard DNS 这类托管解析。
3. 自建递归解析 + DNSSEC
自己运行一个递归解析器（Unbound、Knot Resolver、AdGuard Home、Pi-hole 均可），从根域名服务器开始逐级查询，不再依赖公共缓存，同时开启 DNSSEC 验证：被伪造的应答会因签名校验失败被直接拒绝，而不是把错误 IP 交给你。注意两点：未部署 DNSSEC 的域名不受保护；明文递归查询在受限网络中仍可能被干扰，上游建议走加密或隧道。
4. 让解析随隧道转发
把解析请求和流量一起送进连接隧道，在出口由可信解析服务完成解析——本地网络根本看不到你的解析请求，注入也就无从下手。这是大多数网络环境下最省事、最稳定的组合。选择这类方案时确认三点：客户端能接管系统解析；具备防 DNS 泄露能力；分流规则里不要把 DNS 查询单独放行直连。
5. hosts 与固定 IP：只救急
把域名和 IP 手动写进 hosts 文件，能临时解决个别网站打不开的问题。但 CDN 地址经常变化、换网络就可能失效、也覆盖不了全部域名；而且它只绕过了解析层，上层的流量干扰依然存在。应急可以，不建议长期依赖。
各平台设置速查
| 平台 | 位置与做法 |
|---|---|
| Windows 11 | 设置 → 网络和 Internet → 以太网 / Wi-Fi → DNS 服务器分配：手动填写地址后，开启“通过 HTTPS 的 DNS” |
| macOS / iOS | 安装 DoH / DoT 描述文件（Cloudflare、NextDNS 等官方提供），或安装对应 App 开启系统级防护 |
| 安卓 9+ | 设置 → 网络与互联网 → 私人 DNS，填 one.one.one.one 或 dns.google |
| Chrome / Edge | 设置 → 隐私和安全 → 安全 → 使用安全 DNS（自定义 DoH 地址） |
| Firefox | 设置 → 隐私与安全 → 启用基于 HTTPS 的 DNS |
| 路由器（OpenWrt 等） | 安装 https-dns-proxy 或 AdGuard Home，让全屋设备统一生效 |
星链VPN 的处理方式
星链VPN 把解析与流量统一纳入连接隧道，由出口侧的可信解析服务完成解析，并提供防 DNS 泄露与 IPv6 保护：
| 能力 | 说明 |
|---|---|
| 解析随隧道转发 | 客户端接管解析请求，由隧道出口完成解析，本地网络无法注入伪造应答 |
| 防 DNS 泄露 & IPv6 保护 | 双栈环境下解析与出口保持一致，避免请求从其他链路旁路 |
| AES-256 加密与自研随机混淆协议 | 解析与流量特征同时受到保护，降低被识别与干扰的概率 |
| 零信任架构与无日志策略 | 按不依赖信任假设的思路设计链路，并以不保留浏览记录为目标 |
| 60+ 地区节点与多平台客户端 | Windows、macOS 13+、Android 6.0+ 与 iOS / iPadOS 均提供客户端 |
常见误区
| 误区 | 实际情况 |
|---|---|
| “把 DNS 换成公共地址就解决了” | 明文查询依然可能被路径注入，关键是用加密 DNS 或让解析随隧道转发 |
| “开了 DoH 就万事大吉” | 需确认解析端点可达、系统级生效（而非仅浏览器），其他应用不要旁路 |
| “DNSSEC 可以彻底防污染” | 它能验证应答真伪、拒绝被篡改的结果，但不能保密、不能阻止查询被阻断，未签名域名不受保护 |
| “加密 DNS = 完全隐身” | 解析只是链条中的一环，出口地址与流量特征仍然是可被观察的线索 |
日常防护建议
- 优先在系统或路由器层面统一开启加密 DNS，而不是只改单个浏览器。
- 完成客户端连接后再访问对解析敏感的服务，减少连接前缓存到错误结果的可能。
- 更换网络环境（公司、酒店、公共 Wi-Fi）后重新自查一次。
- 分流规则中不要把 DNS 查询单独放行直连，让它和流量走同一条路径。
- 修改解析设置后，用对照查询或检测页面复测一次再长期使用。
- 保持客户端与系统更新，出现异常时先切换节点或重新连接，再逐项排查。
相关关键词
继续浏览其他说明页面：
常见问题
DNS 污染是什么？
DNS 解析负责把域名翻译成服务器地址。传统 DNS 查询是明文、无连接的，路径上的设备可以抢先伪造一个应答，让设备拿到错误的 IP 地址，这就是 DNS 污染，会导致网站打不开或解析到错误位置。
怎么判断自己的 DNS 被污染了？
用两个不同的解析器查询同一域名并对比结果，如果返回 0.0.0.0、127.0.0.1 等异常地址，或多测几次结果互相矛盾、IP 归属地与网站实际不符，就很可能遇到了污染；也可以用全球多节点解析查询工具交叉验证。
防止 DNS 污染最有效的方法是什么？
把明文查询换成加密 DNS（DoH 或 DoT），并确保解析请求随连接隧道一起转发。前者防止应答被伪造，后者让本地网络根本看不到解析请求；进阶用户还可以自建递归解析并开启 DNSSEC 验证。
为什么把 DNS 换成 8.8.8.8 还是打不开网站？
传统 DNS 查询走 53 端口的明文传输，路径上的设备依然可以抢先伪造应答。更换解析地址并不等于加密查询，需要改用 DoH/DoT 等加密方式，或让解析请求随隧道转发。
DoH 和 DoT 有什么区别？
两者都是加密解析：DoH 走 443 端口，与 HTTPS 流量混在一起不易被识别；DoT 使用独立的 853 端口。日常使用无需手动取舍，保持系统或客户端的一种统一配置即可。
自建 DNS 服务器能防止污染吗？
自建递归解析器从根域名服务器逐级查询，不依赖公共缓存，配合 DNSSEC 验证可以识别并拒绝伪造应答；但明文递归查询在受限网络中仍可能被干扰，上游解析建议走加密或隧道。
DNSSEC 是所有域名都支持吗？
不是。DNSSEC 需要域名方部署签名后才生效，主流站点覆盖较好，但不少小站与部分区域域名尚未启用，这些域名不受 DNSSEC 保护。
hosts 文件可以长期使用吗？
不建议。CDN 地址会变化、换网络可能失效、覆盖不了全部域名，而且它只绕过了解析层，无法解决上层的流量干扰，只适合临时应急。