type
status
date
slug
summary
tags
category
icon
password
DNS泄露是大多数用户并不关心的部分，但也是小部分用户或者强迫症爱好者会纠结的部分。至于泄露之后真正会造成什么样的后果，现在并没有任何确凿的示例，但是秉承着在这个灰色地带尽量安全的准则，以及为了满足自己无尽的动手欲，今天就来尝试通过对自己的整体网络链路进行入手分析，寻找存在的DNS泄露点，以及进行修复。这是一个从2023年就一直在不断讨论的话题，今天我也加入进来。
首先，我们来了解一下什么是DNS泄露：
DNS泄露是指在使用VPN（虚拟专用网络）时，用户的DNS请求绕过VPN隧道，直接通过用户的本地网络发送给互联网服务提供商（ISP）的DNS服务器，而不是通过VPN提供的DNS服务器进行解析。这种情况会暴露用户的真实IP地址、位置和浏览活动，从而削弱了使用VPN所提供的隐私和匿名性。通常，VPN的一个重要功能是加密和隐藏用户的流量，包括DNS请求。但是，如果VPN配置不当或存在漏洞，DNS请求可能不会被加密或路由到正确的DNS服务器，导致信息泄露。这种泄露可能让ISP或其他第三方能够监视用户的上网行为，甚至在某些情况下，影响用户访问内容的安全性。
那么在国内来说，DNS泄露就可能会被ISP知晓你要访问什么网站，从而被识别，劫持至反诈页面或者被短信提醒。根据我的个人体验，在解决完家里DNS泄露的问题之后，目前还没有再被劫持到反诈页面，之前访问Linux.do都会被劫持。
📝 付费内容
DNS请求链路
AdGuard Home：作为监听在
53端口的默认DNS服务，替代Dnsmasq，这也可以使AdGuard Home与OpenClash共存。旁路网关不需要承担DHCP的任务，所以可以直接替换。AdGuard Home可以提供全局的、并且可视化的DNS请求记录查询功能，以及可以快速添加过滤广告功能，这是我所需要的。 MosDNS:作为AdGuard Home上级DNS服务器使用，通过策略进行DNS分流，国内DNS加速，污染请求转发至上级OpenClash的DNS服务。在广告过滤的功能上，MosDNS完全可以替代AdGuard Home，但是由于缺少可用性较好的面板，所以在我这里还无法完全替代AdGuard Home的工作。
OpenClash：作为整体DNS链路的最后一环，单纯提供针对需要代理服务的域名进行解析并返回查询结果，所以关闭DNS劫持，由AdGuard Home和MosDNS负责DNS工作，使三者共存。其实OpenClash对dnsmasq的依赖主要就在于DNS和实验性：绕过中国大陆IPv4这两部分，完全是可以替代掉。
发现问题
1. AdGuard Home泄露排查
在解决问题之前，我们需要先发现问题。
首先通过IP/DNS Detect - What is your IP, what is your DNS, what informations you send to websites. (ipleak.net)进行DNS泄露情况查看，可以看到在未进行整体DNS请求链路调整之前的DNS泄露情况。
同时，通过在AdGuard Home进行日志查询，可以看到具体进行DNS解析请求的域名，一般来说是一个三级域名，类似于
yw9dmycvn53p2zedczygrbjx4v5anjd2as23ly3w-32.ipleak.net 这种。其原理大概是通过生成大量的三级域名让我们请求解析，从而获取我们完整的DNS服务器配置，当这里出现五星红旗及大陆IP时候，即证明已经产生的DNS泄露。 同时经过上述测试，在这里我们可以确认：
- Adguard Home提供的DNS服务正常
- 客户端的DNS请求是通过Adguard Home向上级转发，也就是转发给MosDNS进行处理，并且转发成功。
- 由于我的Adguard Home的DNS设置中，上游DNS只有Mosdns一个地址，那么可以确定问题不是出在Adguard Home这里，可以继续向上排查。
2. MosDNS泄露排查
我对目前我的MosDNS序列执行重新画了流程图。同时我也建议你这么做，这样可以更好的了解MosDNS在你进行域名解析请求的时候都发生了什么，也能更好的了解自己所使用规则的运作原理及解析过程。我的配置文件是使用的Jasper-1024编写的配置文件，地址为：mosdns_docker/mosdns_v5 并在此基础上进行了修改，增加了污染域名的直接远端请求，同时去掉了并发请求DNS服务器，以及根据自己的需要进行了ECS中请求所使用IP地址的修改。
修改后我的流程如下：
- qtype65判断：
QTYPE65是指一种特定的 DNS 查询类型，正式名称为 HTTPS（也称为 SVCB 或 Service Binding）。这种查询类型的数字标识符为 65，是 DNS 协议中的一部分，用于增强安全性和优化连接。但由于QTYPE65的相对新颖性和对新技术的依赖，它在实际使用中还不如传统的 A、AAAA 等 DNS 记录普及，且反而容易产生污染，所以拒绝，也不存在泄露的可能性。
- 无效域名和keyword为空域名：垃圾请求，拒绝，不存在泄露可能性。
- qtype12：PTR请求，通过序列
query_other丢给上级DNS服务查询，本级不存在泄露可能。
- qtype255：DNS扩展请求，通过寻猎
query_other丢给上级DNS服务查询，本级不存在泄露可能。
- 私有IP及geosite_private：本地请求，不涉及外网请求，交由
query_lan本地化处理，本级不存在泄露可能。
- 广告及geosite_ad_all：广告的DNS请求，直接本级处理，丢弃，不存在泄露可能。
- 缓存检查：不存在直接泄露可能，但可能会存在污染被缓存可能。
- cn域名判断：通过
query_cn进行国内DOH/DOT公共DNS查询，本级不存在泄露可能。
- GFW域名判断：通过篇
query_gfw直接转发请求至OpenClash远端处理，本级不存在泄露可能。
- 非cn域名判断：通过
query_nocn使用cloudflare及nextdns查询，并对结果进行过滤，解析结果为国内IP的请求将继续通过序列向下进行查询。
- no_ecs队列：没有什么用的一个执行片段，不产生dns请求，同时也不存在泄露可能。
- query_fallback序列：将最终未能成功解析的域名执行
fallback片段，交由OpenClash进行远端解析请求，本层级不存在DNS泄露可能。
- 日志查询：对日志文件进行查询，发现所有关于
*.ipleak.net的域名解析全部走的query_fallback,也就是交给OpenClash进行域名解析。
通过对整体MosDNS序列的分析，我认为泄露点并不在MosDNS这部分，应该在OpenClash这部分。
3. OpenClash泄露排查
查看日志发现：
也就是DNS的请求最终没有通过OpenClash进行远端解析，而是使用了nameserver或者default nameserver所配置的服务器进行了DNS解析。而我的nameserver组里恰好就阿里的223.5.5.5。
在OpenClash的issue中也有人反应过：OpenClash会同时使用fallback组和nameserver组进行请求（[Bug] dns泄露 #3843）。也就是说
fallback最终back回了国内，反而污染了已经分流好的域名请求。在OpenClash中，由于DNS的解析工作已经由下游的MosDNS完成了一部分，剩下的一部分应该交由上游的代理进行解析，自身并不需要再提供繁杂的DNS规则配置工作，那么也就应该简化原有的配置。
- nameserver：在不配置
proxy-server-nameserver时，nameserver作为默认解析代理节点的dns服务器，同时考虑到dns污染及泄露可能，我这里配置了一个nextdns的服务器。
- fallback：fallback规则在具有远端DNS请求及MosDNS分流的情况下，不再具有任何意义，所以我将所有的fallback服务器删除。
- default-nameserver：默认DNS,用于解析DNS服务器的域名，由于我们并没有在OpenClash中使用任何域名形式的DNS，所以可以不必填写。但为空时可能会将订阅文件中的值填充至config.yaml中，所以我填了一个nextdns的ip地址。
- 追加上游DNS：取消勾选，不需要追加。
- 追加默认DNS：取消勾选，不需要追加。
- Fallback-Filter：取消勾选，不用fallback。
- nameserver-policy：取消勾选，分流已经由MosDNS完成，且geoip和geosite文件是同源文件，没必要重复分流两次。
- 应用配置。
这样配置的好处是，不用对GEOIP,CN进行
no-resolve处理，不需要OpenClash进行兜底规则配置，简单粗暴，也就不用自己动手去修改配置文件，同时也对Dnsmasq的依赖程度降到了最低。🤗 总结归纳
执行结果直接上一张图吧：
国内DNS泄露基本上是解决了。出乎意料的是也没有出现经常看到的IPv6容易造成DNS泄露的问题。
我常用的dns，国内还是会选择阿里巴巴（Alibaba）或者腾讯（dnspod），因为提供DOH，甚至可以提供H3，不使用运营商的DNS主要就是因为无法提供DOH，而且很多时候会被劫持到反诈；国外的话主要使用Cloudflare（赛博菩萨）或者NextDNS，最多再从AdGuard或者9.9.9.11中选择一个。IPv6的话没必要单独配置IPv6地址的DNS，同一个服务器也可以解析IPv6的请求。
目前这套配置下，在AdGuard Home开启乐观缓存的情况下，请求解析时间也可以接受：
以上这些也仅供参考。
查询DNS泄露的网站
一般来说，以ipleak为例，如果全部300次请求都没有产生泄露，那么就大概率没有DNS泄露。
📎 参考文章
有关DNS的问题，欢迎您在底部评论区留言，一起交流~