当前Fake DNS的配置方式非常不合理（附建议）

[bhoppi]

Fake DNS的功能非常好，虽然我没有使用透明代理，但这个功能对tun2socks加速明显。但是，当下Fake DNS的配置方式非常不合理，造成配置时非常地烧脑而且不直观。具体地有如下几个方面问题：

1. 现在fakedns的解析是在DNS Server配置项里。众所周知，DNS Server主要的作用点是三个：基于IP的路由，DNS出站，Freedom出站的UseIP。然后文档又告诉我，基于IP的路由和Freedom出站不会使用Fake DNS这项功能。要知道以往在DNS Server里的配置项是对上述三个模块都起作用，现在却有2/3的情况被忽略掉，总感觉怪怪的。所以感觉应该把Fake DNS的启用放在DNS出站那里更合适。
2. 我个人的猜测，把Fake DNS放在DNS Server的配置项里是为了复用DNS分流的功能。但其实这样反而造成了两个更大的问题：一是，fakedns的选项中只有domains有用，其他选项如port、expectIPs等等统统没有意义；二是，为了保持Fake DNS的高优先级，别的DNS Server里domains有什么，fakedns的domains也得有什么。黑名单也是，哪个域名需要对Fake DNS拉黑，就需要在所有其他DNS Server的domains里加上这个域名。这个非常繁琐，而且真的不合理。
3. 最后是一个小问题，嗅探那里嗅探的不是fakedns，而是fakeip。这个没什么影响，只是稍微有点不直观。

综上述，我个人建议对Fake DNS的配置项调整如下：

1. 将启用Fake DNS解析的开关从DNS Server移到DNS出站的settings里，比如加一项 "fakedns": true|false，另外FakeDnsObject的配置也可以从最外层移到这里，减少该功能的配置项分散。
2. 要对Fake DNS启用黑白名单，可以基于路由规则来做。例如，创建两个DNS出站，一个启用fakedns，一个不启用。然后路由规则里针对不同域名分发到不同的DNS出站，这个大家都会，不细说了。这样比在DNS Server那里分流更灵活，而且无需复制domains这种操作了。
3. sniffing那里的fakedns改成fakeip，并且建议去掉metadataOnly这个选项，实际嗅探方式从destOverride的配置项自行推断出。

[bhoppi]

这样修改之后，DNS相关的逻辑更清楚：
DNS服务器还是那个真正的DNS分流查询模块，基于IP的路由、Freedom出站UseIP都会默认调用它。
Fake DNS是另一个虚拟DNS模块，这两个模块之间相互独立，且不共享缓存。
DNS出站用于拦截和转发 DNS 查询，可以根据实际场景选择转发到真实或虚拟DNS。

[kslr]

不是太明白，现在 fakedns 不就是一个单独的模块吗，路由该怎么走和以前都是一样的

[bhoppi]

现在的配置格式给人的感觉就是：它不是一个单独的模块，而是DNS Server里的一个特殊实现，而且这个特殊实现在基于IP的路由和Freedom出站调用时会被忽略，而且它的分流规则也需要特殊处理（把其他Server的domains全部复制一遍）。想想这个逻辑是否挺让人迷惑的。
所以我的建议的核心就是，不是在DNS的servers里添加fakedns，改为在DNS出站那里添加"fakedns": true。这样，对Fake DNS的域名过滤，不再由DNS分流分成，而是由路由规则代替。这样一切逻辑都变得清晰，配置也变得简单。

[bhoppi]

如果我还没有解释清楚的话，那我这么说：现在Fake DNS的弯弯绕绕，全是因为DNS出站与DNS模块绑定造成的，导致DNS出站调用Fake DNS时，需要
DNS出站->DNS模块->Fake DNS
这样一条路径，非常复杂。解决办法就是要把DNS出站与DNS模块解绑：默认情况下DNS出站会将数据交予DNS模块，但如果开启"fakedns": true的情况下则是直接交给FakeDNS模块处理。DNS模块和FakeDNS模块之间相互独立，不要有任何纠缠。
不知道我这么说清楚没有？

[yuhan6665]

核心是你说的 2，如何实现 FakeDNS 分流（黑白名单）的问题，一开始我也觉得放在路由里面清楚。#406 (comment)
后来我再仔细看发现了问题，因为路由是根据一个包的 目标 地址分流的。以一个 DNS 包来说，就是 8.8.8.8。这明显不是你想达到的。如果在路由选项里加一项 DNS domain 反而更容易误导，所以我的结论是在 DNS 模块分流是比较科学的。

确实，现在 DNS 模块的 domains 不支持正则和其他配置，这个修好以后会好很多。

[bhoppi]

这么一说我明白了，确实之前没有仔细考虑过路由模块的限制。这样的话，现在的配置方式虽然略显奇怪，却也是唯一合理的方式了。多谢回答！

[Ciacconas]

然后文档又告诉我，基于IP的路由和Freedom出站不会使用Fake DNS这项功能。

请问一下这一条在文档的哪里，我找了好一会也没找到，如果真的是这样的话，那还挺重要的。

[bhoppi]

我也找了一下文档，确实没有提到。这句话是写在4.35.1版本的发布日志里的。 https://github.com/v2fly/v2ray-core/releases/tag/v4.35.1

[Ciacconas]

我也找了一下文档，确实没有提到。这句话是写在4.35.1版本的发布日志里的。 https://github.com/v2fly/v2ray-core/releases/tag/v4.35.1

但其实仔细想想确实基于IP的路由，和Freedom出站UseIP这两项也确实不应该用fakedns。但是来自Freedom出站UseIP这两项需要dns分流的时候就需要在fakedns之外再写分流机制，确实有点烧脑。

[xiaokangwang]

Currently, there is only one set of DNS rules that applies everywhere in the V2Ray instance, and this is not enough, since DNS is not only used in routing, but also in resolving destination address, and serve DNS request. The current difficulty in configuring DNS is because DNS for a different purpose needs to share a single rule.

I would like to purpose a general solution, a new Setting object knows as Subsidiary DNS Object. You can specify a set of DNS servers configures(defined in the same format as DNS Object) that addressed by a name. In the freedom outbound, DNS outbound, routing, and sockopt of transport settings for every individual outbound, you can specify a Subsidiary DNS Object to be used, instead of the primary one or system resolver. This idea comes from Policy Routing. https://blog.scottlowe.org/2013/05/29/a-quick-introduction-to-linux-policy-routing/ https://osric.com/chris/accidental-developer/2019/03/linux-policy-based-routing/ .

Request for comment while the work for this haven't begin yet.

https://github.com/v2fly/v2ray-core/projects/1#card-60711425

[xiaokangwang]

Good idea, two comments I have:

* Is it possible for the dns object to reference each other? For instance I may want to match domain for fakedns and then fallback to normal dns configs

* Can we do something to prevent infinite loop on Android? Two scenarios off the top of my head. One is the initial DNS to resolve vps address. Second is DOHL.

object to reference each other would be possible, for example with a subsidiarydns://proxiedDNS. But I rather not to commit to do that right now, since it would take additional logic and can create a loop that requires special logic to prevent.

Prevent infinite loop on Android requires you to protect the DNS lookup connection, which is currently very difficult for ordinary client developer to do. By assigning a subsidiarydns object for every individual outbound's transportation -> socksopt settings, V2Ray will do this automatically for you, if if you overrides the system dialer, necessary support functions will be available to the client developer to resolve DNS with V2Ray's internal DNS solver.

[CalmLong]

像这样? 支持连接复用吗

{
  "protocol": "freedom",
  "settings": {
    "userLevel": 0
  },
  "streamSettings": {
    "sockopt": {
      "dns": {
        "address": "dns.google",
        "ip": "8.8.8.8"
      }
    }
  },
  "tag": "direct"
}

[xiaokangwang]

{
"protocol": "freedom",
"settings": {
"userLevel": 0
},
"streamSettings": {
"sockopt": {
"dns": "directout"
}
},
"tag": "direct"
}
在设置的根部：

{
"dns":{default dns settings},
"subsidiarydns":{
         "directout":{direct out dns settings}
}

为了支持连接复用以及其他的一些考虑，要先声明一个subsidiarydns， 然后其他的地方再引用那个subsidiarydns。

[CalmLong]

挺好的

emmm.... 有个疑问就是为什么不增强下原有 dns，然后把 tag 放到 sockopt 里面。这样顶层配置又 +1

[xiaokangwang]

这个subsidiarydns的实现思路就是现有的dns套娃。增强现有的话需要给DNS很多地方加配置tag的选项，然后未来新加DNS选项的话又要费尽加tag。如果不想加顶级配置的话，可以按照dns的类型进行处理，如果是Object就是原来的模式，如果是数组，就生成subsidiarydns， 然后首个配置是默认的（类似inbounds，outbounds）。