使用本地双层 DNS 过滤（Xray+smartDNS）降低 DNS 泄漏概率 #1983

picklefan · 2023-04-22T12:02:25Z

picklefan
Apr 22, 2023

结论：只要你分流，DNS泄露就是可以被检测的，对观察者来说露没露取决于他的观测手段，你只能降低被检测到的概率。

以下方法仅能降低一定概率，并不能避免泄露，若有表述为解决泄露的，请脑动替换为降低概率，我懒得改了。要是你理解分流必然能被检测出泄露那么你不需要看了。

该教程只讲解软路由透明代理环境下的解决方案（其他环境可以看个思路）

什么是DNS泄漏？

按照油管不良林的说法和我的理解，导致 DNS 泄漏 的原因是 查询域名时使用的 IP 与 实际访问网站的 IP 区域差距太大。具体原理请谷歌或者看 不良林 的视频。
那么我们需要做的事情就是保持 DNS 查询 和 访问 出口的一致性，也就是说：

当你访问的网站需要通过代理时，它的 DNS 请求也需要通过代理。

为了实现这一点，最简单的方法就是，把 DNS 的规则和 routing 的规则写成一样的，比如：

DNS 规则为 geosite:cn 通过114查询，其他通过1.1.1.1查询
routing 规则为 geosite:cn direct, 其他 proxy

以上做法可以保持 DNS 查询 和 访问 出口的一致性，但是问题就在于实际使用上 routing 的规则往往比较复杂，并且 routing 的查询策略和 dns 的不一样，routing 是从上往下按顺序匹配规则，而 dns 是先匹配规则，然后把匹配到规则的 server 排到前面然后再按顺序查询。
所以即使你把两个的规则写成纸面上的一致，实际执行的结果也是不一致的。
而我们需要做的就是根据 routing 的规则来写 dns规则，使得他们的执行结果保持一致（你 proxy 我也 proxy）
根据 routing规则的不同，写 dns 的困难程度也不一样，下面讲解一下不同 routing 策略下 dns 的处理方法

ROUTING 策略及对应的 DNS 处理方法

ROUTING 策略为白名单 proxy

白名单 proxy，也就是指定的域名走代理，其他全部直连，这种方法应该没什么人用，毕竟白名单不可能全面，有时候要手动加名单很累。这个解决方法最简单，就是纸面的把两个规则写一样就行了，就不说了。

实际上只要规则不重复就可以保证 `dns` 和 `routing` 的执行结果一致，比如你只使用 `geosite:cn` 。而添加了 `domian:tiktok.com` 之后由于 `tiktok.com` 存在于 `geosite:cn` 和 `domian:tiktok.com` ，会导致 `dns` 和 `routing` 执行结果不一致，具体下面有讲。

ROUTING 策略为 `geosite/ip:cn` 直连，其他代理

这个应该是大多数人使用的策略，如果 geosite:cn 或者 geoip:cn 非常准确的话，那 routing 和 dns 两个规则纸面一致，完全不会有 DNS 泄漏，问题就在于： geosite:cn 误杀太多，比如 tiktok 也在里面，要让 tiktok 也走 proxy 就需要在 geosite:cn 上面加一条 domian:tiktok.com -> proxy。
这在 routing 上是很容易解决的，因为 routing 是按顺序从上到下匹配规则，但是 dns 的匹配策略为：
先匹配规则，规则命中（据我观察只会命中一个）的服务器排在前面，然后按顺序查询。而 geosite:cn 和 domian:tiktok.com 在 dns 的匹配策略下都匹配 tiktok，并且无视顺序，这就导致了 tiktok 在 dns 里面到底匹配到了谁比较随机。
不过根据我观察 geosite 优先级比较高，我看日志 tiktok 都是匹配 geosite:cn 而不是 domian:tiktok.com，所以这时候 tiktok 的 DNS 查询使用的是国内机器，但是访问确是VPS的ip, 两个地理位置相差巨大，导致dns服务器地理差距也巨大，所以出现了 DNS 泄漏。

以上 tiktok 只是举个例子，我只是想说明 dns 和 routing 的匹配策略的不一致导致在一些 routing 规则下，单靠 Xray 的内置 dns 模块无法将 proxy 列表和 DNS 查询列表一致化，需要引入其他软件处理DNS。

引入 smartDNS （本来是用mosDNS 的，但是实在是太菜了，不会用）

引入的目的就是为了解决一些本来应该在远端查询的DNS 请求却在本地查询的问题，如下图，把 CN 的 DNS 请求全部交给 smartDNS，然后再让 smartDNS 处理 “漏网之鱼“

Xray 配置

dnsObject

 "dns": {
    "hosts": {
      "domain:googleapis.cn": "googleapis.com",
      "dns.google": "8.8.8.8"
      //"你的VPS域名": "你的VSP IP" //如果 outbound 的 proxy 里 address 填的域名：希望代理走ipv4，这里 VPS IP 填VPS的ipv4, 希望代理走ipv6，这里VPS IP 填VPS的ipv6；outbound 的 proxy 里 address 填的 IP，这行不用写。
    },
    "servers": [
      "https://1.1.1.1/dns-query",
      {
        "address": "127.0.0.1",
        "port": 1153,//smartDNS 监听端口
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      "https://dns.google/dns-query",
      "1.1.1.1"
    ]
  },

inboundObject

 "inbounds": [
     
      {
        "tag":"dns-in",
        "port":53,//开个53端口代替系统DNS server,这样就算你关了Tproxy也不会把国外请求交给国内DNS server
        "listen":"0.0.0.0",
        "protocol":"dokodemo-door",
        "settings": {
          "address": "127.0.0.1",
          "port":1153,//smartDNS 监听端口
          "network":"tcp,udp"
          
          //"udp": true
      }
  ],

routingObject

"routing": {
    "domainStrategy": "IPOnDemand",
    "domainMatcher": "hybrid",
    "rules": [
      {
        "type": "field",
        "ip": ["233.5.5.5"],//需要把国内DNS查询IP放在第一位，不然会出毛病，不信自己试一试
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["8.8.8.8", "1.1.1.1"],//这个也要放前面
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "inboundTag": ["dns-in"],
        "outboundTag": "dns-out"//dns-out 一般来说需要放在第二位。routing位置很玄学，出问题自己调整顺序，国内dns第一位毋庸置疑，这个第二位或者第三位
      },
      {
        "type": "field",
        "inboundTag": [
            "tproxy-in" // 只劫持来自透明代理入站的 DNS 流量。同上，这三个routing只能放在最上面，
        ],
        "port": 53,
        "outboundTag": "dns-out"
      },
      {
        "type":"field",
        "domain":[
          //"domain:自定义需要proxy的域名",
          
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "outboundTag": "direct",
        "domain": [
          "geosite:cn",
          "domain:grc.com"
          ] // 中国大陆主流网站的域名
      },
      {
        "type": "field",
        "domain": ["geosite:geolocation-!cn"],//放这个是因为我以前经常把outbound的proxy和direct换顺序
        "outboundTag": "proxy"
      }
    ]
  }

outboundObjct

"outbounds": [    
      {
    "tag": "proxy"
    },
  {
    "tag": "direct"
  },
  {
    "protocol": "dns",
    "tag": "dns-out"
}

smartDNS配置（文档写得好，可以看文档自己配置）

smartdns.conf

bind [::]:1153
cache-size 4096
serve-expired yes
serve-expired-ttl 86400

# 过CDN的可以加上下面两条，否则可以忽略，意思是该域名DNS结果不缓存
serve-expired-reply-ttl 9
domain-rules /aaa.com/ -no-cache

# dns-proxy-list.conf 这个文件里面放走国外DNS 查询的域名
conf-file /usr/local/etc/xray/dns-proxy-list.conf
# 给国外的 DNS 查询加代理，不加代理好像会查询失败
proxy-server socks5://127.0.0.1:10808 -name socks5
# 1.1.1.1 来查询国外域名,可以指定多个自己看文档
server 1.1.1.1 -group out -exclude-default-group -proxy socks5
# 127.0.0.1:153 是我本地的另一个DNS server, 可以换成国内DNS server 比如114.114.114.114  ~~套娃真好玩~~
server 127.0.0.1:153

最后我还在本地153端口开了个AdGuardHome, 有webui,用来看dns是否泄漏很方便，~~还可以紧急block DNS 防止泄漏,再顺便看看隔壁邻居再干啥~~

dns-proxy-list.conf 这个名字自己起的爱起啥起啥，要跟这个conf-file /usr/local/etc/xray/dns-proxy-list.conf 对应
好像是支持正则的，自己看文档，我只举例子域名

nameserver /githubusercontent.com/out
nameserver /duolingo.com/out
nameserver /whoer.net/out
nameserver /adguard.com/out
nameserver /ipleak.net/out
nameserver /debian.org/out
nameserver /nodeseek.com/out
nameserver /google.com/out
nameserver /hao123.com/out
nameserver /4399.com/out
nameserver /googlevideo.com/out
nameserver /googleapis.com/out
nameserver /googleusercontent.com/out

再顺便说一下把ipleak.net 加入远端查询列表并不是掩耳盗铃，而是可以检查配置是否正确，如果ipleak.net 没有泄漏，说明列表里面的其他DNS 也没有泄漏。当然也不是绝对不泄漏，人家硬是搞个CN 域名来测试你你也没办法是不是。这套方案是我觉得在能在保证绝大多数外网能走 proxy 的情况下，手动添加远端解析列表最少的方案。DNS泄漏没有一劳永逸的解决方案，除非你要求不高，直接 CN->direct ,OTHERS->proxy那确实可以一劳永逸, fakeDNS 的话没研究过不是很懂不就加个转换层吗，跟泄露有关系？

tomclassplus · 2023-04-24T00:32:22Z

tomclassplus
Apr 24, 2023

1 reply

picklefan Apr 24, 2023
Author

这样子吗，理论错误指的哪里？还请指教

rurirei · 2023-04-30T15:18:56Z

rurirei
Apr 30, 2023

i don't know what you said as dns leakage discribes behaviors not expected onto those dns queries.

0 replies

kulongwangzhi85 · 2023-06-13T02:24:42Z

kulongwangzhi85
Jun 13, 2023

我的做法比这个更快速。我在xray-server端也用smartdns搭建一个dns服务，并在server端新建立一个内网的私有地址。
然后家里的smartdns外网全部转向这个server的私有地址。在网关上将这个私有地址做tproxy到xray-server。

nft防火墙tproxy设置

chain prerouting {
		type filter hook prerouting priority mangle; policy accept;
		iif "ppp0" ct mark { 0x00000001, 0x00000002, 0x00000020, 0x00000021 } return
		meta l4proto { tcp, udp } ip daddr { 1.0.0.1, 1.1.1.1, 8.8.4.4, 8.8.8.8, 9.9.9.9, 172.26.10.168, 172.26.41.253 } tproxy ip to :7073 meta mark set 0x00000001 accept comment "VPS DNS Server"
}
chain output {
		type route hook output priority mangle; policy accept;
		meta l4proto { tcp, udp } ip daddr { 1.0.0.1, 1.1.1.1, 8.8.4.4, 8.8.8.8, 9.9.9.9, 172.26.10.168, 172.26.41.253 } meta mark set 0x00000001 comment "VPS DNS Server"
}

xray-client路由设置

        {
          "type": "field",
          "outboundTag": "quic-proxy",
          "ip": [
		  "172.26.41.253",
		  "172.26.10.168"
	  ],
          "network": "udp"
        },

xray-server路由设置

        {
          "type": "field",
          "ip": [
            "172.26.10.168"
          ],
          "outboundTag": "freedom"
        },

1 reply

picklefan Jun 16, 2023
Author

你对DNS 泄漏可能有一些误解，你这样的操作其实和外网指定1.1.1.1 然后xray proxy 1.1.1.1 没有什么区别。可以再深入了解一下DNS泄漏，百度百科就有。并不是说你的做法不对，我是说你在服务端搭一个DNS 服务器是没有作用的，跟使用公共DNS 没有区别

jiushibushuo · 2023-07-04T09:07:40Z

jiushibushuo
Jul 4, 2023

整篇文章的基点是第一句话，但是第一句就不对，学东西看书比看视频强的多

1 reply

picklefan Jul 9, 2023
Author

？你能不能看看你在说什么。什么是dns泄露你不会去谷歌？真觉得全局就不泄露了？全局对国内而言算不算泄露？你跟楼上真的师出同门，拜把子吧。

picklefan · 2023-07-09T18:57:21Z

picklefan
Jul 9, 2023
Author

DNS leak WIKI
不想看视频，看看百科总行吧。再不行你回家翻翻书看看书上怎么写的。我实在懒得解释。不要看到第一行就以为全部给服务端查询就不泄露了，那你告诉我，全部给服务端查，你相对于国内算不算泄露？不要看点英文帖子就觉得自己很牛逼了，人家用英文的人根本不需要分流，你也不需要？说到底最后还是分流。

1 reply

jiushibushuo Jul 10, 2023

蠢货就是蠢货！拿个smartdns大搞套娃的你自信哪里来的？泄露的前提是先要有个VPN！

话题是鱼子酱要不要配法国面包，你和我说三文鱼不错，你tmd连鱼子酱都没有，谁和你谈三文鱼了？

picklefan · 2023-07-09T19:13:28Z

picklefan
Jul 9, 2023
Author

这么简单的东西我相信该懂的都懂，确实没必要发出来讨论

1 reply

jiushibushuo Jul 10, 2023

按照油管不良林的说法和我的理解，导致 DNS 泄漏的原因是查询域名时使用的 IP 与实际访问网站的 IP 区域差距太大。具体原理请谷歌或者看不良林的视频。

没闲工夫看一群油管主的视频，不知道你的理解/转述的对不对，如果真如你说，你和不良林，都是蠢货

picklefan · 2023-07-12T22:40:44Z

picklefan
Jul 12, 2023
Author

哦，你说这句话啊，那确实跟wiki不一样，我们又要兼顾国内网络又要连外网，跟老外用VPN保护隐私是有区别的，他们泄漏指的泄露本地，我们不仅要解决本地泄漏还要解决远端泄漏，这个说法没问题，差不多得了。比喻打得不错啊，语文很好吧~~虽然我只看了开头~~

…

On Mon, 10 Jul 2023, 10:36 jiushibushuo, ***@***.***> wrote: 按照油管不良林的说法和我的理解，导致 DNS 泄漏的原因是查询域名时使用的 IP 与实际访问网站的 IP 区域差距太大。具体原理请谷歌或者看不良林的视频。没闲工夫看一群油管主的视频，不知道你的理解/转述的对不对，如果真如你说，你和不良林，都是蠢货 — Reply to this email directly, view it on GitHub <#1983 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIKEELZ7T67LCSJ4M6UOW63XPNTCFANCNFSM6AAAAAAXHZJDSQ> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

0 replies

picklefan · 2023-07-12T22:42:48Z

picklefan
Jul 12, 2023
Author

讨论区嘛就是图个乐，我看还是open 吧

0 replies

zshwain2022 · 2024-07-23T02:07:44Z

zshwain2022
Jul 23, 2024

配置透明代理，全局模式，在其后方通过软路由分流。DNS不就不会泄露了。
https://github.com/user-attachments/assets/fc0d5c28-7dfa-4f33-bf37-f972d783f244)

0 replies

ZqinKing · 2024-07-23T05:41:16Z

ZqinKing
Jul 23, 2024

？？？DNS 泄漏的原因是查询域名时使用的 IP 与实际访问网站的 IP 区域差距太大。这句话有问题，DNS泄漏是递归导致的，再不济按F12或者弄个ADG看看泄漏测试的时候会出来哪些域名就知道怎么回事了。
当然防泄漏的的核心目标是保持DNS查询出口和查询到的目标再进行访问的出口尽可能的一致。这点没问题。
全局模式不会泄漏这个点也是没问题的。DNS请求和访问都走代理的情况下，从DNS的角度就是不泄露的。

0 replies

zshwain2022 · 2024-07-23T10:23:57Z

zshwain2022
Jul 23, 2024

对。就是这样。我为了更方便有效做分流就是这么构建的。 ZqinKing ***@***.***> 于 2024年7月23日周二 13:41写道：

…

？？？DNS 泄漏的原因是查询域名时使用的 IP 与实际访问网站的 IP 区域差距太大。这句话有问题，DNS泄漏是递归导致的，再不济按F12或者弄个ADG看看泄漏测试的时候会出来哪些域名就知道怎么回事了。当然防泄漏的的核心目标是保持DNS查询出口和查询到的目标再进行访问的出口尽可能的一致。这点没问题。全局模式不会泄漏这个点也是没问题的。DNS请求和访问都走代理的情况下，从DNS的角度就是不泄露的。 — Reply to this email directly, view it on GitHub <#1983 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZZ7PCDMGK5NQRHYM5OPEODZNXUJBAVCNFSM6AAAAABLJM7TKCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJSGIYTIMQ> . You are receiving this because you commented.Message ID: ***@***.***>

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

使用本地双层 DNS 过滤（Xray+smartDNS）降低 DNS 泄漏概率 #1983

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 11 comments 5 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

使用本地双层 DNS 过滤（Xray+smartDNS）降低 DNS 泄漏概率 #1983

结论：只要你分流，DNS泄露就是可以被检测的，对观察者来说露没露取决于他的观测手段，你只能降低被检测到的概率。

以下方法仅能降低一定概率，并不能避免泄露，若有表述为解决泄露的，请脑动替换为降低概率，我懒得改了。要是你理解分流必然能被检测出泄露那么你不需要看了。

该教程只讲解软路由透明代理环境下的解决方案（其他环境可以看个思路）

什么是DNS泄漏？

ROUTING 策略及对应的 DNS 处理方法

ROUTING 策略为白名单 proxy

实际上只要规则不重复就可以保证 dns 和 routing 的执行结果一致，比如你只使用 geosite:cn 。而添加了 domian:tiktok.com 之后由于 tiktok.com 存在于 geosite:cn 和 domian:tiktok.com ，会导致 dns 和 routing 执行结果不一致，具体下面有讲。

ROUTING 策略为 geosite/ip:cn 直连， 其他代理

引入 smartDNS （本来是用mosDNS 的，但是实在是太菜了，不会用）

Xray 配置

smartDNS配置（文档写得好，可以看文档自己配置）

Replies: 11 comments · 5 replies

picklefan Apr 24, 2023 Author

picklefan Jun 16, 2023 Author

picklefan Jul 9, 2023 Author

picklefan Jul 9, 2023 Author

picklefan Jul 9, 2023 Author

picklefan Jul 12, 2023 Author

picklefan Jul 12, 2023 Author

ROUTING 策略为 `geosite/ip:cn` 直连，其他代理

Replies: 11 comments 5 replies

picklefan Apr 24, 2023
Author

picklefan Jun 16, 2023
Author

picklefan Jul 9, 2023
Author

picklefan
Jul 9, 2023
Author

picklefan
Jul 9, 2023
Author

picklefan
Jul 12, 2023
Author

picklefan
Jul 12, 2023
Author