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

[windmsn]

省流：请直接拉到最后。

原始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 ```       

[zfl9]

劫持dns的iptables发来看看

[zfl9]

完整chinadns配置发来看看

测试记得全程开verbose，方便分析

[windmsn]

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

内核也没报啥奇怪的。。 dmesg.log

劫持dns的iptables发来看看

iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 53 iptables -t nat -A PREROUTING -p tcp --dport 53 -j REDIRECT --to-ports 53

配置文件是刚修改了cache 0之前我是直接把cache给去掉的。。

bind-addr ::
bind-port 53
china-dns 223.5.5.5,2400:3200::1
trust-dns tcp://8.8.8.8
gfwlist-file /root/gfwlist.txt
chnlist-file /root/chnlist.txt
ipset-name4 cnip
ipset-name6 chnroute6
cache 0
cache-nodata-ttl 0
default-tag chn
add-taggfw-ip gfwlist,gfwlist6
no-ipv6 tag:gfw

verbose的话正在捕获。。需要点时间

[zfl9]

你这个config有几个无用配置：

#这个不需要，因为default-tag chn已经将所有未匹配list的域名tag归为了tag:chn
chnlist-file /root/chnlist.txt

# 这两个也没用，你是gfwlist模式，根本没有tag:none，用不上ip test
# ipset-name4 chip
# ipset-name6 chnroute6

[windmsn]

你这个config有几个无用配置：

#这个不需要，因为default-tag chn已经将所有未匹配list的域名tag归为了tag:chn
chnlist-file /root/chnlist.txt

# 这两个也没用，你是gfwlist模式，根本没有tag:none，用不上ip test
# ipset-name4 chip
# ipset-name6 chnroute6

这个。。因为一直在调整测试。参数。。还没整理。。应该没影响的。。。吧。。

[zfl9]

是的没啥影响。

[zfl9]

先等你的without cache测试结果。

[zfl9]

难道是这个zig hash表有问题？

我待会重写一个hashmap。

你先测试没缓存时是否ok

[windmsn]

难道是这个zig hash表有问题？

我待会重写一个hashmap。

你先测试没缓存时是否ok

恩，我先暂定观察6小时，因为昨天关了cache运行16小时没异常。

[zfl9]

看起来没问题？我改了下cache.zig，去掉zig的hashmap，待会你试试（开缓存）。

[zfl9]

bin.tgz

[windmsn]

看起来没问题？我改了下cache.zig，去掉zig的hashmap，待会你试试（开缓存）。

cache 0后暂时还未收到异常报告。。。 cache 0和直接注释#cache 10000是一样的么？

[zfl9]

ok，那可以确定是cache.zig的问题了，可能reply数据错位了。

不确定是zig的hashmap问题，还是我使用不当。

[zfl9]

cache 0和直接注释#cache 10000是一样的么？

一样，cache 选项默认值就是0。0就是不启用缓存。

[windmsn]

cache 0和直接注释#cache 10000是一样的么？

一样，cache 选项默认值就是0。0就是不启用缓存。

我先放上去开启缓存观察一下。。。

[windmsn]

@zfl9 还是不行。。不知道是啥问题了，先不弄了。。老母有大意见，。先在前面套个dnsmasq用着先。。

[zfl9]

那就不知道你这边啥问题了，我也无能为力。

因为我和其他人都是正常使用，没见你这种情况。

关了。。

[windmsn]

那就不知道你这边啥问题了，我也无能为力。

因为我和其他人都是正常使用，没见你这种情况。

关了。。

不知道跟我双拨有没有关系。。。。

我老母家是双拨电信千兆，。

我自己家是单拨移动千兆。。。

我自己那的单拨，好像问题不大。虽然也有偶发性的解析问题，但是没有老母家的严重。

[zfl9]

有可能是 LTO 优化的问题，待会给你构建一个不带 LTO 的版本，试试？

@windmsn

[windmsn]

有可能是 LTO 优化的问题，待会给你构建一个不带 LTO 的版本，试试？

@windmsn

可以有。。LTO是什么。。。目前关了cache。。套上了dnsmasq，，已经跑了一天多了。。很正常。。

[zfl9]

链接时优化，今天晚上我和另一个小伙伴测试 x86_64 版本的 chinadns-ng，发现有些问题。

不确定与你的错误是否有关系。

[windmsn]

链接时优化，今天晚上我和另一个小伙伴测试 x86_64 版本的 chinadns-ng，发现有些问题。

不确定与你的错误是否有关系。

哦对的。我老娘那是x86的。电信，双拨，经常反馈有问题。

我自己用的是mipsel，只出现了偶尔的半次打不开阿里云的连接。其他时间很正常。

[windmsn]

@zfl9 中午的时候换了不带LTO版本的。老娘反馈还是不行。反馈有问题的时候，套上dnsmasq也不行，后来要把chinadns-ng用回原来的4.13带LTO的才可以

目前正常使用的部署是用dnsmasq监听53端口并做缓存，chinadns-ng只做转发查询分流关闭cache。

先不管了。先这样用着。到时想到是什么问题再反馈。。。

[zfl9]

如果后面有空，记得补充细节，从整个issue来看，还是缺少一个整体的描述，特别是“问题”出现时：

• 整个局域网都“无网络”？还是只有给定的设备（全部手机？某些特定手机？）无网络？
• 如果是只有手机有问题，是部分“手机APP”显示无网络，还是全部“手机APP”显示无网络？
• 如果能拿到当时手机的“错误日志”，那就可以分析究竟是什么导致它“无网络”，而不是现在这样猜测。。
• 另外，根据你之前说的，出现“问题”时，其他设备可以正常使用dig、wget访问？是否有确认过当时的chinadns log有收到这些dig、wget的dns解析。
• 因为我是没办法重现，而且其他人也没办法重现，要找出问题的真正原因，只能靠你自己了。最最重要的一点时，尽量不要只看表面现象，光在那猜测没意义，解决不了问题。。必须结合日志来分析，而且最好看看出问题时的log，到底有什么异常之处。。不光是chinadns-ng的日志，最理想的情况是能够分析到当时手机APP（或系统）的日志，看看到底什么鬼情况。。。

还有个办法，如果可能，建议换个环境测试，先排除是不是被openwrt上的某些东西影响到了。

---

另外，建议多去了解 DNS 相关的细节知识（虽然我也不太抱有什么希望了），就先这样吧。。。

[windmsn]

如果后面有空，记得补充细节，从整个issue来看，还是缺少一个整体的描述，特别是“问题”出现时：

• 整个局域网都“无网络”？还是只有给定的设备（全部手机？某些特定手机？）无网络？
• 如果是只有手机有问题，是部分“手机APP”显示无网络，还是全部“手机APP”显示无网络？
• 如果能拿到当时手机的“错误日志”，那就可以分析究竟是什么导致它“无网络”，而不是现在这样猜测。。
• 另外，根据你之前说的，出现“问题”时，其他设备可以正常使用dig、wget访问？是否有确认过当时的chinadns log有收到这些dig、wget的dns解析。
• 因为我是没办法重现，而且其他人也没办法重现，要找出问题的真正原因，只能靠你自己了。最最重要的一点时，尽量不要只看表面现象，光在那猜测没意义，解决不了问题。。必须结合日志来分析，而且最好看看出问题时的log，到底有什么异常之处。。不光是chinadns-ng的日志，最理想的情况是能够分析到当时手机APP（或系统）的日志，看看到底什么鬼情况。。。

还有个办法，如果可能，建议换个环境测试，先排除是不是被openwrt上的某些东西影响到了。

另外，建议多去了解 DNS 相关的细节知识（虽然我也不太抱有什么希望了），就先这样吧。。。

恩，有空再去测了。反正现在套个dnsmasq作缓存。也能用。。。再弄下去。。老母估计会把宽带都取消掉了。。

[zfl9]

是的，主要看你自己这边了，不想折腾就现在这样也没问题。。。

[windmsn]

是的，主要看你自己这边了，不想折腾就现在这样也没问题。。。

已破案，这个原因主要是dnsmasq的port设置为0后，它将停止dns的功能，这会导致他的dhcp服务不会向客户端提供dhcp_option '6,192.168.0.1'这个东西。。客户端获取不到DNS服务器地址导致无法解析域名。而平时有时能正常使用，是因为ipv6 ra时会给客户端下发路由器的ipv6地址作为dns服务器。当ra更新的时候，，就失效了。

查阅了几个案例。发现有部分用户同样使用adgurad home代替dnsmasq时都会出现同样症状，

如若用chinadns-ng替代dnsmasq，则需要手动给dnsmasq添加dhcp_option '6,192.168.0.1' 另外，dnsmasq只有port设为53的时候，才会给客户端下发dns地址。。。监听其他端口。。都不行。

至于缓存问题，，，可能是错觉。。但也有可能是ipv6所导致。。目前还不清楚。只知道添加dhcp_option '6,192.168.0.1'后，一切症状解决。

还需给普通用户备注提醒。。。

[zfl9]

总算找到问题原因了哈，我就说这种“奇怪的”现象和 chinadns-ng 应该没关系，因为不符合程序的常理。。

在 dnsmasq 只担任 DHCP 角色时（port=0），必须确保有 dhcp_option '6,DNS服务器IP' 这样一条配置的存在。

后面我在 readme 补充说明下，防止还有人掉坑。

[zfl9]

翻了下 dnsmasq 文档：

By default, dnsmasq sends some standard options to DHCP clients, the netmask and broadcast address are set to the same as the host running dnsmasq, and the DNS server and default route are set to the address of the machine running dnsmasq.

我猜测 dnsmasq 内部逻辑是这样，当 dnsmasq 的 DNS 功能启用时（可能还有个条件，那就是端口必须是标准的 53），才会自动下发 dns-server 这个 dhcp-option，并且 dns-server 的 IP 是 dnsmasq 所在的主机的 IP。

当这个条件不满足时，比如这个 issue（port=0，关闭了 DNS），就不（自动）下发这个 dns-server option 了，于是就出现了你说的这个问题。。确实挺坑的。

解决方法就是：显式的给出 dhcp-option，不要依赖默认行为。

---

翻了翻源码，看来和我猜想的差不多：

[cattyhouse]

我是这样配置 dnsmasq 的 dhcp server 的:

pid-file
user=dnsmasq
keep-in-foreground
# port=0 关闭 dns 服务
port=0
# dhcp-range 代表开启 dhcp server
dhcp-range=x.x.x.100,x.x.x.200
# 0.0.0.0 是特殊字段, 代表运行 dnsmasq 的主机的 ip
dhcp-option=option:dns-server,0.0.0.0
dhcp-option=option:router,0.0.0.0