UDP流量会在本地发起DNS请求？

[Minhao-Geng]

我所有的ip-rules都加了no-resolve，按理来说走节点的流量不会有本地dns请求，dns解析应该都是节点服务器完成。

只有cn的流量是本地解析。tcp这块倒是没问题，所有墙外流量都是代理解析dns，我昨天开了respect rules然后nameserver只写

• https://1.1.1.1/dns-query
• https://8.8.8.8/dns-query。
  direct nameserver 用阿里和腾讯公共dns，所以国内流量都是国内这俩dns解析。

问题出在我看log时发现cloudflare和google这两dns走了代理，说明一定有dns解析从本地发出，这个log后一条就是个udp流量，说明前面那个1.1.1.1的代理是为了获取这个udp流量的real ip。 这udp请求一定会在本地发起dns吗？我的兜底rule是走代理，所以不存在有不匹配的域名走直连。

我的配置如下·：

dns:
  default-nameserver:
  - https://223.6.6.6/dns-query
  - tls://223.5.5.5
  direct-nameserver:
  - https://223.5.5.5/dns-query
  - tls://223.6.6.6
  - https://doh.pub/dns-query
  - dot.pub
  direct-nameserver-follow-policy: false
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
  - '*.lan'
  - '*.local'
  - '*.arpa'
  - time.*.com
  - ntp.*.com
  - time.*.com
  - +.market.xiaomi.com
  - localhost.ptlogin2.qq.com
  - '*.msftncsi.com'
  - www.msftconnecttest.com
  fake-ip-filter-mode: blacklist
  fake-ip-range: 198.18.0.1/16
  fallback-filter:
    domain: []
    geoip: false
    geoip-code: CN
    ipcidr: []
  ipv6: false
  listen: :53
  nameserver:
  - https://1.1.1.1/dns-query
  - https://8.8.8.8/dns-query
  prefer-h3: true
  proxy-server-nameserver:
  - https://223.5.5.5/dns-query
  - tls://223.6.6.6
  - https://doh.pub/dns-query
  - dot.pub
  respect-rules: true
  use-hosts: false
  use-system-hosts: true

[mengdegege]

[mengdegege]

找了几个singbox客户端对比了一下，发现这个确实是mihomo特有的现象。其他的基本是按规则，如果代理域名启用了fake ip就是下发fake ip，有的日志疑似出站前是解析了一次，但依然拿到的是fake ip。而且不管是sing 还是 mihomo的日志显示和连接列表，看起来最终连接的目标其实都是域名。如果这样的话那这一次跳过fake ip的解析是bug吗？还是有什么特别的用意呢。希望有懂的人能赐教一下。虽然不是很在乎DNS泄露，按照现有的DNS 策略也可以避免所谓的泄露。
就单纯比较想知道，这个解析是不是必须的。
而且，如果要为了去迎合这个解析行为，专门去配置复杂的 本来可以依靠fakeip就全部省去的复杂策略，实测下来是对网络流畅性有影响的，还挺明显。现在为了体验只能直接拒绝udp(感觉不完整了😰)。
这是nekobox上的日志


下面这个是meta的

而如果拦截udp，则不会有这种解析行为，反复测试下来基本上很明确这种解析动作是udp连接触发的。

[sMetase]

应该是这样的情况，翻到 Mihomo 内核的更新说明：

端午节内核更新
https://github.com/MetaCubeX/mihomo/releases/tag/v1.19.10
https://github.com/MetaCubeX/ClashMetaForAndroid/releases/tag/v2.11.13
整体udp部分的dns解析已延迟到连接发起阶段，在rule匹配过程中仅匹配没有配置no-resolve的ip规则时会触发。
对于direct和wireguard出站，会遵循和tcp部分相同的逻辑，即当direct-nameserver（或wireguard配置的dns）存在时丢弃rule匹配过程中的解析结果对域名发起重解析。该重解析逻辑仅对fakeip生效。
对于reject和dns出站，不再需要解析。
对于其他出站依然会在udp连接发起时进行解析，目前不会将域名直接发送到远程服务器上。
此外该版本tun入站的udp部分内存占用也已优化。

[mengdegege]

应该是这样的情况，翻到 Mihomo 内核的更新说明：

端午节内核更新
https://github.com/MetaCubeX/mihomo/releases/tag/v1.19.10
https://github.com/MetaCubeX/ClashMetaForAndroid/releases/tag/v2.11.13
整体udp部分的dns解析已延迟到连接发起阶段，在rule匹配过程中仅匹配没有配置no-resolve的ip规则时会触发。
对于direct和wireguard出站，会遵循和tcp部分相同的逻辑，即当direct-nameserver（或wireguard配置的dns）存在时丢弃rule匹配过程中的解析结果对域名发起重解析。该重解析逻辑仅对fakeip生效。
对于reject和dns出站，不再需要解析。
对于其他出站依然会在udp连接发起时进行解析，目前不会将域名直接发送到远程服务器上。
此外该版本tun入站的udp部分内存占用也已优化。

那就应该是了，只是对比下来同样的ss出站节点，sb好像不会有这种解析，也不知道是日志没有体现出来，还是确实是实现上面有差异。感觉这种UDP流量如果说技术上可以实现发送域名的话，直接传递域名是不是会更优一些？而且，因为这种解析的需要，会使得域名解析策略变得很复杂。

[nasaboy]

[mengdegege]

tcp没有发现,如果有这种情况, 可以检查一下在这个命中的规则及以上规则里有没有IP类型规则且没有加no-resolve的.

[nasaboy]

确实是我自己搞错了，没启用fake-ip模式

[mengdegege]

最近找了singbox内核的软件做了个测试，虽然没有完全理解底层原理，但在sb内核的软件上观察到一个现象，由于sb内核不像mihomo把dns阶段和出站阶段分开，所以观察到一个现象，如果在sb内核中启用代理域名采用fake-ip会导致所有quic请求全部失败，直接没有了UDP的连接，只有关闭fakeIP，用真实解析才能获得UDP的正常通信，因此大致可以判断，sb系内核也并不是可以让UDP连接保持发送域名给远端服务器进行解析，而是在特定场景直接抛弃了UDP。从这一层面来说，mihomo的逻辑设计似乎更加完善更合理，明确区分解析阶段和出站阶段不同的解析需求。