搜索 K
Appearance
适用对象:已部署 OpenWrt / iStoreOS 软路由,正在使用 OpenClash(Meta 内核),并希望彻底解决「DNS 泄漏」「国内网站解析飘到海外」「ChatGPT 提示地区受限」这三类顽疾的中高级玩家。
先把结论摊开,后面全是论证过程。
核心矛盾只有一个:国内域名必须用国内递归解析(否则 CDN 就近失败、视频卡顿、下载龟速),国外域名必须避开明文 UDP 53(否则被抢答污染、被 QoS 丢包)。 这两件事在物理层面是互斥的,所以任何「一套 DNS 打天下」的方案本质上都是在牺牲一端。
正确的解法是按域名分流 + 分层缓存 + 加密出口:
223.5.5.5 / 119.29.29.29 / 运营商本地 DNS,并携带 ECS(EDNS Client Subnet)扩展,让 CDN 调度器看到你的真实出口网段。restart 后走 OpenClash 的流量),避免 TCP 443 层的 SNI 阻断导致 DoH 本身超时。concurrent: 2 并发查询 + 快速失败,避免单上游挂掉导致整网解析停滞。90% 的所谓「DNS 泄漏」其实不是 MosDNS 配错了,而是下面四件事之一:
2400:3200::1 之类的公网地址直出;198.18.0.0/16 回程,Fake-IP 被当成真实 IP 打出去。这套方案的验证标准很硬:dnsleaktest.com 的 Extended Test 只出现你代理节点所在地的解析器,且国内站点 dig 出来的 IP 归属地与你的宽带运营商一致。
要谈「防泄漏」,先得把链路拆开。
第一层:明文 UDP 53 的无状态抢答。 DNS 查询默认走 UDP 53,无连接、无握手、无序列号校验(只有 16 位 TxID 和源端口做弱校验)。中间设备只要能在权威服务器响应到达之前,抢先注入一个「看起来对」的响应包,客户端就会采信。这就是污染的原理——它根本不需要阻断你的查询,只需要比真答案快。被污染的答案通常指向一个黑洞 IP 或者不属于目标服务的公网地址。
第二层:针对境外递归解析器的定向处理。 8.8.8.8、1.1.1.1 这类地址的 UDP 53 在跨境链路上会遭遇明显丢包和延迟抖动。结果是解析超时 → 客户端 fallback 到备用 DNS → 备用 DNS 是运营商下发的明文 DNS → 又回到第一层。这就是为什么很多人「配了加密 DNS 还是泄漏」,因为主上游超时后系统自动降级了。
第三层:SNI 与 DNS 的关联阻断。 即使你拿到了正确的 IP,TCP 443 握手里的 SNI 字段依然是明文的。所以「防污染」和「防阻断」是两个独立问题,DNS 只解决前者。
第四层:ECS 与 CDN 调度的博弈。 国内主流 CDN(阿里云 CDN、腾讯云 EdgeOne、网宿、白山)依赖 EDNS Client Subnet 或者递归解析器的出口 IP 来定位用户。如果你的国外域名走加密 DNS 没问题,但国内域名也走了国外递归,那么 CDN 会认为你在海外,把你调度到香港或新加坡的节点——国内访问一个电商站点绕道香港,延迟从 15ms 变成 80ms 是常态。这就是「国内 CDN 精准解析」这个需求的技术来源。
第五层:IPv6 的隐性旁路。 绝大多数软路由教程只讲 iptables -t nat 的 IPv4 劫持,忘了 ip6tables。双栈环境下,操作系统会并行发出 A 和 AAAA 查询,AAAA 走 IPv6 链路的明文 53,泄漏就这么发生了,而且在很多检测工具上不明显。
理解了这五层,你就会明白:MosDNS 的价值不在于「加密」,而在于它能在同一个进程里,把「哪些域名走哪条路、带不带 ECS、缓存多久、失败了怎么兜底」这件事描述清楚。
MosDNS 是用 Go 写的 DNS 转发器,v5 之后彻底插件化。它的模型非常干净:
udp_server / tcp_server / doh_server /