新版本在处理"黑名单和白名单中都能匹配成功的域名"时似乎有些问题

[ShadowOfTheDay]

最近在升级到新版本（ChinaDNS-NG 2023.04.11-2）后，观察到在处理"黑名单和白名单中都能匹配成功的域名"时和旧版本（ChinaDNS-NG v1.0-beta.25）的结果有所不同。为便于排查，新旧版本所用的命令行选项和黑白名单文件都相同，为/usr/bin/chinadns-ng -b 0.0.0.0 -l 5334 -c 223.5.5.5 -t 127.0.0.1#5311 -g /etc/chinadns-ng/gfwlist.txt -m /etc/chinadns-ng/chinalist.txt -v，按默认选项应该是优先黑名单。

以下测试了www.bloomberg.cn和tw.iqiyi.com这两个域名。前者分别匹配bloomberg.cn在黑名单中，cn在白名单中；后者有tw.iqiyi.com在黑名单，iqiyi.com在白名单。

测试结果显示，旧版ChinaDNS-NG对于这两个域名都返回trust-dns（127.0.0.1#5311）结果，而新版却是返回china-dns（223.5.5.5#53）结果。日志如下：

旧版（v1.0-beta.25）：

2023-04-17 00:24:19 INF: [main] local listen addr: 0.0.0.0#5334
2023-04-17 00:24:19 INF: [main] chinadns server#1: 223.5.5.5#53
2023-04-17 00:24:19 INF: [main] trustdns server#1: 127.0.0.1#5311
2023-04-17 00:24:19 INF: [main] ipset ip4 setname: chnroute
2023-04-17 00:24:19 INF: [main] ipset ip6 setname: chnroute6
2023-04-17 00:24:19 INF: [main] dns query timeout: 5 seconds
2023-04-17 00:24:19 INF: [main] gfwlist entries count: 6105
2023-04-17 00:24:20 INF: [main] chnlist entries count: 64163
2023-04-17 00:24:21 INF: [main] gfwlist have higher priority
2023-04-17 00:24:21 INF: [main] filter reply without ip addr
2023-04-17 00:24:21 INF: [main] cur judgment mode: fast mode
2023-04-17 00:24:21 INF: [main] print the verbose running log
2023-04-17 00:24:46 INF: [handle_local_packet] query [www.bloomberg.cn] from 127.0.0.1#52312 (0)
2023-04-17 00:24:46 INF: [handle_local_packet] query [www.bloomberg.cn] from 127.0.0.1#52312 (1)
2023-04-17 00:24:46 INF: [handle_remote_packet] reply [www.bloomberg.cn] from 127.0.0.1#5311 (0), result: accept
2023-04-17 00:24:46 INF: [handle_remote_packet] reply [www.bloomberg.cn] from 127.0.0.1#5311 (1), result: accept
2023-04-17 00:26:16 INF: [handle_local_packet] query [tw.iqiyi.com] from 127.0.0.1#36446 (2)
2023-04-17 00:26:16 INF: [handle_local_packet] query [tw.iqiyi.com] from 127.0.0.1#36446 (3)
2023-04-17 00:26:16 INF: [handle_remote_packet] reply [tw.iqiyi.com] from 127.0.0.1#5311 (2), result: accept
2023-04-17 00:26:16 INF: [handle_remote_packet] reply [tw.iqiyi.com] from 127.0.0.1#5311 (3), result: accept

新版（2023.04.11-2）

2023-04-16 16:30:22 I [main.c:337 main] local listen addr: 0.0.0.0#5334
2023-04-16 16:30:22 I [main.c:339 main] chinadns server#1: 223.5.5.5
2023-04-16 16:30:22 I [main.c:341 main] trustdns server#1: 127.0.0.1#5311
2023-04-16 16:30:22 I [ipset.c:443 ipset_init] ipset for ipv4: chnroute
2023-04-16 16:30:22 I [ipset.c:444 ipset_init] ipset for ipv6: chnroute6
2023-04-16 16:30:22 I [dnl.c:532 dnl_init] gfwlist have higher priority
2023-04-16 16:30:22 I [dnl.c:551 dnl_init] gfwlist loaded:6182 added:6181 cost:131.034k
2023-04-16 16:30:22 I [dnl.c:554 dnl_init] chnlist loaded:64194 added:64150 cost:1269.701k
2023-04-16 16:30:22 I [dnl.c:556 dnl_init] L1 items:70223 lists:54440 buckets:131072 cost:512.000k
2023-04-16 16:30:22 I [dnl.c:560 dnl_init] L2 items:108 lists:91 buckets:256 cost:1.000k
2023-04-16 16:30:22 I [dnl.c:563 dnl_init] total memory cost (page-aligned): 1916.000k
2023-04-16 16:30:22 I [main.c:349 main] default domain name tag: none
2023-04-16 16:30:22 I [main.c:350 main] filter reply without ip addr
2023-04-16 16:30:22 I [main.c:351 main] dns query timeout: 5 seconds
2023-04-16 16:30:22 I [main.c:374 main] print the verbose running log
2023-04-16 16:30:32 I [main.c:117 handle_local_packet] query [www.bloomberg.cn] from 127.0.0.1#42081 (0)
2023-04-16 16:30:32 I [main.c:162 handle_local_packet] forward [www.bloomberg.cn] to 223.5.5.5 (chinadns)
2023-04-16 16:30:32 I [main.c:117 handle_local_packet] query [www.bloomberg.cn] from 127.0.0.1#42081 (1)
2023-04-16 16:30:32 I [main.c:162 handle_local_packet] forward [www.bloomberg.cn] to 223.5.5.5 (chinadns)
2023-04-16 16:30:32 I [main.c:281 handle_remote_packet] reply [www.bloomberg.cn] from 223.5.5.5 (1), result: accept
2023-04-16 16:30:32 I [main.c:281 handle_remote_packet] reply [www.bloomberg.cn] from 223.5.5.5 (0), result: accept
2023-04-16 16:30:35 I [main.c:117 handle_local_packet] query [tw.iqiyi.com] from 127.0.0.1#40309 (2)
2023-04-16 16:30:35 I [main.c:162 handle_local_packet] forward [tw.iqiyi.com] to 223.5.5.5 (chinadns)
2023-04-16 16:30:35 I [main.c:117 handle_local_packet] query [tw.iqiyi.com] from 127.0.0.1#40309 (3)
2023-04-16 16:30:35 I [main.c:162 handle_local_packet] forward [tw.iqiyi.com] to 223.5.5.5 (chinadns)
2023-04-16 16:30:35 I [main.c:281 handle_remote_packet] reply [tw.iqiyi.com] from 223.5.5.5 (2), result: accept
2023-04-16 16:30:35 I [main.c:281 handle_remote_packet] reply [tw.iqiyi.com] from 223.5.5.5 (3), result: accept

不知是新版本的逻辑发生了变化，还是个bug？谢谢！

[ShadowOfTheDay]

顺便一提，如果是对于www.baidu.jp这种黑白名单匹配的域名完全一样（baidu.jp）的域名，新版本是可以按预期返回trust-dns的结果的。貌似只是上面那种，黑名单匹配结果为白名单子域名的情况才发现有问题。

[zfl9]

感谢反馈，大概知道是哪段逻辑的问题了。

---

之前版本的 gfwlist 和 chnlist 的数据结构是分开的，所以之前版本的 --gfwlist-frist --chnlist-first 逻辑很简单，就是先匹配哪个map。

新版本的 gfwlist 和 chnlist 放到同一个数据结构了（为了减少匹配次数，减少内存碎片），所以处理哪个列表优先的逻辑发生了改变：--gfwlist-frist --chnlist-first 变为先加载哪个list到数据结构中，因此对于同一级别的域名（label数量相同），肯定是先加载的优先级高。

换句话说，gfw优先/chn优先 的粒度 从 列表 变为 同级别域名

---

对于这样一个域名：a.b.c.d，则匹配逻辑如下：

• 检查 d 是否存在，存在则结束匹配
• 检查 c.d 是否存在，存在则结束匹配
• 检查 b.c.d 是否存在，存在则结束匹配
• 检查 a.b.c.d 是否存在，存在则结束匹配

---

代入你说的情况：

tw.iqiyi.com在黑名单，iqiyi.com在白名单。

在匹配 iqiyi.com 时，会被白名单命中，所以被判定为 tag:chn，因此走 china 上游

---

如果调用一下匹配顺序，应该就可以解决此问题，也就是改为：

• 检查 a.b.c.d 是否存在，存在则结束匹配
• 检查 b.c.d 是否存在，存在则结束匹配
• 检查 c.d 是否存在，存在则结束匹配
• 检查 d 是否存在，存在则结束匹配

对于 使用同一个父域名，然后通过不同子域来区分国家/地区 的情况，应该是可以解决问题的，比如上面说的 iqiyi.com；google这一类恰好相反，他们是通过不同的顶级域来区分 国家/地区，比如 google.com、google.de、google.com.hk、google.co.jp 等。

[zfl9]

更新到最新版本试试。

[ShadowOfTheDay]

感谢作者！！！刚刚测试了下最新版本，的确解决了上述问题。
而且我认为新的匹配逻辑比之前v1.0版本更加合理：相当于对于某域名和其子域名分别在黑白名单的情况下，子域名优先，无论黑白名单哪个优先。举例来说，之前v1.0版，默认设置黑名单优先，其中包括google.com，那么白名单中的dl.google.com就无法生效。我之前的做法是把这些域名加到dnsmasq的规则里，优先级高于ChinaDNS；在新版本下，这一步就不需要了。优先级的选项现在只对黑白名单中完全重合的域名有用了，而这种情况几乎屈指可数（比如baidu.jp），没啥实际的影响。
再次感谢🙏🙏🙏