-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
上游 TCP/DoT 服务器的 限流/限速 问题 #189
Comments
经过用dns2tcp测试上游tcp://223.5.5.5,同样的dns请求量没有出现dns查询timeout的问题。在当下国内各种公共dns普遍限速的环境下,chinadns-ng确实这方面有改进的空间。 |
这个配置信息需要附加到 upstream 的 url 上,因为允许不同的 upstream 具有不同的限额配置。 因此需要扩展 upstream 的 url 格式,如下(加空格是为了方便阅读,实际格式中不允许有空格):
UPDATE: udp、tcp、tls 会话默认配置都改为 count=10 && life=10。 |
老大,如果是仅用作dns转发的情况下如何设置呢?如这样的使用方式: |
仅用作转发 DNS 程序也一样的,没有特别之处。
我建议保持默认配置,因为根据先前 UDP 的经验(很久之前就是 count=10 && life=20 了),这个配置是安全的,兼顾了性能(不会频繁创建 udp socket、TCP/TLS 连接)和实际网络情况(避免触发上游 DNS 对单个连接/端口的限流、限速)。 |
希望DOT增加支持纯域名加端口的方式。 |
如果是纯域名的dns地址,还得添加bootstrap-dns服务器设置,否则连dns本身的域名都解析不了,这工作量估计有点大了。 |
明白了,太复杂了。那就现在这样吧。用的私有dns服务器,ip地址有时候会变动。 |
久等了,这周末或下周应该会更新此功能。
应该是 ssl session resume 导致的,见后面的更新。 |
各种平台都有这个问题。X86 ARM64,可能不一定是LTO问题。 |
我自己编译了一个ARM64不带LTO版本的,查询几次后也一样报Upstream.zig:551 TCP.on_error failed: received alert fatal error |
查询几次?意思是短时间内就能重现吗?我好像没遇到这种情况,也是aarch64。 构建命令行是什么,发来看看。 另外,走代理了吗?国内dot的还是国外的dot服务器? |
我自建的是在国外服务器,直连过去,我在国外查询也会出现,应该不是干扰问题。 是的,可以精确重现,十几次就会不行。 |
你这个看起来像是被gfw阻断了/干扰了,直连境外不走代理。毕竟DoT流量特征挺明显的。 |
我用境外服务器访问也一样的。 今天换了别的客户端是正常的。 |
难不成是ssl session恢复的问题?默认给启用了session恢复 |
怎么disable?我再编译一个看看。 |
没有build option可以控制,待会我切个测试分支,关闭ssl session恢复功能。你再测测 |
好的。 |
https://github.com/zfl9/chinadns-ng/tree/no-ssl-session-resume 这个分支。记得先 作为对照,建议编译该分支的两个版本,一个 lto,一个 no-lto。 |
可以了,没报错了。lto,no-lto都没问题了。 |
可能是 wolfssl 的 session 恢复 BUG。。先不管了,去除这个特性。 |
实测:阿里的 DoT 在南方某省份,“限流”很严重。测试了电信和移动,都是这样。 这里说的“限流”是指连接服务器失败,目前发现有以下两种表现: $ # 表现形式1:
$ # 若在 timeout 时间内可以 retry 成功,则 chinadns-ng 可以应对
$ dig +tls @223.5.5.5 taobao.com +retry=0 +timeout=3
;; Connection to 223.5.5.5#853(223.5.5.5) for taobao.com failed: connection refused.
$ # 表现形式2:
$ # 注意,dig 没有任何输出
$ # 这种故意等 2 秒的恶意行为无法应对,因为故意拉大了 retry 间隔,很容易触发 timeout
$ time dig +tls @223.5.5.5 taobao.com +retry=0 +timeout=3
dig +tls @223.5.5.5 taobao.com +retry=0 +timeout=3 0.00s user 0.01s system 0% cpu 2.074 total
$ # 表现形式2:
$ # 还是上面这个环境,在 chinadns-ng 中测试 (tls://223.6.6.6)
$ # 可以看到 dig 没输出是因为 ssl 握手时,alidns 故意等了 2 秒,然后发送一个 close 信号
$ # 而且 chinadns-ng 尝试了两次 connect(ssl 握手),都是这样,每次都是故意卡你 2 秒。
2024-09-06 15:16:05 I [server.zig:335 QueryLog.query] query(id:20781, tag:chn, qtype:1, 'taobao.com') from 127.0.0.1#36541
2024-09-06 15:16:05 I [server.zig:404 QueryLog.forward] forward query(qid:7, from:udp, 'taobao.com') to china group
2024-09-06 15:16:05 I [Upstream.zig:1114 Group.send] forward query(qid:7, from:udp) to upstream tls://223.6.6.6
2024-09-06 15:16:07 W [Upstream.zig:789 TCP.on_error] connect(tls://223.6.6.6) failed: peer sent close notify alert
2024-09-06 15:16:09 W [Upstream.zig:789 TCP.on_error] connect(tls://223.6.6.6) failed: peer sent close notify alert
2024-09-06 15:16:10 W [server.zig:121 Query.on_timeout] query(qid:7, id:20781, tag:chn) from udp://127.0.0.1#36541 [timeout] 腾讯的 DoT 目前正常(tls://1.12.12.12、tls://120.53.53.53),虽然解析耗时稍微高一些,但不像阿里这般变态。 另外,阿里的 tcp://223.5.5.5、tcp://223.6.6.6 (纯 TCP 查询)却又正常,不存在 DoT 那样的拒绝连接问题。 |
我这边在windows下用telnet测试阿里的223.5.5.5的853端口直接不通,只有阿里的ipv6地址的853端口才通 |
我在passwall添加直连dns dot支持时,在dot列表中阿里的服务器只放了ipv6地址,因为我不确定223.5.5.5是否真的支持tls,另外国内的dot服务器太少了,目前我只知道腾讯、360和阿里有。 |
对于阿里 DoT 的这种变态限制,chinadns-ng 实际上无能为力。 奇怪的是,不同地区这个现象还不同(根据收集到的反馈),Ta那边阿里DoT没有这种情况。。。 |
自建吧,这些免费的都要开始收钱了。没办法。 |
国内的这些 “公共” DoT/DoH 基本要废了。 |
这么变态的限制,他们开放服务干嘛?只为了代表它有吗? |
收费呀,都出了付费版。 |
连dns都要付费,还不如用isp的算数 |
感觉目前也就这么几个选项能用了(国内 DNS):
|
tcp目前我找到的国内公共dns只有两家,一个是阿里:223.5.5.5、223.6.6.6,还有就是字节跳动:180.184.1.1、180.184.2.2;阿里的tcp也有限速,而字节跳动的目前暂时还没有限速;国内除了udp以外,其他类型的dns真的少得可怜。 |
见 2024.09.08 版本。 |
先关了,有反馈再 reopen。 |
udp 目前应该没有(就算有,也是比较难触发的),自己换成 223.5.5.5 试试呗,可以再加上 119.29.29.29,备用。 |
用字节跳动的,经过测试目前没有限速,地址我上面有发出来。 |
#183 (comment)
#183 (comment)
#185 (comment)
根据收集的情况看,似乎 腾讯、阿里的 TCP DNS、DoT DNS 存在比较严重的限速,需要研究一个解决方案。
根据 #185 的反馈,似乎长连接(pipeline 查询)更容易受到限流的影响,考虑增加一个选项,对单个 TCP/TLS 连接增加一个配额,例如配置为 10,则表示单个连接最多服务 10 次 DNS 查询,避免在单个连接上执行过多查询。根据日志看,被限速时,上游服务器似乎不会立即主动关闭连接,所以看起来像连接假死了,导致 chinadns-ng 在一段时间内一直在等待上游 DNS 的 reply。
The text was updated successfully, but these errors were encountered: