关于DNS泄露二三事

在一些科学论坛刷帖，经常看到有朋友截图问自己是不是DNS泄露了。不管是从主贴还是从回复来看，总感觉大家对DNS泄露还是不太能说的清楚。

今天闲来无事，加上之前刚好研究过一波，发个贴记录下自己的理解。挑战下我能不能讲清楚：

什么是DNS泄露？
为什么说FakIP能省一次DNS？
全局就能避免泄露吗？
以及怎么配置能防泄露？

继续之前，大家可以先通过这个网站来测试下，自己有没有DNS泄露：https://ipleak.net/ 开启魔法后访问，如果下面出现了有大陆的运营商，那就是有可能泄露了：

ipleak

下面内容可能很难避免要提到魔法相关，我尽量隐晦，主要还是讲DNS

1. 概念
2. FakeIP
3. 猫咪的DNS都发生在什么时候
4. 怎么配置能防DNS泄露
- 4.1. DNS
- 4.2. 路由
5. 一些常见问题
- 5.1. 是不是开全局就能避免泄露
- 5.2. 有必要上mosdns这些吗
6. 参考
7. 尝试回答下评论区问题

1. 概念

开始之前，先快速理清几个概念。不八股，只说人话。

1.1. 什么是DNS？

全称Domain Name System，域名解析系统，就是把域名换成IP，把baidu.com换成110.242.68.66

1.2. 为什么需要DNS？

因为TCP/IP协议的通信，是基于IP与IP之间的通信，连通之前，必须知道对方的IP地址才行。浏览器想访问baidu.com，发起TCP/IP请求的报文里必须要有它的IP地址。哪来的？发起DNS查来的。

1.3. 什么是DNS泄露？

简单说，就是在使用魔法访问油管时，查油管IP的DNS请求，不是从魔法服务器发出的，而是从我们本地网络发出的(或者发出过)，就是泄露了。

仔细想想，也好理解，因为访问油管需要通过我们的中间服务器来做跳板，那么本机就不需要DNS了，跳板机去拿DNS就行了。

而且本地DNS拿到的IP本身就是不可靠的，一方面可能是脏的（被污染了）；另一方面，就算没脏，但因为很多站会做DNS负载均衡，不同地点拿到的IP是不一样的，一般是优化后最接近自己的。我们在本地DNS，拿到一个（假设）油管在新加坡的IP，结果我们的中间服务器在美国，它应该拿离它最近的IP才对，不应该是离本机的。

1.4. 漏了会咋样？

主要2个影响：

一个是，我们所在地的运营商收到了DNS请求，它就知道我们在访问某个站，隐私泄露了。如果访问的是很特殊的站，据说也有被六扇门关注的可能。

另一个是，很多网站本身也会根据DNS来判断用户的实际所在地，比如有些流媒体和AI，他们发现虽然请求IP是来自美国的我们的中间服务器，但是DNS却来自大陆，显然有问题，就不提供服务了。

要说泄露有多危险的话，其实也还好。 对于小站的泄露，其实无所谓，如果很重要，DNS其实早就不会让通了，就给脏了；对于大站（比如谷哥、油管这种），已经给脏了，漏了的话，确实会让别人知道我们在访问它，但真说会单根据这个请喝茶，感觉也小题大做了；但对于有些目的极其不纯，甚至危害很大的站（比如轮啥的），如果不小心访问到了，又漏了，可能就有被关注的风险了。

2. FakeIP

FakeIP是啥？为啥需要它？

其实就是为了解决上面说的，当流量是走中间服务器时，本机是不需要（也不应该）发起DNS请求的。但TCP/IP链接的建立又需要有个IP，所以，那就给个假的吧（一般是198.18.x.x），单纯用来建立链接使用。当最后中间服务器真正请求时，再从它发起真正的DNS。

这就是为啥大家老是说，用FakeIP可以省一次DNS。

那在FakeIP模式出来之前，都是怎么处理DNS的呢？都引起了哪些问题？ 这里就不扩展了，大家自己理解。

3. 猫咪的DNS都发生在什么时候

这里以猫咪为例。

第一次，浏览器访问某站，需要建立TCP/IP链接，需要一个IP，发起DNS，流量进入猫咪，触发FakeIP，返回一个假的198.18.x.x

然后，浏览器建立链接，发起请求，请求进入猫咪，猫咪会通过FakeIP还原出原始的域名，拿着这个域名进行路由，看应该走直连还是魔法。

第二次，路由时，有两种情况，

第一种，根据域名，很快就判定应该直连，也就是直接请求就行了。为了与真实站点建立链接，会发起DNS，拿到真实IP，并去访问它
第二种，按顺序找路由，一直没命中，直到遇到一个根据IP匹配路由的规则，但当前又是域名，驴头对马嘴，没法匹配，所以，猫咪会发起一次DNS，尝试用手里的域名换到真实IP，用这个IP来跟路由规则做匹配。如果匹配上直连，就直接去连接了。如果是需要魔法，会将流量转发到我们的魔法服务器。

这里面，最容易发生DNS泄露的，其实就是第二次里的第二种情况。

那能不能匹配IP规则的路由时，不要去DNS，手里是域名，就直接跳过，接着去匹配后面的。其实可以的，大部分工具也都是这么处理的（没记错的话sing-box默认也是这个逻辑）。但猫咪需要特别指定下，就是大家常说的no-resolve，下面贴配置。

4. 怎么配置能防DNS泄露

以下还是以猫咪为例，模式为Tun + FakeIP

4.1. DNS

如果没特殊需求，个人推荐使用FakeIP。


dns:
  enable: true
  ipv6: true
  enhanced-mode: fake-ip
  listen: 53
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
  - '*.lan'
  - '*.localdomain'
  - '*.example'
  - '*.invalid'
  - '*.localhost'
  - '*.test'
  - '*.local'
  - '*.home.arpa'
  - time.*.com
  - time.*.gov
  - time.*.edu.cn
  - time.*.apple.com
  - time1.*.com
  - time2.*.com
  - time3.*.com
  - time4.*.com
  - time5.*.com
  - time6.*.com
  - time7.*.com
  - ntp.*.com
  - ntp1.*.com
  - ntp2.*.com
  - ntp3.*.com
  - ntp4.*.com
  - ntp5.*.com
  - ntp6.*.com
  - ntp7.*.com
  - '*.time.edu.cn'
  - '*.ntp.org.cn'
  - +.pool.ntp.org
  - time1.cloud.tencent.com
  - music.163.com
  - '*.music.163.com'
  - '*.126.net'
  - musicapi.taihe.com
  - music.taihe.com
  - songsearch.kugou.com
  - trackercdn.kugou.com
  - '*.kuwo.cn'
  - api-jooxtt.sanook.com
  - api.joox.com
  - joox.com
  - y.qq.com
  - '*.y.qq.com'
  - streamoc.music.tc.qq.com
  - mobileoc.music.tc.qq.com
  - isure.stream.qqmusic.qq.com
  - dl.stream.qqmusic.qq.com
  - aqqmusic.tc.qq.com
  - amobile.music.tc.qq.com
  - '*.xiami.com'
  - '*.music.migu.cn'
  - music.migu.cn
  - '*.msftconnecttest.com'
  - '*.msftncsi.com'
  - msftconnecttest.com
  - msftncsi.com
  - localhost.ptlogin2.qq.com
  - localhost.sec.qq.com
  - +.srv.nintendo.net
  - +.stun.playstation.net
  - xbox.*.microsoft.com
  - '*.*.xboxlive.com'
  - +.battlenet.com.cn
  - +.wotgame.cn
  - +.wggames.cn
  - +.wowsgame.cn
  - +.wargaming.net
  - proxy.golang.org
  - stun.*.*
  - stun.*.*.*
  - +.stun.*.*
  - +.stun.*.*.*
  - +.stun.*.*.*.*
  - heartbeat.belkin.com
  - '*.linksys.com'
  - '*.linksyssmartwifi.com'
  - '*.router.asus.com'
  - mesu.apple.com
  - swscan.apple.com
  - swquery.apple.com
  - swdownload.apple.com
  - swcdn.apple.com
  - swdist.apple.com
  - lens.l.google.com
  - stun.l.google.com
  - +.nflxvideo.net
  - '*.square-enix.com'
  - '*.finalfantasyxiv.com'
  - '*.ffxiv.com'
  - '*.mcdn.bilivideo.cn'
  - WORKGROUP
  default-nameserver:
  - 223.5.5.5
  - 119.29.29.29
  nameserver:
  - https://223.5.5.5/dns-query
  - https://223.6.6.6/dns-query
  - https://1.12.12.12/dns-query
  - https://120.53.53.53/dns-query
  nameserver-policy: null
  fallback: null
  fallback-filter: null

nameserver要配国内的DNS服务，可以是当地运营商的。

很多人会配很复杂的nameserver-policy和fallback，但对DNS泄露来说其实作用不大，再捋一捋之前的流程就知道了。

4.2. 路由

路由规则里，有根据IP规则来路由的，都加上no-resolve


rules:
  - RULE-SET,applications,DIRECT,no-resolve
  - DOMAIN,clash.razord.top,DIRECT
  - DOMAIN,yacd.haishan.me,DIRECT
  - RULE-SET,private,DIRECT,no-resolve
  - RULE-SET,reject,REJECT,no-resolve
  - RULE-SET,icloud,DIRECT,no-resolve
  - RULE-SET,apple,DIRECT,no-resolve
  - RULE-SET,google,PROXY,no-resolve
  - RULE-SET,proxy,PROXY,no-resolve
  - RULE-SET,direct,DIRECT,no-resolve
  - RULE-SET,lancidr,DIRECT,no-resolve
  - RULE-SET,cncidr,DIRECT,no-resolve
  - RULE-SET,telegramcidr,PROXY,no-resolve
  - GEOIP,LAN,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

注意RULE-SET里面的IP规则也要加上no-resolve，参考：https://github.com/blackmatrix7/ios_rule_script/blob/e2a851d0e2a9d69a5d619da1e6a64183039f38cb/rule/Clash/YouTube/YouTube_No_Resolve.yaml#L191

完整的配置其实没必要贴，因为每个人的分组和路由习惯不一样。但我猜到肯定会有朋友要，这里分享一个最近看到的不错的模板作为参考：https://github.com/zuluion/Clash-Template-Config/blob/master/Clash-Template-Config.yml

5. 一些常见问题

5.1. 是不是开全局就能避免泄露

一般来说，是的，但不推荐。这样用起来很不方便，都有路由系统了，为啥开倒车，自己手动来回切太原始。

那有没有不一般的情况导致全局了还是会DNS泄露？也是有的。有些特殊场景下，比如基于UDP的quic协议，可以参考这个：https://hostloc.com/thread-1315189-1-1.html 和 https://github.com/MetaCubeX/mihomo/issues/1152

建议可以浏览器里直接把quic协议关了解决：chrome://flags/#enable-quic

5.2. 有必要上mosdns这些吗

如果只是为了防泄露，没必要，或者说起不到太大作用。

mosdns能一定程度防泄露，是因为它内部维护了一套规则，实现绝大部分常见域名的分流。

但悖论是，我们如果信任这套分流规则，完全可以直接把它直接配到猫咪里，实现效果一模一样的。如果不信任，那用了mosdns一样会泄露。而且维护两套规则，本身也很累。路由有问题后，不仅要查猫咪，还要再去查mosdns。

所以，如果不是特殊需求（dns缓存、IP择优这些），仅仅是为了防泄露，就没必要使用mosdns了，只会增加复杂度。

6. 参考

为了便于理解，用了很多口语化的表达。如果有不准确的地方，或者有可以补充的地方，欢迎回帖一起讨论。

目录