search

zfl9 / chinadns-ng

chinadns 重构增强版，支持域名分流、ipset/nftset、UDP/TCP/DoT
GNU Affero General Public License v3.0
1.14k stars 188 forks source link

使用 chinadns-ng 替代 dnsmasq 时，需要注意的事项 #165

Closed windmsn closed 7 months ago

windmsn commented 7 months ago

省流：请直接拉到最后。

原始comment 症状： 第一天[4月13日]：使用chinadns-ng作为主服务，开启cache，监听53端口，代替dnsmasq。客户端设备表现为无网络，dig没问题，手机就是连不上网。（设备主要是使用国内APP。抖音微信等日常的） 第二天[4月14日-15日]：为了保障家里设置能正常上网，chinadns-ng监听5354端口，关闭chinadns-ng的cache，开启dnsmasq的cache并作为主dns服务，chinadns-ng作为dnamasq的上游，**客户端备设使用正常两天** 第三天，同上 第四天[4月16日]：因为摆脱不了chinadns-ng的高性能，又把chinadns-ng作为了主服务。设置跟4月13日一样代替dnsmasq，客户端设备表现为无网络，无法连网，还是能dig通 第五天[4月17日]：又改回了**第二天[4月14日-15日]**的设置。**客户端备设使用正常** 第六天[4月18日]：又把chinadns-ng作为了主服务，但此次关闭了自带的cache。**客户端备设使用正常** 设备连不上网，表现为：chinadns-ng重启后，能短暂的使用一会。大概过了一个小时，就开始陆陆续续地出现网络无法连接的问题，重启chinadns-ng后，又正常一段时间。 曾经以为，resolver不支持edns或者tc等问题而提出过修改https://github.com/zfl9/chinadns-ng/issues/160#issuecomment-2051751354 也曾经以为是返回的reply过大https://github.com/zfl9/chinadns-ng/issues/160#issuecomment-2051795097 在4月16日测试的时候，我发现上游的223.5.5.5和119.29.29.29返回reply并不带有AUTHORITY和ADDITIONAL，返回的reply肯定不会超过512，于是我把国内的dns设为了`china-dns 223.5.5.5,udp://119.29.29.29`，但情况一样，一个小时左右客户端设置就开始出了无法连接到网络。 目前情况就是若想正常使用chinadns-ng作为主服务，就必须把它的cache给关了 配置如下 ``` bind-addr :: bind-port 53 china-dns 223.5.5.5,udp://119.29.29.29 trust-dns tcp://8.8.8.8 gfwlist-file /root/gfwlist.txt chnlist-file /root/chnlist.txt ipset-name4 cnip ipset-name6 chnroute6 cache 10000 default-tag chn add-taggfw-ip gfwlist,gfwlist6 ``` ![WX20240419-105023@2x](https://github.com/zfl9/chinadns-ng/assets/15327926/fac3506e-9357-40fb-b31b-115612236594) ![WX20240419-105044@2x](https://github.com/zfl9/chinadns-ng/assets/15327926/82ecd566-9931-432b-a308-ae31bef1ecb0) ![WX20240419-105149@2x](https://github.com/zfl9/chinadns-ng/assets/15327926/e9fbfd32-a7ae-4029-9027-66a764b04207) ![WX20240419-105157@2x](https://github.com/zfl9/chinadns-ng/assets/15327926/ddefe2a9-c1ca-4569-94f0-27d3668f1778) ![WX20240419-105210@2x](https://github.com/zfl9/chinadns-ng/assets/15327926/78f51892-0314-440f-99e4-34834e121ea0) ![WX20240419-105217@2x](https://github.com/zfl9/chinadns-ng/assets/15327926/d743ca7e-103b-4195-814c-0310fa7deafb) ![WechatIMG4113](https://github.com/zfl9/chinadns-ng/assets/15327926/7f677ac2-5623-425d-83de-6318e308c6b0)
windmsn commented 7 months ago

?

在描述问题，不小心点了comment，等会，，

zfl9 commented 7 months ago

看你配置，是gfwlist分流？

路由器上使用？mips吗

没网的时候，有去路由器上观察chinadns-ng什么状态没？还在运行？能否正常dig解析域名

zfl9 commented 7 months ago

目前情况就是若想正常使用chinadns-ng作为主服务，就必须把它的cache给关了

关了cache就正常？

windmsn commented 7 months ago

看你配置，是gfwlist分流？

是的。是gfwlist分流，之前以为是使用chinafirst，发现有很多国内的域名解析到国外了。所以就改了一下配置。不匹配gfwlist的都走china了。

路由器上使用？mips吗

是在路由器上使用，是x86的openwrt。

没网的时候，有去路由器上观察chinadns-ng什么状态没？还在运行？能否正常dig解析域名

没网的时候。chinadns-ng是正在运行的。局域网下的设置是能用dig解析域名的，但只局限于dig。其他客户端就表示没网络。

关了cache就正常？

是的。关了就正常。就慢一点。 目前只使用chinadns-ng，并关闭cache，使用一天正常，其他情况关闭chinadns-ng的cache的时候，都是前面套多了一个dnsmasq作为主服务，并启用缓存的

zfl9 commented 7 months ago

没网的时候。chinadns-ng是正在运行的。局域网下的设置是能用dig解析域名的，但只局限于dig。其他客户端就表示没网络。

就是说，出现“没网的时候”，在其他局域网机器上，可以用dig正常解析，但是常规app就是提示没网？

windmsn commented 7 months ago

没网的时候。chinadns-ng是正在运行的。局域网下的设置是能用dig解析域名的，但只局限于dig。其他客户端就表示没网络。

就是说，出现“没网的时候”，在其他局域网机器上，可以用dig正常解析，但是常规app就是提示没网？

是的。是的。但是我dig的都只是一些常规的域名。。例如什么www.qq.com www.baidu.com www.163.com等

zfl9 commented 7 months ago

在这种“没网”的情况下，是否试过使用curl、wget测试？能否访问 baidu、google、youtube 之类的（模拟正常解析dns）

windmsn commented 7 months ago

有没有测过在这种情况下，使用curl、wget测试？能否访问 baidu、google、youtube 之类的（模拟正常解析dns）

是有的。我常用wget。是可以解析的。也能直接wget到他们的index.html的。dns感觉运行是正常的。

zfl9 commented 7 months ago

你说的wget测试，在什么机器上进行？openwrt路由器上？还是其他局域网机器上？都ok吗？

windmsn commented 7 months ago

你说的wget测试，在什么机器上进行？openwrt路由器上？还是其他局域网机器上？都ok吗？

路由器上和局域网下都是ok的。局域网里有2台linux设备。

zfl9 commented 7 months ago

那就奇了怪了，出现你说的“无网络”症状时：

手机上获取的网关和dns都是指向这台openwrt路由器吗？

这个透明代理用的是什么插件？这里可能会有问题吗？

windmsn commented 7 months ago

那就奇了怪了，出现你说的“无网络”症状时：

  • 使用wget、dig可以正常解析dns、访问网站
  • 但是手机上就提示没网络，无法访问

手机上获取的网关和dns都是指向这台openwrt路由器吗？

这个透明代理用的是什么插件？这里可能会有问题吗？

手机上提示没网络。主要集中于高频app。（微信，抖音，头条等）

路由器上，是做了dns 53端口胁持的。所有局域网内设置的dns查询都是被REDIRECT到路由器的53端口的。

透明代理用的是ssrplus。但是国内流量。都是直连的。。而且大半个ssrplus我自己重写过了。iptables上我试过把ssrplus的规则删除。情况依旧。透明代理插件应该没问题。

现在主要的区别就是cache与非cache的区别。。。

zfl9 commented 7 months ago

手机没网的时候，能把那个时间段chinadns-ng日志发出来吗（开一下verbose日志）

zfl9 commented 7 months ago

我有与你类似的使用场景，也是透明代理，chinadns-ng作为唯一的dns服务器，但不是openwrt，而是在树莓派上。

开了缓存等功能，也在上面持续跑了快半个月了，最长持续运行时间（未重启）应该有5天左右，没有你说的问题。

需要一些更详细的信息，才能分析（主要是我没法重现）：

windmsn commented 7 months ago

我有与你类似的使用场景，也是透明代理，chinadns-ng作为唯一的dns服务器，但不是openwrt，而是在树莓派上。

开了缓存等功能，也在上面持续跑了快半个月了，最长持续运行时间（未重启）应该有5天左右，没有你说的问题。

需要一些更详细的信息，才能分析（主要是我没法重现）：

  • 出现“无网络”问题时的dns verbose log
  • 当时的进程运行情况，cpu占用，内存占用
  • dig测试、wget测试时的dns verbose log

稍等。我写个脚本捕获一下日志。

zfl9 commented 7 months ago

记得把cache开启。配置带上verbose行，启用详细日志

muziling commented 7 months ago

dhcp还需要dnamasq呢。是不是dhcp没了

windmsn commented 7 months ago

dhcp还需要dnamasq呢。是不是dhcp没了

不是的dnsmasq没关，只是监听端口改为了0,chinadns-ng监听53而已。

muziling commented 7 months ago

可以考虑用mosdns运行一段时间看看有没有问题。

windmsn commented 7 months ago

可以考虑用mosdns运行一段时间看看有没有问题。

那倒不必。只要前面再套上dnsmasq，打开缓存。关掉chinadns-ng的cache dnsmasq(监听53)->chinadns-ng(监听5354)->各种上游 这样是完全没问题的。

现在不想用dnsmasq去解析dns。。是因为chinadns-ng不出问题的时候是真的快。。

zfl9 commented 7 months ago

看了下 cache 的代码，发现有个地方可能会导致 与某些客户端不兼容。

不确定是否是这个问题导致。

但我觉得就算这个有影响，也不至于无网络，感觉问题根源不是这个。

windmsn commented 7 months ago

看了下 cache 的代码，发现有个地方可能会导致 与某些客户端不兼容。

  • NODATA 类型的响应（rcode=NOERROR && answer.n=0），我这边误删了 AUTHORITY 节的内容。按照 RFC 规范，这里要保留 SOA 记录的（位于 AUTHORITY 节）。

不确定是否是这个问题导致。

但是我直接dig @223.5.5.5 www.qq.com或者dig @119.29.29.29 www.qq.com的时候。返回的reply也不带有AUTHORITY 节的内容。

更何况，影响的是访问高频的域名。微信，抖音，腾讯视频，爱奇艺等这 APP。这些日常使用频率高的app，应该不会存在NODATA的吧。。

晚上9点的时候我添加了一个参数cache-nodata-ttl 0我不清楚会不会有些偶尔reply会返回空的情况。而缓存进去了。 目前观察中。

下午截了大概3小时的日志，出现无网络情况时。所有的dig，wget，cpu，内存，进程等都是正常的。 dns.tar.gz

zfl9 commented 7 months ago

下午又出现了“无网络”是吗？

我看下log先

windmsn commented 7 months ago

下午又出现了“无网络”是吗？

是的。大概出现在下午5点钟左右，我女放学回来玩手机的时候说，日志上的时间+8小时。

zfl9 commented 7 months ago

这个log的结束时间点是不是就是出故障的那段时间

zfl9 commented 7 months ago

看日志没啥问题。。。

windmsn commented 7 months ago

但我觉得就算这个有影响，也不至于无网络，感觉问题根源不是这个。

其实这个问题在上一个版本的时候就已经有，更早之前的不清楚。那时候还没用chinadns-ng替代dnsmasq。，当时我还跟你说过以为是tc的问题，也以为是edns返回的包超过512字节的问题，才做了第一版的cache调整。

这个log的结束时间点是不是就是出故障的那段时间

这个log的结束点。。。是被我女儿投诉上不了网后我又把dnsmasq加上去结束chinadns-ng缓存的时候的。 收到我女儿反馈的时候是5点左右。故障出现应该更早。。

看日志没啥问题。。。

日志是看不出问题，dig，wget等都是正常的。当时我让她试了一些其他app〉小红书等，也是能正常使用的。

zfl9 commented 7 months ago

日志是看不出问题，dig，wget等都是正常的。当时我让她试了一些其他app〉小红书等，也是能正常使用的。

是部分APP无网络，而不是所有都无网络？

那就更奇怪了。

zfl9 commented 7 months ago

你确定不是路由器哪里设置有问题吗，这看起来不像是DNS导致的。

windmsn commented 7 months ago

日志是看不出问题，dig，wget等都是正常的。当时我让她试了一些其他app〉小红书等，也是能正常使用的。

是部分APP无网络，而不是所有都无网络？

那就更奇怪了。

是的，最主要就是微信，因为用得多嘛。一小时看几十次微信。。是最容易发现的。昨天也试了。把缓存关了，就能正常使用的。所以今天一直在调整缓存的参数。

你确定不是路由器哪里设置有问题吗，这看起来不像是DNS导致的。

路由器设置应该没问题吧。。因为只要关了cache。。能正常使用。。

zfl9 commented 7 months ago

cache从理论上来说，如果会出问题，也是一开始就出问题了，而不是运行几个小时后出问题。毕竟程序都是死的。无论运行多久，cache的逻辑都是相同的。

cache只会影响2个方面：

按理来说要是这里会出问题，刚开始运行就会立马发现。所以我想不通。

zfl9 commented 7 months ago

我想起一个地方：未命中缓存时的响应内容 与 命中缓存时的响应内容 有一些不同：

我只能怀疑是这个不同 导致某些 resolver 产生奇怪行为。因为我思来想去，与dnsmasq做对比，唯一的区别就在这个地方。

有兴趣的话，我明天给你发个修改版，测试下

修改的内容：

无论是否启用缓存，都把additional节给删了（EDNS信息在这个节，有些dns服务器也会在这个节带上NS记录关联的A/AAAA记录），本质上都没啥作用，不如删了，这样无论是否启用缓存，response都是一样的，唯一的区别就是响应时间的快慢，这下总没有问题了吧。。。

移除这个信息不影响chinadns-ng对query的EDNS bufsize信息的读取，这两操作之间没有关联。也即是说，如果UDP查询端在OPT RR中声明了 bufsize 为 4096，那么chinadns-ng可以理解这个信息，只要response没超过这个size，就不会发送truncated response给查询方。

windmsn commented 7 months ago

cache从理论上来说，如果会出问题，也是一开始就出问题了，而不是运行几个小时后出问题。毕竟程序都是死的。无论运行多久，cache的逻辑都是相同的。

cache只会影响2个方面：

  • dns解析速度的快慢，这个很好理解。
  • 保存cache的reply msg时，对msg进行了裁剪，丢弃了authority/additional节，只留下了answer节，对于常规响应(answer节有内容，即非NODATA响应)，这样做是完全没问题的，dnsmasq也是一样的做法。而且这个修改只在add cache时进行一次，之后hit cache都只是简单的返回这个数据，无其他修改（除了TTL递减）。

按理来说要是这里会出问题，刚开始运行就会立马发现。所以我想不通。

我今天也扒了半天cache.zig，CacheMsg.zig，dns.zig的代码。。因为zig不太懂，平时主要肝java和python，所以看得有点吃力。 有些也只能猜。。 目前我有这几方面的猜想：

  • dns服务器返回数据时会不会有出错的情况（有这个猜想是因为运营商基本是把dns给劫持了）。概率不知道高不高，如果存在这种情况又把信息给缓存了，dnsmasq又是如何处理的。所以晚上添加了cache-nodata-ttl 0测试，有时候dig dnsmasq的时候，需要dig好几次才能Query time: 0 msec说明缓存命中。

  • 我观察了一下，下午的d.log缓存，大概1小时就add cache 就达到了10000条了。10000条里面有8000条的TTL是30-200，大概有1000条的TTL是400-600，对于高频的域名解析，TTL时间短的，应该是一个不断add cache的过程。这个过程会不会有问题，这主要是联想到高频访问题30-60分钟就会出故障而时间又刚好跟这个有交集。

修改的内容：

无论是否启用缓存，都把additional节给删了（EDNS信息在这个节，有些dns服务器也会在这个节带上NS记录关联的A/AAAA记> 录），本质上都没啥作用，不如删了，这样无论是否启用缓存，response都是一样的，唯一的区别就是响应时间的快慢，这下总没> 有问题了吧。。。

移除这个信息不影响chinadns-ng对query的EDNS bufsize信息的读取，这两操作之间没有关联。也即是说，如果UDP查询端在> OPT RR中声明了 bufsize 为 4096，那么chinadns-ng可以理解这个信息，只要response没超过这个size，就不会发送truncated > response给查询方。

这个可以有。明天有包测试打一个试试。还是一样两个架构

ChinaDNS-NG 2024.04.13 | target:x86_64-linux-musl | cpu:x86_64_v3 | mode:fast+lto
ChinaDNS-NG 2024.04.13 | target:mipsel-linux-musl | cpu:mips32r5 | mode:fast+lto

我今晚添加的cache-nodata-ttl 0明天也可以一同汇报

windmsn commented 7 months ago

我想起一个地方：未命中缓存时的响应内容 与 命中缓存时的响应内容 有一些不同：

  • 未命中缓存时的响应，带了EDNS信息给客户端（也就是OPT RR），当然前提是客户端发了EDNS信息过来
  • 命中缓存时的响应，因为add cache时被修剪了，所以只有answer节，没有EDNS那些信息

我只能怀疑是这个不同 导致某些 resolver 产生奇怪行为。因为我思来想去，与dnsmasq做对比，唯一的区别就在这个地方。

有兴趣的话，我明天给你发个修改版，测试下

修改的内容：

无论是否启用缓存，都把additional节给删了（EDNS信息在这个节，有些dns服务器也会在这个节带上NS记录关联的A/AAAA记录），本质上都没啥作用，不如删了，这样无论是否启用缓存，response都是一样的，唯一的区别就是响应时间的快慢，这下总没有问题了吧。。。

移除这个信息不影响chinadns-ng对query的EDNS bufsize信息的读取，这两操作之间没有关联。也即是说，如果UDP查询端在OPT RR中声明了 bufsize 为 4096，那么chinadns-ng可以理解这个信息，只要response没超过这个size，就不会发送truncated response给查询方。

我发现，dnsmasq，在缓存前缓存后是有不同的 不知道他是否为了兼容性？

缓存前

[root@ManTou:/root]#dig @127.0.0.1 -p53 www.qq.com

; <<>> DiG 9.9.9-P3 <<>> @127.0.0.1 -p53 www.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64538
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 13

;; QUESTION SECTION:
;www.qq.com.                    IN      A

;; ANSWER SECTION:
www.qq.com.             223     IN      CNAME   ins-r23tsuuf.ias.tencent-cloud.net.
ins-r23tsuuf.ias.tencent-cloud.net. 116 IN A    112.53.42.52
ins-r23tsuuf.ias.tencent-cloud.net. 116 IN A    112.53.42.114

;; AUTHORITY SECTION:
tencent-cloud.net.      137794  IN      NS      ns-open2.qq.com.
tencent-cloud.net.      137794  IN      NS      ns-open1.qq.com.
tencent-cloud.net.      137794  IN      NS      ns-open3.qq.com.

;; ADDITIONAL SECTION:
ns-open1.qq.com.        6605    IN      A       203.205.236.176
ns-open1.qq.com.        6605    IN      A       59.36.132.139
ns-open1.qq.com.        6605    IN      A       117.135.174.196
ns-open2.qq.com.        1931    IN      A       182.254.59.163
ns-open2.qq.com.        1931    IN      A       203.205.195.63
ns-open2.qq.com.        1931    IN      A       203.205.195.122
ns-open2.qq.com.        1931    IN      A       61.241.27.10
ns-open3.qq.com.        481     IN      A       101.227.161.202
ns-open3.qq.com.        481     IN      A       121.51.167.100
ns-open3.qq.com.        481     IN      A       140.207.180.51
ns-open3.qq.com.        481     IN      A       203.205.220.25
ns-open3.qq.com.        481     IN      A       218.68.91.163
ns-open2.qq.com.        2590    IN      AAAA    240e:e1:aa00:2001::3

;; Query time: 7 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Apr 20 09:47:49 CST 2024
;; MSG SIZE  rcvd: 397

缓存后：

[root@ManTou:/root]#dig @127.0.0.1 -p53 www.qq.com

; <<>> DiG 9.9.9-P3 <<>> @127.0.0.1 -p53 www.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32265
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.qq.com.                    IN      A

;; ANSWER SECTION:
www.qq.com.             210     IN      CNAME   ins-r23tsuuf.ias.tencent-cloud.net.
ins-r23tsuuf.ias.tencent-cloud.net. 103 IN A    112.53.42.114
ins-r23tsuuf.ias.tencent-cloud.net. 103 IN A    112.53.42.52

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Apr 20 09:48:02 CST 2024
;; MSG SIZE  rcvd: 119

仔细观察，当dig一些大厂的dns（223.5.5.5，119.29.29.29）时，他们所返回的，全是带有EDNS的opt以及去掉AUTHORITY SECTION和ADDITIONAL的reply。缓存的结果是与dnsmasq相似的。偶有不同的也只是bufsize大小不同：

[root@ManTou:/root]#dig @223.5.5.5 -p53 www.163.com

; <<>> DiG 9.9.9-P3 <<>> @223.5.5.5 -p53 www.163.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42994
;; flags: qr rd ra; QUERY: 1, ANSWER: 18, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1408
;; QUESTION SECTION:
;www.163.com.                   IN      A

;; ANSWER SECTION:
www.163.com.            29      IN      CNAME   www.163.com.163jiasu.com.
www.163.com.163jiasu.com. 29    IN      CNAME   www.163.com.w.kunluncan.com.
www.163.com.w.kunluncan.com. 29 IN      A       183.240.239.240
www.163.com.w.kunluncan.com. 29 IN      A       183.240.176.185
www.163.com.w.kunluncan.com. 29 IN      A       120.240.65.231
www.163.com.w.kunluncan.com. 29 IN      A       183.240.178.234
www.163.com.w.kunluncan.com. 29 IN      A       183.240.178.233
www.163.com.w.kunluncan.com. 29 IN      A       120.233.175.232
www.163.com.w.kunluncan.com. 29 IN      A       120.233.175.235
www.163.com.w.kunluncan.com. 29 IN      A       120.232.248.220
www.163.com.w.kunluncan.com. 29 IN      A       120.240.65.230
www.163.com.w.kunluncan.com. 29 IN      A       120.233.4.221
www.163.com.w.kunluncan.com. 29 IN      A       120.233.172.125
www.163.com.w.kunluncan.com. 29 IN      A       183.240.176.182
www.163.com.w.kunluncan.com. 29 IN      A       183.240.239.239
www.163.com.w.kunluncan.com. 29 IN      A       120.233.4.222
www.163.com.w.kunluncan.com. 29 IN      A       120.233.172.126
www.163.com.w.kunluncan.com. 29 IN      A       120.232.248.219

;; Query time: 17 msec
;; SERVER: 223.5.5.5#53(223.5.5.5)
;; WHEN: Sat Apr 20 10:08:08 CST 2024
;; MSG SIZE  rcvd: 369

[root@ManTou:/root]#dig @119.29.29.29 -p53 www.163.com

; <<>> DiG 9.9.9-P3 <<>> @119.29.29.29 -p53 www.163.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12800
;; flags: qr rd ra; QUERY: 1, ANSWER: 18, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.163.com.                   IN      A

;; ANSWER SECTION:
www.163.com.            239     IN      CNAME   www.163.com.163jiasu.com.
www.163.com.163jiasu.com. 539   IN      CNAME   www.163.com.w.kunluncan.com.
www.163.com.w.kunluncan.com. 45 IN      A       120.233.4.226
www.163.com.w.kunluncan.com. 45 IN      A       183.240.176.188
www.163.com.w.kunluncan.com. 45 IN      A       120.233.172.119
www.163.com.w.kunluncan.com. 45 IN      A       120.232.248.223
www.163.com.w.kunluncan.com. 45 IN      A       120.233.175.232
www.163.com.w.kunluncan.com. 45 IN      A       183.240.178.232
www.163.com.w.kunluncan.com. 45 IN      A       183.240.239.237
www.163.com.w.kunluncan.com. 45 IN      A       120.240.65.230
www.163.com.w.kunluncan.com. 45 IN      A       120.240.65.227
www.163.com.w.kunluncan.com. 45 IN      A       183.240.239.234
www.163.com.w.kunluncan.com. 45 IN      A       183.240.178.235
www.163.com.w.kunluncan.com. 45 IN      A       120.233.175.231
www.163.com.w.kunluncan.com. 45 IN      A       120.232.248.219
www.163.com.w.kunluncan.com. 45 IN      A       120.233.172.139
www.163.com.w.kunluncan.com. 45 IN      A       183.240.176.190
www.163.com.w.kunluncan.com. 45 IN      A       120.233.4.221

;; Query time: 17 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Sat Apr 20 10:08:26 CST 2024
;; MSG SIZE  rcvd: 369
zfl9 commented 7 months ago

bin.tgz

zfl9 commented 7 months ago

@windmsn 试试，参数不变（记得开启cache），替换上去

windmsn commented 7 months ago

@windmsn 试试，参数不变（记得开启cache），替换上去

这个版本是无论缓存与否。都保留AUTHORITY SECTION，砍掉了ADDITIONAL SECTION。

待测，

思考一下，为何dnsmasq，223.5.5.5，119.29.29.29，8.8.8.8等都需要加上EDNS的opt。。。

zfl9 commented 7 months ago

这个版本是无论缓存与否。都保留AUTHORITY SECTION，砍掉了ADDITIONAL SECTION。

是的。无论缓存与否，response都是一样的，只有响应快慢/TTL的区别。

zfl9 commented 7 months ago

为何dnsmasq，223.5.5.5，119.29.29.29，8.8.8.8等都需要加上EDNS的opt。。。

那是因为dig默认启用了EDNS，dig测试时，加上 +noedns 标志就明白了。

glibc/musl等libc没有启用edns，我之前观察过。

zfl9 commented 7 months ago

我发现，dnsmasq，在缓存前缓存后是有不同的 不知道他是否为了兼容性？

先不管这个吧，我相信让消息保持一致是有益的（无论是否启用缓存），应该能减少所谓的兼容性问题。

windmsn commented 7 months ago

@windmsn 试试，参数不变（记得开启cache），替换上去

已替换上去。。在测。观察一天。今天周六不上学。应该能体现结果

zfl9 commented 7 months ago

ok，有问题及时反馈，我这边方便跟进并尝试修复。

windmsn commented 7 months ago

为何dnsmasq，223.5.5.5，119.29.29.29，8.8.8.8等都需要加上EDNS的opt。。。

那是因为dig默认启用了EDNS，dig测试时，加上 +noedns 标志就明白了。

glibc/musl等libc没有启用edns，我之前观察过。

会不会有这么一种工况：

会不会有这种情况？

zfl9 commented 7 months ago

不会有兼容性问题，因为 EDNS 是向后兼容的（具体可以看看 rfc6891）。

比如：当一个支持 EDNS 的客户端（在 query 中携带了 EDNS 信息），查询一个传统服务端时，服务端因为不理解 EDNS 信息，所以返回的 response 不会有 EDNS 信息。

chinadns-ng 会理解客户端传来的 OPT RR（主要是读取其中的 udp bufsize，用于 reply 时的 truncate 逻辑），但不会在 response 中放入 EDNS 信息，目的是模拟传统服务端的行为。因为 chinadns-ng 本身不提供 EDNS 相关特性，自然没必要发送它。

所以，最新修改版（发你的）的行为完全符合 RFC 标准，肯定不会有兼容性问题。

windmsn commented 7 months ago

ok，有问题及时反馈，我这边方便跟进并尝试修复。

还是反映有问题。。。已经想不出是哪里有可能了。。 WX20240420-133314@2x

zfl9 commented 7 months ago

见鬼了？

完全相同的配置/dns/环境，只把cache关了(配置cache 0，其他一个都别修改)，然后重启chinadns-ng。再试

zfl9 commented 7 months ago

另外你没网络时怎么恢复的，操作是什么？单纯重启dns进程？还是重启路由器。还是重新设置iptables？

zfl9 commented 7 months ago

这回可真是有没有缓存都一样的response哦，如果开cache就会导致微信有问题，关闭cache就没问题，那我只能说见鬼了

我和其他人也没遇见你这种情况。。

ss-tproxy那边也没有类似的反馈

windmsn commented 7 months ago

另外你没网络时怎么恢复的，操作是什么？单纯重启dns进程？还是重启路由器。还是重新设置iptables？

恢复网络只需重启chinadns-ng即可。其他不需要操作。。

zfl9 commented 7 months ago

内核dmesg日志有没有？发来看看