fixed XTLS#104 and apply routing for non-local DoH requests

[badO1a5A90]

1. fixed 关于远程doH的问题 #104

因为 'Dispatched connection will be closed (interrupted) after each request'.
所以原来的远程DOH方式在高并发时,第一个DNS请求返回后连接关闭,后续使用同一个连接的其他请求失败.
出现类似 'app/dns: failed to retrieve response > Post "https://1.0.0.1/dns-query": io: read/write on closed pipe' 的错误.

这个commit针对 non-local DOH(即远程DOH)修正了这个错误,.
其余模式(如local DOH)行为和以前一致.

2. apply routing for non-local DoH requests

在很久前 v2ray 的一次 commit 中,将 non-local DoH 修改成直接使用第一个outbound, 而不经过路由.
本意似乎是为了防止某些不当配置时,陷入DNS解析的死循环,但这是很不合理的.
这样的设计会导致远程DOH请求发往的都是第一个 outbound 进行解析,得到的未必是最合适IP, 甚至可能并未发往代理 (比如第一个outbound为freedom时)
举例来说,原来的模式下. 比如你配置了DNS服务器为:
"https://1.1.1.1/dns-query"
路由中设定了

      {
        "type": "field",
        "ip": [
          "1.1.1.1"
        ],
        "outboundTag": "proxy"
      },

这意味着你期望使用1.1.1.1的DOH,并且通过代理远程解析.
但事实上路由规则并不生效. 此时如果的第一个outbound是freedom, 这次解析实际上就变成了直接向1.1.1.1发起连接并请求解析(行为与本地DOH模式相同了),而不是远程DOH解析了.

这个commit使远程DoH 请求和其他DNS(如最常用UDP模式)请求一样, 目标DNS服务器会经过路由模块分流,并且选择你期望的outbound.
即比如你配置了DNS服务器为:
"https://dns.google/dns-query" 或者 "https://1.1.1.1/dns-query"
可以和其他模式的DNS服务器一样, 同样通过配置类似

      {
        "type": "field",
        "domain": [
          "dns.google"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "1.1.1.1"
        ],
        "outboundTag": "proxy"
      },

进行路由分流.

其余模式(如local DOH 仍然是直接发起连接)行为和以前一致.

---

如欲避免不当配置导致的死循环比如自己企图解析自己(commit针对这种情况会有error log).
最方便的模式是 hosts 中直接加入 DNS 服务器域名所对应的 IP.
比如:

  "dns": {
    "hosts": {
      "dns.google": "8.8.8.8"
    },
    "servers": [
      {
        "address": "https://dns.google/dns-query"
      },
   "https+local://1.1.1.1/dns-query",
   "8.8.8.8"
   ]
}

解释:
hosts的解析是最优先的.因此,
假设极端情况下,你只写了一个DNS服务器,且这个DNS服务器是远程DOH模式的,并且还是用了域名(你确定要要这么写么)...
也就是, 你只写了一个 https://dns.google/dns-query 作为DNS服务器.
这种情况下, 需要查DNS的时候,就要先解析 dns.google ,但是你只有dns.google 一个服务器, 就自己查询自己套娃了.
最简单的处理方式是 hosts 里面直接写 "dns.google": "8.8.8.8" , 或者你也可以增加其他DNS服务器, 那么虽然他最初向自己查询失败, 但是失败后会从其他服务器查询得到 dns.google 的IP.后续的解析就进入正常节奏了.

[RPRX]

第一项修改，内置的 DNS 有缓存吗

[badO1a5A90]

第一项修改，内置的 DNS 有缓存吗

有,和以前行为一致.即命中缓存的话不会实际发起查询而是直接使用缓存数据.

[RPRX]

那这项修改应该不会有明显影响，话说以前的 Mux 指的是 v1.mux.cool 吗

[badO1a5A90]

那这项修改应该不会有明显影响，话说以前的 Mux 指的是 v1.mux.cool 吗

注释掉的吗? 是的.

[RPRX]

似乎可以顺便解释之前 splice 那里断言遇到的情况

[badO1a5A90]

似乎可以顺便解释之前 splice 那里断言遇到的情况

记不清当时测试的具体场景了, 但似乎可以解释

[RPRX]

我觉得这样修改后实际上应该会改善体验？因为其它并行的 DoH 请求不会因为等待一段时间却得不到结果而又要去参与新的 mux

[badO1a5A90]

我觉得这样修改后实际上应该会改善体验？因为其它并行的 DoH 请求不会因为等待一段时间却得不到结果而又要去参与新的 mux

是的,会改善.
因为原来的模式下.失败的请求会在4秒后才向下一个DNS服务器发起请求.

[RPRX]

以前是不是又要去参与下一个 Mux，堪忧。。。

[badO1a5A90]

以前是不是又要去参与下一个 Mux，堪忧。。。

这似乎不会, 应该是去查询下一个配置的DNS服务器.

[RPRX]

那如果内置 DNS 只设置了一个远程 DoH 呢。。。

[badO1a5A90]

那如果内置 DNS 只设置了一个远程 DoH 呢。。。

那就意味着这次查询失败了啊,除了正常返回的第一个,后面都是查询失败没结果的

[RPRX]

感谢 PR，我们先这样修改吧，v1.3.x 时再尝试优化