能否优化下dns查询的分组机制，防止ddos。

hapood commented 4 months ago

当网络状况突然变差时，可能会出现某些APP或者机器疯狂请求DDNS的情况。导致chinadns-ng持续报错too many pending requests，干扰了其他应用的DNS请求。

能否对同一域名的DNS请求做一个单独LIST，而不是把所有的DNS请求放入同一个LIST。

zfl9 commented 4 months ago

能提供下当时的日志吗？我需要从日志分析，是什么情况导致你说的这个错误。

hapood commented 4 months ago

能提供下当时的日志吗？我需要从日志分析，是什么情况导致你说的这个错误。

chinadns.log 这是完整的日志，可以看到很多too many pending requests

zfl9 commented 4 months ago

    456 [server.zig:129 QueryCtx.List.add] too many pending requests: 65536
   1126 [server.zig:391 on_query] dns.check_query(fd:6) failed: invalid query msg
   6646 [Upstream.zig:396 TCP.push_qmsg] too many pending queries: 1000
      4 [Upstream.zig:551 TCP.on_error] recv(tcp://8.8.8.8) failed: (104) Connection reset by peer

简单统计了一下日志，我感觉这个与 #180 是类似的问题，也许可以一并讨论。

如果可以复现，建议开 verbose log，这样就能看到 too many pending requests 之前的日志，得知查询者的 ip:port，查询的域名。

这个看起来确实很像 DDoS 攻击（我猜是某个程序的 Bug，一直在死循环解析某些域名，毕竟内网应该不应该存在 DDoS 攻击），短时间内 chinadns-ng 收到了巨量的 dns query，因为 qctx_list 容量是有限的（65535），所以可能导致正常请求无法得到处理。

invalid query msg 这个错误我估计也是上述 Bug程序触发的，具体见 #180。

zfl9 commented 4 months ago

能否对同一域名的DNS请求做一个单独LIST，而不是把所有的DNS请求放入同一个LIST。

问题没有这么简单，这种类似“DDoS”的攻击实际上很难防御，且听我道来。

为什么 qctx_list 有容量限制，最多只能持有 65536 个未完成的 dns 查询。

首先需要介绍一些 DNS 知识：

在单个 TCP/UDP 会话中，允许处理多个 DNS 查询（或者叫 DNS 事务）。
一个 TCP 会话其实就是指一个 TCP 连接；而对于 UDP，虽然 UDP 没有“连接”，但我们仍然可以根据五元组来唯一标识一个 UDP 会话，所谓五元组就是 {proto, src.ip, src.port, dst.ip, dst.port}，只要两个 UDP 数据包的五元组信息相同，我们就认为这两数据包属于同一个 UDP 会话（想象成一个 TCP 连接）。
要在单个 “TCP/UDP会话” 中同时处理 “多个DNS查询”，就需要一种机制来区分不同的“DNS数据包”属于哪个“DNS查询”，这个机制就是 dns msg-id (uint16)，因此在单个 TCP/UDP 会话中，最多可同时处理 2^16=65536 个DNS查询。

chinadns-ng 与每个 upstream 都是单个“持久的” TCP/UDP 会话，因此 qctx_list 最多可容纳 65536 个未完成的查询，如果 qctx_list 满了，那么新来的 query 就无法得到处理，因为没有 msg-id 可用了。无论你怎么“优化”qctx_list的结构，都受到这个 msg-id 的限制，所以你提议的方法没什么效果。

有人会问，是否可以换个思路：让 chinadns-ng 对于收到的每个 “DNS查询” 都使用一个 “单独的TCP/UDP会话” 与 upstream 进行通信，这样就可以绕过 dns msg-id 的限制了。

这样确实绕过了 msg-id 的限制，但陷入了另一个限制：“五元组”的限制，或者说可同时打开的 socket 数的限制。

proto 自然是同一个，即 TCP or UDP
对于每个 upstream 来说，dst.ip 和 dst.port 也都是同一个值，即 upstream 的 ip 和 port
那就只剩下 src.ip 和 src.port 了，src.ip 大部分情况下只有 1 个（除非你有多个 IP），那就只剩下 src.port 了，port 也是 uint16，所以理论上也最多有 65536 个 port 供你分配，但实际上更少，因为低于 1024 的端口是保留的，而且默认情况下，用于动态分配的端口范围是 32768–61000，远没有6万多个，更何况这种实现方案会消耗大量系统 socket 资源，这也是为什么 chinadns-ng 不采用此方法的原因。

zfl9 commented 4 months ago

所以我的想法是，找出这个有问题的程序/主机，看看查询的是什么域名，为什么它会疯狂发DNS查询。从这个方向入手。

zfl9 / chinadns-ng

能否优化下dns查询的分组机制，防止ddos。 #179

为什么 qctx_list 有容量限制，最多只能持有 65536 个未完成的 dns 查询。