XDNS finalmask: apply sockopt to outgoing sockets for resolvers.

[26X23]

Policy-based routing with XDNS was broken in v26.4.13. Since then XDNS creates new sockets for resolvers and doesn't apply sockopt (and mark). Also sendThrough isn't used.

There is no need to create new sockets for every resolver. One preconfigured raw net.PacketConn may be used for all resolvers.

[Fangliding]

这样肯定不行 太丑了

[Fangliding]

#5872 从一开始就是AI slop想法自己打破封装 在finalmask里乱搞就算了别霍霍别的包

[RPRX]

可以接受应用 sockopt 但不能改这么多文件

[26X23]

Another way to partially fix is to use the raw net.PacketConn parameter rather than creating a new socket when there is only one resolver and there is no BindAddress (more correct would be to specify many addresses on the transport level and wrap them all in the finalmask, similar to how multiple ports are defined on the inbound level and then used in the dokodemo-door's portMap).
Yet another way is to copy predefined set of sockopts from raw net.PacketConn to resolverConns.
Or perhaps if we pass the list of internet.Controllers plus another one controller capturing SocketConfig to the WrapPacketConnClient there will be no import cycle.
Do you think this would be better than modifying so many files?

[Fangliding]

而且udp本来就可以对着设置好的packet conn writeto readfrom 不知道那玩意为什么还得自己单开连接

[26X23]

@Fangliding please review the new version of this PR (it's better to view without whitespace changes). Only 2 files changed now. New sockets for resolvers are not created anymore.

[RPRX]

@LjhAUMEM XDNS 目前只支持 UDP，我觉得是可以先改成 WriteTo 而不是创建一堆新 sockets，你看下这个 PR 可以合并不

[LjhAUMEM]

@LjhAUMEM XDNS 目前只支持 UDP，我觉得是可以先改成 WriteTo 而不是创建一堆新 sockets

开新 socket 不是你说的吗 #5872 (comment)

你看下这个 PR 可以合并不

完全不能，现在非常反感 ai 人，标题说的应用 socketopt 现在又只有改回单 conn 的修改

[RPRX]

那我确实说过，但现在有没应用 sockopt 这个问题。。。这个好修不，你改一下开个 PR 吧

[Fangliding]

说实话不好动 单socket反而简单点

[LjhAUMEM]

想了想改回单 conn 后就没有应用 sockopt 的问题了，不过改回单 conn 可能也不通过，ipv4 也 as16 不会出问题吗

那我确实说过，但现在有没应用 sockopt 这个问题。。。这个好修不，你改一下开个 PR 吧

只是改到单 conn 吧，那我来开个吧，到时候再加 co-authored，审完的精力自己早都写好了

[Fangliding]

ipv4 也 as16 不会出问题吗

As16 对ipv4可以用 一个很经典的坑 返回一个 ipv4 mapped ipv6 在标准库里很多地方都视为是一样的 但是也导致了很多麻烦 比如在需要的时候区分不出真的 ipv4 和 mapped ipv4 以及一些标准库函数返回哪种 ip 还在左右脑互搏

[26X23]

只是改到单 conn 吧

Yes. I switched back to a single PacketConn.

ipv4 也 as16 不会出问题吗

normalizeAddrPort is used only to compare the address of the received packet with the address of the resolver from the configuration. This normalized address isn't used for sending or anything else. So I don't think it will cause any problems. Without normalization addresses were sometimes incomparable. One was [::ffff.1.2.3.4]:53, and the other was 1.2.3.4:53

[LjhAUMEM]

@26X23 用我那一版吧，你现在这个除了改回单 conn 还相当于把单个 resolver 的 domain 和 ip 绑定了，然后还没改完，writeto 和 sendloop 那里还是乱序的

[RPRX]

但是 u1s1 单 conn 只能暂时解决问题，这以后支持个 example.com+https:// 咋整

[Fangliding]

那就不叫udp mask了 跟我之前吐槽的那样实质性变成第二层transport

[RPRX]

这 udp 的意思是适用于 udp 而不是一定还是以 udp 的形式发出，不然你让 XICMP 咋办

某种程度上来说它确实是又一层 transport，除了第二层还有负一层呢，以后要加个 pre

[26X23]

@LjhAUMEM I tested your PR (8bd1c92), it seems to work.

还相当于把单个 resolver 的 domain 和 ip 绑定了

I compare the pair (domain, IP-address) to match current behavior. Because one IP-address could be used with multiple domains (e.g.: t1.xdns.com+udp://1.1.1.1:53, t2.xdns.com+udp://1.1.1.1:53, t3.xdns.com+udp://8.8.8.8:53). In your PR domain isn't used to increment resolverSend, therefore first domain (t1.xdns.com) will be selected more frequently than second (t2.xdns.com) in the condition if c.resolverSend[c.resolverAddrs[c.resolverIdx].String()].Load() < curSend { break }.

[LjhAUMEM]

I compare the pair (domain, IP-address) to match current behavior. Because one IP-address could be used with multiple domains (e.g.: t1.xdns.com+udp://1.1.1.1:53, t2.xdns.com+udp://1.1.1.1:53, t3.xdns.com+udp://8.8.8.8:53). In your PR domain isn't used to increment resolverSend, therefore first domain (t1.xdns.com) will be selected more frequently than second (t2.xdns.com) in the condition if c.resolverSend[c.resolverAddrs[c.resolverIdx].String()].Load() < curSend { break }.

因为服务端会回空响应，实际上你那种也保证不了严格意义上的平均，只能保证大概，你可以打印 readfrom 的 addr 看看，基本上平均

[LjhAUMEM]

不过保证平均也不是健康检查的职责，这个简陋的健康检查主要是筛查出在相同发送次数下"死亡"的dns，都不死的话才会受服务器空包影响

[RPRX]

@LjhAUMEM 这个 PR 可以合并吗，我觉得还是多 sockets 更好

[RPRX]

。。。我看了下这个 PR 的代码，也是改成单 conn 了啊，这。。。

[RPRX]

还以为 @26X23 后面把这个 PR 改成了改动了更少文件的多 conn，打算先合了 @LjhAUMEM 那一版，毕竟 XDNS 是他写的

有空时你们再研究多 conn #5982 (comment) ，感觉最近思考的事情、说过的话太多，大脑的上下文窗口被撑满了，有点缺失

[LjhAUMEM]

毕竟 XDNS 是他写的

也欢迎其他人来修改，但不要是这种不痛不痒的或者在header里搞个科学计算器，如果是新记录传输我也很乐意帮忙审

但是 u1s1 单 conn 只能暂时解决问题，这以后支持个 example.com+https:// 咋整

配置文件没变可以随时加回来，但 https 应该也啥必要，会改记录也是提供商那里改，和提供商建立加密隧道有点多此一举

[RPRX]

@LjhAUMEM GFW 可能会拦截明文 TXT 查询

[LjhAUMEM]

那再看吧，关于 xdns 我的 todo 是

• 重构
• 添加 512 mode

[RPRX]

@LjhAUMEM 512 mode 是啥

[LjhAUMEM]

正常 dns udp 报文应该在 512 内，现在使用了 dns 扩展达到了 1280