这是一个创建于 654 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近我在访问一个论坛：www.ai2moe.org 的时候发现访问异常，排查后发现是 DNS 解析错误。
<>我平常用的 223.5.5.5 和 119.29.29.29 的 UDP DNS ，跑在 openclash 上。 然后我用把 openclash 关掉，在软路由上用 dig 和 nslookup 进行测试，测试结果如下：- 运营商 DNS 在 nslookup 和 dig 下都正常
- dig 下，223.5.5.5 正常
- nslookup 下，114DNS 正常而 223.5.5.5 异常（重点！！）
详细结果如下四图： 223.5.5.5 测试 dig 正常而 nslookup 异常： https://img.chkaja.com/b98e8e559e1bfa8f.png
114DNS 测试 nslookup 正常： https://img.chkaja.com/ae9cab6d9b411af7.png
114DNS 测试 dig 正常： https://img.chkaja.com/9a0b19830aae75b9.png
运营商 dig 正常： https://img.chkaja.com/44e034a3964b1f20.png
运营商 DNS nslookup 正常： https://img.chkaja.com/42ac2f962d94a18e.png
并且根据此网站结果可得 223.5.5.5 解析是没有污染的： https://dig.ping.pe/www.ai2moe.org:A:223.5.5.5
而且运营商 DNS 解析正常说明这个问题也不是 DNS 劫持，不然直接用运营商 DNS 也无法访问才对。
然后我又测试了下换成阿里的 DoH 就又可以正常解析了。。玄学问题了。
求教坛友们这可能是出在什么问题上？实在排查不出来了。
第 1 条附言 2024-03-17 11:03:23 +08:00
首先感谢 @Tianao @jinqzzz 提供的排错思路。
先放结论：分析下来结论是 223.5.5.5 没问题，我电脑自己不管是用运营商 DNS 还是 223.5.5.5 访问网站都没问题，所以问题只能出在过了 openclash 内核以后就寄了。分析下来这可能更像是 openclash 内核的问题，我去反馈下这个问题。
1. 开始的时候怀疑是 223.5.5.5 由于 UDP 查询返回的 A 记录过多，超过了 512 字节，于是 223.5.5.5 用 TCP 再进行查询，在这过程中 DNS 服务器不能正常响应（返回了 TCP RST 包），从而导致用 223.5.5.5 查询 nslookup 失败。
114DNS 和运营商 DNS 自己丢弃了部分 A 记录让返回的结果小于 512 字节，所以 nslookup 没问题。
而 223.5.5.5 dig 查询成功的原因是 dig 采用 EDNS0 ，允许 4096 字节长的结果返回，所以 dig @223.5.5.5 www.ai2moe.org 的结果正常。
2. 后来又经过测试在关闭 openclash 的情况下在 openwrt 上用命令 dig +tcp @223.5.5.5 -p 53 www.ai2moe.org ，返回结果正常，说明 openwrt 上是可以对 223.5.5.5 进行 TCP 的 UDP 查询，得出结论：223.5.5.5 的 TCP 查询是没问题的。
3. 再测试 PC 的 DNS 手动设置为 223.5.5.5 后测试访问 www.ai2moe.org ，结果竟然可以正常访问。而打开 openclash （ openclash 只设置一个 223.5.5.5 的 Nameserver ）就无法正常访问 www.ai2moe.org 。
先放结论：分析下来结论是 223.5.5.5 没问题，我电脑自己不管是用运营商 DNS 还是 223.5.5.5 访问网站都没问题，所以问题只能出在过了 openclash 内核以后就寄了。分析下来这可能更像是 openclash 内核的问题，我去反馈下这个问题。
1. 开始的时候怀疑是 223.5.5.5 由于 UDP 查询返回的 A 记录过多，超过了 512 字节，于是 223.5.5.5 用 TCP 再进行查询，在这过程中 DNS 服务器不能正常响应（返回了 TCP RST 包），从而导致用 223.5.5.5 查询 nslookup 失败。
114DNS 和运营商 DNS 自己丢弃了部分 A 记录让返回的结果小于 512 字节，所以 nslookup 没问题。
而 223.5.5.5 dig 查询成功的原因是 dig 采用 EDNS0 ，允许 4096 字节长的结果返回，所以 dig @223.5.5.5 www.ai2moe.org 的结果正常。
2. 后来又经过测试在关闭 openclash 的情况下在 openwrt 上用命令 dig +tcp @223.5.5.5 -p 53 www.ai2moe.org ，返回结果正常，说明 openwrt 上是可以对 223.5.5.5 进行 TCP 的 UDP 查询，得出结论：223.5.5.5 的 TCP 查询是没问题的。
3. 再测试 PC 的 DNS 手动设置为 223.5.5.5 后测试访问 www.ai2moe.org ，结果竟然可以正常访问。而打开 openclash （ openclash 只设置一个 223.5.5.5 的 Nameserver ）就无法正常访问 www.ai2moe.org 。
第 2 条附言 2024-03-19 10:26:13 +08:00
更新：已向 OpenClash 仓库维护者 V 大反馈此问题： https://github.com/vernesong/OpenClash/issues/3811
V 大表示是内核的问题，于是我又向 meta 内核发了 issue ，目前等待回复中： https://github.com/MetaCubeX/mihomo/issues/1117
V 大表示是内核的问题，于是我又向 meta 内核发了 issue ，目前等待回复中： https://github.com/MetaCubeX/mihomo/issues/1117
第 3 条附言 2024-03-24 14:09:06 +08:00
3/24 更新：
在 meta 内核 alpha-d56a439 已经修复此问题。
https://github.com/MetaCubeX/mihomo/issues/1117#issuecomment-2016511149
在 meta 内核 alpha-d56a439 已经修复此问题。
https://github.com/MetaCubeX/mihomo/issues/1117#issuecomment-2016511149
 | 1 Tianao 2024-03-16 17:23:50 +08:00  12 权威解析给这个 CNAME 配的 A 记录太多了，dig 在请求的时候携带了 UDP payload size (比如我的 macOS 的默认是 4096), 所以 223.5.5.5 会直接使用 UDP 返回这个八百多字节的递归解析结果； nslookup 默认没有在请求里携带 UDP payload size 信息，223.5.5.5 默认按 512 对待，返回了 Truncated flag 置位，让客户端去用 TCP 再请求一次。 至于楼主的 nslookup 为什么没有成功通过 TCP 解析，就要检查 nslookup 的实现、DNS 客户端的配置和 TCP 的联通性了（比如 telnet 223.5.5.5 53 ）。我的 macOS 的 nslookup 是会在这样输出之后正确显示最终的 A 记录的： nslookup www.ai2moe.org 223.5.5.5 ;; Truncated, retrying in TCP mode. 至于为什么阿里的 DoH 没问题，因为 DoH 和使用 53 端口的 DNS 是两个完全不同的协议，不存在这个默认最大 512 字节的限制。 至于为什么 119.29.29.29 和 114.114.114.114 和运营商 DNS 使用相同的 nslookup 和相同的 DNS 协议也没问题，因为它们直接无视了来自 DNS 客户端的 DNS 请求中携带的 UDP payload size, 偷偷把超长递归解析结果裁剪到不超过 512 字节（在本例中，是通过随机丢弃 A 记录的方式）通过 UDP 直接返回了。 |
 | 2 CharonVIII OP @Tianao 大佬太厉害了，分析非常详细，感觉给我开辟了新大陆！ 我刚才测试了下 telnet 223.5.5.5 53 ，显示空白页面，应该代表对 223.5.5.5 的 53 端口的 TCP 连接是通畅的。 然而我用电脑又试了下 nslookup www.ai2moe.org 223.5.5.5 ，结果显示： nslookup www.ai2moe.org 223.5.5.5 服务器: public1.alidns.com Address: 223.5.5.5 DNS request timedout. timeout was 2 seconds. *** 请求 public1.alidns.com 超时 还是感觉原因不明啊。 其实这种事情也真是我上了这么多年网第一次遇到，太异常了。照理说 A 记录太多的网站肯定不止这一家... |
| 3 Tianao 2024-03-16 22:29:12 +08:00 1 @CharonVIII #2 我测试下来，是 Windows 上的 nslookup 实现在通过 UDP 收到 Truncated 置位的应答、转而使用 TCP 并完成 TCP 的 3-way 握手后，会紧接着（也就是在这个 TCP 连接的第 4 个包）发送一个带有 PSH 置位的、仅有 2 bytes 的 TCP payload 的 TCP segment, 我不知道这个 2-byte 载荷的意义是什么（但猜测是用作一个什么出于性能或可用性目的的什么前导？），然后紧接着就收到了来自 223.5.5.5 的 TCP RST (我也不知道 223.5.5.5 为什么要 reset, 但是我猜测是 223.5.5.5 收到了这个不明所以的 TCP 分段，出于节省资源开销/防攻击的目的主动 reset 掉了这个 TCP 连接)，然而按照 Windows nslookup 的预期（这一「预期」我使用了其他使用 Windows nslookup 可以正常解析的 DNS 服务器进行了验证），这第 5 个包本应是来自服务端的正常 ACK, 然后 nslookup 再紧接着发送可以和第 4 个包进行 TCP segment reassemble 从而组成一个完整 DNS 请求的 TCP 分段，但是此时 TCP 连接已经被 223.5.5.5 给 reset 掉了。 目前的判断：Windows 的 nslookup 实现和 223.5.5.5 的某些策略性表现在 TCP 解析时存在兼容性问题。 目前的建议：在 Windows 上，在 PowerShell 中使用 Resolve-DnsName 能够获得比 nslookup 更接近 Windows DNS 客户端真实表现的测试结果。换言之，在 Windows 上，仅是 nslookup 失败不代表浏览器等真实用户访问行为调用的 DNS 解析也会失败。 「照理说 A 记录太多的网站肯定不止这一家...」 对于一般 web 服务的 GSLB, 国内一般都是地理+运营商分区解析，每个分区最终的 A/AAAA 记录真的远没这么多；对于国际化服务，虽然会使用 anycast, 但是 ADNS 会控制每次返回给 recursive DNS 的权威结果数量，也不会一次性返回好几十个 anycast 地址的 A 记录。 |
| 4 CharonVIII OP @Tianao 感谢分析，我这边还没测试过直接在 windows 上设置 DNS 为 223.5.5.5 能否正常访问网站（估计不行），但是我测试过由跑在 openwrt 上的 openclash 来代为用 223.5.5.5 解析 DNS 的话是解析结果错误的。 看你的原因分析感觉非常有道理，确实如果是这个原因的话就说得通了。那么最好的办法要么在阿里、腾讯 DNS 之外再加个 114DNS 或者运营商 DNS ，要么就用阿里和腾讯的加密 DNS 。 我现在的解决方案就是 openclash 用阿里和腾讯的 DoT 来规避 UDP DNS 的 payload size limit 的问题（当然用 DoH 也行），目前情绪稳定。 |
 | 5 filtrate 2024-03-17 08:31:18 +08:00 关于为什么没有自动 fallback 到 tcp ，我指出两点可能的存在的线索，仅供楼主参考： 首先，看楼主是在 openwrt 上边测试，openclash 可能劫持了你发向 wan 的 dns 请求 其次，clash dns 服务器是不支持 tcp mode 的 |
| 6 filtrate 2024-03-17 08:33:41 +08:00 1 dig 命令可以测试 dns 服务器是否支持 tcp ，比如 dig +tcp @127.0.0.1 -p 1053 www.baidu.com |
 | 7 465456 2024-03-17 09:35:26 +08:00 同时使用运营商 DNS ，和 DNS-over-QUIC 就没问题 |
| 8 CharonVIII OP @jinqzzz 我测试都是关掉 openclash 再测试的。 刚才测试了下关闭 openclash 的情况下在 openwrt 上用命令 dig +tcp @223.5.5.5 -p 53 www.ai2moe.org ，返回结果正常，说明 openwrt 上是可以进行 TCP 的 UDP 查询的，得出结论：223.5.5.5 的 TCP 查询是没问题的。 我又把 PC 的 DNS 手动设置为 223.5.5.5 后测试访问 www.ai2moe.org ，结果竟然可以正常访问。而打开 openclash （ openclash 只设置一个 223.5.5.5 的 Nameserver ）就无法正常访问 www.ai2moe.org 。 所以就是说 223.5.5.5 没问题，我电脑自己不管是用运营商 DNS 还是 223.5.5.5 访问网站都没问题，问题就出在过了 openclash 内核以后就寄了。。分析下来这可能更像是 openclash 内核的问题，我去反馈下看看。 谢谢各位大佬们的思路！ |
 | 9 fredcc 2024-03-17 20:13:11 +08:00 不知道 op 用的哪个版本的 clash 内核，也不知道 dns 分流配置怎么写的，测试 meta alpha-g44d8a14 解析正常  |
| 10 CharonVIII OP |
| 11 465456 2024-03-19 12:49:00 +08:00 @CharonVIII 为啥一定要用 udp ，用 DoH/DoT 不香吗？ |
 | 12 johnjiang85 2024-04-10 19:30:42 +08:00 这个还需要看 dns 服务端对 tcp 请求的兼容性问题，不是所有版本的 windows 的 nslookup 都有这个，只是部分版本的 nslookup 有这个问题。 当客户端发起 tcp 请求的时候，tcp 的 dns 请求是由 2 个字节的长度包+实际的 dns 请求组成的，部分较旧版本的 nslookup 会把两个部分分开发送，而 dig 和较新版本的 nslookup 会将两部分一起发送。 当 dns 服务端对 tcp 的 dns 请求数据不进行分段接收数据的支持处理的话，比如只支持一次性收到 2 字节的长度包，和完整的后续 dns 请求包，那么这些老版本的 nslookup 分 2 次发送的数据包，在 dns 服务端收到的数据和前 2 字节的数据包长度不匹配，就会校验失败，然后关闭 tcp 连接。 如果需要兼容此类客户端，需要在 dns 服务端进行修改，支持 tcp dns 请求的时候，没有一次性收到完整数据的场景，即需要自己对客户端的 tcp 连接和已收到部分数据做额外的管理，会复杂一些。 |
| 13 johnjiang85 2024-04-10 19:32:49 +08:00 可以使用老版本 nslookup 或 nc 来模拟分段发送 dns 请求 |
| 14 johnjiang85 2024-04-10 19:42:38 +08:00 { echo -n -e "\x00\x2b";sleep 1; echo -n -e "\x69\x6f\x01\x20\x00\x01\x00\x00\x00\x00\x00\x01\x0a\x6c\x6f\x76\x65\x6c\x79\x70\x69\x6e\x67\x03\x63\x6f\x6d\x00\x00\x01\x00\x01\x00\x00\x29\x10\x00\x00\x00\x00\x00\x00\x00"; } | nc 1.12.0.1 53 nc 模拟在同一个 tcp 连接中分段发送 DNS 请求的示例，此处是向 1.12.0.1 发送 tcp dns 请求域名 lovelyping.com 的 A 记录 |
Select Language
