CNAME 导致部分 AAAA 过滤失效（使用`-d chn_A/gfw_A`方案） #119

Smallthing · 2023-03-31T02:15:45Z

请问
在使用

chinadns-ng -p 2 -N=gt -l 7913 -c 119.29.29.29#53,119.28.28.28#53 -t 127.0.0.1#1055 -g /tmp/gfwlist.txt -d chn

这个参数的时候，时不时的会漏一点ipv6的解析出来(确信bing.com www.bing 各种bing的域名都在gfwlist.txt里面）
是我的配置有误还是我理解不对还是说处理中有遗漏呢？谢谢

./dig @127.0.0.1 -p53 www.bing.com AAAA
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 31534
;; Flags: qr rd ra; QUERY: 1; ANSWER: 4; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; www.bing.com.       		IN	AAAA

;; ANSWER SECTION:
www.bing.com.       	106	IN	CNAME	www-www.bing.com.trafficmanager.net.
www-www.bing.com.trafficmanager.net. 106	IN	CNAME	www-bing-com.dual-a-0001.a-msedge.net.
www-bing-com.dual-a-0001.a-msedge.net. 395	IN	CNAME	dual-a-0001.a-msedge.net.
dual-a-0001.a-msedge.net.	700	IN	AAAA	2620:1ec:c11::200

并不是每时每刻都这样，大部分时候是没有的，然后突然会解析出一个v6地址（然后因为变成了直连无法访问，因为我透明代理和服务端只开启了v4）

The text was updated successfully, but these errors were encountered:

zfl9 · 2023-03-31T02:22:22Z

你这里chinadns-ng监听的端口是7913，但是你dig访问的是53，我觉得问题可能不在chinadns-ng，请检查dns解析链路。
另外我仔细看了代码，也验证过不存在你说的“处理遗漏问题”

Smallthing · 2023-03-31T02:24:28Z

我的命令打错了
不好意思 dig 7913 with AAAA结果是相同的。
53端口是个缓存而已

pid-file=/var/run/dnsmasq.pid
user=nobody
bind-dynamic
interface=br0
interface=pptp*
no-dhcp-interface=pptp*
no-poll
no-resolv
server=127.0.0.1#7913
min-cache-ttl=900

zfl9 · 2023-03-31T02:27:29Z

那请把chinadns-ng运行日志，以及dig -p7913的输出发我。

zfl9 · 2023-03-31T02:59:14Z

gfwlist.txt并未包括bing.com，只有global.bing.com，所以bing.com显然被判定为chn域名。

zfl9 · 2023-03-31T03:00:24Z

$ grep bing.com gfwlist.txt
global.bing.com

zfl9 · 2023-03-31T03:03:36Z

如果需要将bing.com(含所有子域)判定为gfw域名，请加入gfwlist.txt，重启chinadns-ng再试。

Smallthing · 2023-03-31T04:38:54Z

加入过了
经测试应该是cname部分有问题,不清楚是dnsmasq的问题还是chinadns-ng的问题
即:

dig www.halowaypoint.com AAAA -p 53
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 3806
;; Flags: qr rd ra; QUERY: 1; ANSWER: 6; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; www.halowaypoint.com.		IN	AAAA

;; ANSWER SECTION:
www.halowaypoint.com.	811	IN	CNAME	waypoint-web-prod-gcb2d6gegzardhg0.z01.azurefd.net.
waypoint-web-prod-gcb2d6gegzardhg0.z01.azurefd.net. 811	IN	CNAME	star-azurefd-prod.trafficmanager.net.
star-azurefd-prod.trafficmanager.net. 829	IN	CNAME	shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net.
shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net. 829	IN	CNAME	part-0018.t-0009.fdv2-t-msedge.net.
part-0018.t-0009.fdv2-t-msedge.net. 806	IN	AAAA	2620:1ec:4f:1::46
part-0018.t-0009.fdv2-t-msedge.net. 806	IN	AAAA	2620:1ec:4e:1::46

dig www.halowaypoint.com AAAA -p 7913
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 62635
;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; www.halowaypoint.com.		IN	AAAA

;; Received 38 B
;; Time 2023-03-31 12:35:29 GMT
;; From 127.0.0.1@7913(UDP) in 0.1 ms

dig part-0018.t-0009.fdv2-t-msedge.net AAAA -p 7913
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 48583
;; Flags: qr rd ra; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; part-0018.t-0009.fdv2-t-msedge.net. 	IN	AAAA

;; ANSWER SECTION:
part-0018.t-0009.fdv2-t-msedge.net. 60	IN	AAAA	2620:1ec:4e:1::46
part-0018.t-0009.fdv2-t-msedge.net. 60	IN	AAAA	2620:1ec:4f:1::46

;; Received 108 B
;; Time 2023-03-31 12:35:50 GMT
;; From 127.0.0.1@7913(UDP) in 92.4 ms

经过测试cname后面的每一级都会有ipv6解析.并且这个结果会被dnsmasq吃进去.
请问应该如何让多重cname后的域名也进行no-ipv6?谢谢. chinadns-ng端是否无法辨识是什么cname
难道必须把每一级都加入?那也太傻了.国外爱用的这些cname递归应该都是cdn负载均衡器,随时会发生变化的.
如果可以把每一层解析出来的结果做判断如果是cname就临时加入内存中no-ipv6的域名列表中,生命周期为上级缓存的ttl,这样可行吗?
或是干脆加一个简单粗暴的选项,隐藏掉后续所有cname过程和域名,对下级dns/最终用户端只返回ip地址
非常感谢.

Smallthing · 2023-03-31T04:40:38Z

gfwlist.txt并未包括bing.com，只有global.bing.com，所以bing.com显然被判定为chn域名。

我的gfwlist已合并了自己的域名.怪我没说清楚.
请看一下后面的谢谢

zfl9 · 2023-03-31T06:11:29Z

麻烦整理一下issue信息哈：

有问题的域名是哪个？
chinadns-ng参数，以及log
dnsmasq的log
dig测试输出

请带上chinadns-ng的详细日志(-v参数)
如果涉及gfwlist/chnlist.txt，请说明相关域名属于哪个列表

是bing.com、还是www.halowaypoint.com？还是二者？

zfl9 · 2023-03-31T06:36:26Z

我这边无法重现你说的问题（我手动将bing.com和www.halowaypoint.com）加入了gfwlist.txt，并且chinadns-ng参数与你说的相同；dig via dnsmasq、dig via chinadns-ng 都正常。

dnsmasq 日志

$ dnsmasq --no-daemon --server='127.0.0.1#65353' --port 53 --log-debug --no-resolv --log-queries
dnsmasq: started, version 2.89 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
dnsmasq: using nameserver 127.0.0.1#65353
dnsmasq: read /etc/hosts - 0 names

dnsmasq: query[AAAA] bing.com from 127.0.0.1
dnsmasq: forwarded bing.com to 127.0.0.1#65353
dnsmasq: reply bing.com is NODATA-IPv6

dnsmasq: query[AAAA] www.halowaypoint.com from 127.0.0.1
dnsmasq: forwarded www.halowaypoint.com to 127.0.0.1#65353
dnsmasq: reply www.halowaypoint.com is NODATA-IPv6

chinadns-ng 日志

$ ./chinadns-ng -v -N=gt -c 192.168.2.84 -t 192.168.2.89 -g gfwlist.txt -d chn
2023-03-31 14:17:32 I: [main] local listen addr: 127.0.0.1#65353
2023-03-31 14:17:32 I: [main] chinadns server#1: 192.168.2.84#53
2023-03-31 14:17:32 I: [main] trustdns server#1: 192.168.2.89#53
2023-03-31 14:17:32 I: [main] ipset ip4 setname: chnroute
2023-03-31 14:17:32 I: [main] ipset ip6 setname: chnroute6
2023-03-31 14:17:32 I: [dnl_init] gfwlist-name 5705 98.702k
2023-03-31 14:17:32 I: [dnl_init] gfwlist-bucket 5704 44.562k
2023-03-31 14:17:32 I: [dnl_init] other-bucket 2552 19.938k
2023-03-31 14:17:32 I: [main] default domain name tag: chn
2023-03-31 14:17:32 I: [main] filter reply without ip addr
2023-03-31 14:17:32 I: [main] dns query timeout: 5 seconds
2023-03-31 14:17:32 I: [main] filter AAAA for gfwlist name
2023-03-31 14:17:32 I: [main] filter AAAA for trust upstream
2023-03-31 14:17:32 I: [main] print the verbose running log

2023-03-31 14:32:19 I: [handle_local_packet] query [bing.com] from 127.0.0.1#50533 (4)
2023-03-31 14:32:19 I: [handle_local_packet] filter [bing.com] AAAA query, rule: tag_gfw

2023-03-31 14:32:27 I: [handle_local_packet] query [www.halowaypoint.com] from 127.0.0.1#56544 (4)
2023-03-31 14:32:27 I: [handle_local_packet] filter [www.halowaypoint.com] AAAA query, rule: tag_gfw

2023-03-31 14:32:33 I: [handle_local_packet] query [bing.com] from 127.0.0.1#39129 (4)
2023-03-31 14:32:33 I: [handle_local_packet] filter [bing.com] AAAA query, rule: tag_gfw

2023-03-31 14:32:38 I: [handle_local_packet] query [www.halowaypoint.com] from 127.0.0.1#44313 (4)
2023-03-31 14:32:38 I: [handle_local_packet] filter [www.halowaypoint.com] AAAA query, rule: tag_gfw

dig 测试，查询 dnsmasq 的监听端口

# root @ archlinux in ~ [14:29:28]
$ dig @127.0.0.1 -p53 bing.com AAAA

; <<>> DiG 9.18.12 <<>> @127.0.0.1 -p53 bing.com AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51163
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 31896912a2a18ca8 (echoed)
;; QUESTION SECTION:
;bing.com.			IN	AAAA

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Mar 31 14:32:19 CST 2023
;; MSG SIZE  rcvd: 49


# root @ archlinux in ~ [14:32:19]
$ dig @127.0.0.1 -p53 www.halowaypoint.com AAAA

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 090f653db39a0252 (echoed)
;; QUESTION SECTION:
;www.halowaypoint.com.		IN	AAAA

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Mar 31 14:32:27 CST 2023
;; MSG SIZE  rcvd: 61

dig 测试，查询 chinadns-ng 的监听端口

# root @ archlinux in ~ [14:32:27]
$ dig @127.0.0.1 -p65353 bing.com AAAA

; <<>> DiG 9.18.12 <<>> @127.0.0.1 -p65353 bing.com AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25689
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 0a896d474cef4e7e (echoed)
;; QUESTION SECTION:
;bing.com.			IN	AAAA

;; Query time: 3 msec
;; SERVER: 127.0.0.1#65353(127.0.0.1) (UDP)
;; WHEN: Fri Mar 31 14:32:33 CST 2023
;; MSG SIZE  rcvd: 49


# root @ archlinux in ~ [14:32:33]
$ dig @127.0.0.1 -p65353 www.halowaypoint.com AAAA

; <<>> DiG 9.18.12 <<>> @127.0.0.1 -p65353 www.halowaypoint.com AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29307
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 617562796714b385 (echoed)
;; QUESTION SECTION:
;www.halowaypoint.com.		IN	AAAA

;; Query time: 3 msec
;; SERVER: 127.0.0.1#65353(127.0.0.1) (UDP)
;; WHEN: Fri Mar 31 14:32:38 CST 2023
;; MSG SIZE  rcvd: 61

zfl9 · 2023-03-31T06:47:11Z

这是去掉 -N=gt 参数后的 dig 测试结果（其他参数未变）

chinadns-ng

$ ./chinadns-ng -v -c 192.168.2.84 -t 192.168.2.89 -g gfwlist.txt -d chn
2023-03-31 14:42:59 I: [main] local listen addr: 127.0.0.1#65353
2023-03-31 14:42:59 I: [main] chinadns server#1: 192.168.2.84#53
2023-03-31 14:42:59 I: [main] trustdns server#1: 192.168.2.89#53
2023-03-31 14:42:59 I: [main] ipset ip4 setname: chnroute
2023-03-31 14:42:59 I: [main] ipset ip6 setname: chnroute6
2023-03-31 14:42:59 I: [dnl_init] gfwlist-name 5705 98.702k
2023-03-31 14:42:59 I: [dnl_init] gfwlist-bucket 5704 44.562k
2023-03-31 14:42:59 I: [dnl_init] other-bucket 2552 19.938k
2023-03-31 14:42:59 I: [main] default domain name tag: chn
2023-03-31 14:42:59 I: [main] filter reply without ip addr
2023-03-31 14:42:59 I: [main] dns query timeout: 5 seconds
2023-03-31 14:42:59 I: [main] print the verbose running log

2023-03-31 14:43:08 I: [handle_local_packet] query [bing.com] from 127.0.0.1#33510 (0)
2023-03-31 14:43:08 I: [handle_local_packet] forward [bing.com] to 192.168.2.89#53 (trustdns)
2023-03-31 14:43:08 I: [handle_remote_packet] reply [bing.com] from 192.168.2.89#53 (0), result: accept

2023-03-31 14:43:14 I: [handle_local_packet] query [bing.com] from 127.0.0.1#41122 (1)
2023-03-31 14:43:14 I: [handle_local_packet] forward [bing.com] to 192.168.2.89#53 (trustdns)
2023-03-31 14:43:14 I: [handle_remote_packet] reply [bing.com] from 192.168.2.89#53 (1), result: accept

2023-03-31 14:43:22 I: [handle_local_packet] query [www.halowaypoint.com] from 127.0.0.1#56979 (2)
2023-03-31 14:43:22 I: [handle_local_packet] forward [www.halowaypoint.com] to 192.168.2.89#53 (trustdns)
2023-03-31 14:43:22 I: [handle_remote_packet] reply [www.halowaypoint.com] from 192.168.2.89#53 (2), result: accept

2023-03-31 14:43:29 I: [handle_local_packet] query [www.halowaypoint.com] from 127.0.0.1#44096 (3)
2023-03-31 14:43:29 I: [handle_local_packet] forward [www.halowaypoint.com] to 192.168.2.89#53 (trustdns)
2023-03-31 14:43:29 I: [handle_remote_packet] reply [www.halowaypoint.com] from 192.168.2.89#53 (3), result: accept

dnsmasq

$ dnsmasq --no-daemon --server='127.0.0.1#65353' --port 53 --log-debug --no-resolv --log-queries
dnsmasq: started, version 2.89 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
dnsmasq: using nameserver 127.0.0.1#65353
dnsmasq: read /etc/hosts - 0 names

dnsmasq: query[AAAA] bing.com from 127.0.0.1
dnsmasq: forwarded bing.com to 127.0.0.1#65353
dnsmasq: reply bing.com is 2620:1ec:c11::200


dnsmasq: query[AAAA] www.halowaypoint.com from 127.0.0.1
dnsmasq: forwarded www.halowaypoint.com to 127.0.0.1#65353
dnsmasq: reply www.halowaypoint.com is <CNAME>
dnsmasq: reply waypoint-web-prod-gcb2d6gegzardhg0.z01.azurefd.net is <CNAME>
dnsmasq: reply star-azurefd-prod.trafficmanager.net is <CNAME>
dnsmasq: reply shed.dual-low.part-0011.t-0009.fdv2-t-msedge.net is <CNAME>
dnsmasq: reply part-0011.t-0009.fdv2-t-msedge.net is 2620:1ec:4e:1::39
dnsmasq: reply part-0011.t-0009.fdv2-t-msedge.net is 2620:1ec:4f:1::39

dig bing.com

# root @ archlinux in ~ [14:42:54]
$ dig @127.0.0.1 -p53 bing.com AAAA

; <<>> DiG 9.18.12 <<>> @127.0.0.1 -p53 bing.com AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22214
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: a922afd8835cd471 (echoed)
;; QUESTION SECTION:
;bing.com.			IN	AAAA

;; ANSWER SECTION:
bing.com.		30	IN	AAAA	2620:1ec:c11::200

;; Query time: 26 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Mar 31 14:43:08 CST 2023
;; MSG SIZE  rcvd: 85


# root @ archlinux in ~ [14:43:08]
$ dig @127.0.0.1 -p65353 bing.com AAAA

; <<>> DiG 9.18.12 <<>> @127.0.0.1 -p65353 bing.com AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64477
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 5f29e51d35250fa1 (echoed)
;; QUESTION SECTION:
;bing.com.			IN	AAAA

;; ANSWER SECTION:
bing.com.		24	IN	AAAA	2620:1ec:c11::200

;; Query time: 0 msec
;; SERVER: 127.0.0.1#65353(127.0.0.1) (UDP)
;; WHEN: Fri Mar 31 14:43:14 CST 2023
;; MSG SIZE  rcvd: 85

dig www.halowaypoint.com

# root @ archlinux in ~ [14:43:14]
$ dig @127.0.0.1 -p53 www.halowaypoint.com AAAA

; <<>> DiG 9.18.12 <<>> @127.0.0.1 -p53 www.halowaypoint.com AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35454
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 7ae2c979fc010267 (echoed)
;; QUESTION SECTION:
;www.halowaypoint.com.		IN	AAAA

;; ANSWER SECTION:
www.halowaypoint.com.	14	IN	CNAME	waypoint-web-prod-gcb2d6gegzardhg0.z01.azurefd.net.
waypoint-web-prod-gcb2d6gegzardhg0.z01.azurefd.net. 14 IN CNAME	star-azurefd-prod.trafficmanager.net.
star-azurefd-prod.trafficmanager.net. 14 IN CNAME shed.dual-low.part-0011.t-0009.fdv2-t-msedge.net.
shed.dual-low.part-0011.t-0009.fdv2-t-msedge.net. 14 IN	CNAME part-0011.t-0009.fdv2-t-msedge.net.
part-0011.t-0009.fdv2-t-msedge.net. 14 IN AAAA	2620:1ec:4e:1::39
part-0011.t-0009.fdv2-t-msedge.net. 14 IN AAAA	2620:1ec:4f:1::39

;; Query time: 13 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Mar 31 14:43:22 CST 2023
;; MSG SIZE  rcvd: 563


# root @ archlinux in ~ [14:43:22]
$ dig @127.0.0.1 -p65353 www.halowaypoint.com AAAA

; <<>> DiG 9.18.12 <<>> @127.0.0.1 -p65353 www.halowaypoint.com AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9157
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 3e5edb9a40b18b3a (echoed)
;; QUESTION SECTION:
;www.halowaypoint.com.		IN	AAAA

;; ANSWER SECTION:
www.halowaypoint.com.	8	IN	CNAME	waypoint-web-prod-gcb2d6gegzardhg0.z01.azurefd.net.
waypoint-web-prod-gcb2d6gegzardhg0.z01.azurefd.net. 8 IN CNAME star-azurefd-prod.trafficmanager.net.
star-azurefd-prod.trafficmanager.net. 8	IN CNAME shed.dual-low.part-0011.t-0009.fdv2-t-msedge.net.
shed.dual-low.part-0011.t-0009.fdv2-t-msedge.net. 8 IN CNAME part-0011.t-0009.fdv2-t-msedge.net.
part-0011.t-0009.fdv2-t-msedge.net. 8 IN AAAA	2620:1ec:4f:1::39
part-0011.t-0009.fdv2-t-msedge.net. 8 IN AAAA	2620:1ec:4e:1::39

;; Query time: 3 msec
;; SERVER: 127.0.0.1#65353(127.0.0.1) (UDP)
;; WHEN: Fri Mar 31 14:43:29 CST 2023
;; MSG SIZE  rcvd: 563

在未过滤AAAA的情况下，bing.com并未携带CNAME记录。www.halowaypoint.com确实有CNAME记录。

但是在-N=gt模式时，我并未重现你说的问题（bing.com以及www.halowaypoint.com均已正常过滤v6）

zfl9 · 2023-03-31T06:51:26Z

我希望你这边能够按照上述流程（测试样板），复现一下。请务必带上chinadns-ng的日志，dnsmasq日志如果可以也请带上。

Smallthing · 2023-03-31T06:51:54Z

我这里也不是每次必然出现的.
一天有个几次会出现最后一个cname的ipv6地址.重新插拔设备网线时比较容易复现,是否是在缓存里没有的时候dnsmasq先收到了优先的aaaa查询?

具体我继续测试,如果找出原因我会继续提交日志.

ChinaDNS-NG 2023.03.10 <https://github.com/zfl9/chinadns-ng>

刚发现加上-d chn后, 老的-M没有删除,我先删除观察一阵

zfl9 · 2023-03-31T06:55:24Z

是否是在缓存里没有的时候dnsmasq先收到了优先的aaaa查询?

A和AAAA查询是两个独立的dns query请求，我不认为存在所谓优先级。

zfl9 · 2023-03-31T07:24:29Z

关于你说的 dnsmasq会递归解析上游返回的CNAME记录，我认为也不成立。

这一点可以通过dnsmasq的log来验证（可以看前面的dnsmasq日志输出）。

而且以我的认知来理解，我不认为dns中间件会做这种处理(也不需要)；因为dnsmasq/chinadns-ng使用的上游通常都是递归DNS（也就是本地ISP/公共dns服务器），若权威服务器（拥有此域名的服务器）返回CNAME记录，则递归DNS会继续进行解析操作，等拿到最终IP后，才会作为单个response，将其交给下游。这里的下游，也就是dnsmasq/chinadns-ng。因此并不需要这些dnsmasq/chinadns-ng来执行这些（迭代查询）操作。

举个最简单的例子，dig baidu.com

$ dig www.baidu.com

; <<>> DiG 9.18.12 <<>> www.baidu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49007
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; MBZ: 0x0005, udp: 1232
; COOKIE: e2578f1036b76b7b (echoed)
;; QUESTION SECTION:
;www.baidu.com.			IN	A

;; ANSWER SECTION:
www.baidu.com.		5	IN	CNAME	www.a.shifen.com.
www.a.shifen.com.	5	IN	A	14.119.104.254
www.a.shifen.com.	5	IN	A	14.119.104.189

;; Query time: 0 msec
;; SERVER: 192.168.136.2#53(192.168.136.2) (UDP)
;; WHEN: Fri Mar 31 15:22:15 CST 2023
;; MSG SIZE  rcvd: 161

Smallthing · 2023-03-31T17:59:00Z

关于你说的 dnsmasq会递归解析上游返回的CNAME记录，我认为也不成立。

这一点可以通过dnsmasq的log来验证（可以看前面的dnsmasq日志输出）。

而且以我的认知来理解，我不认为dns中间件会做这种处理(也不需要)；因为dnsmasq/chinadns-ng使用的上游通常都是递归DNS（也就是公共dns服务器），若权威服务器（拥有此域名的服务器）返回CNAME记录，则递归DNS会进行递归解析操作，拿到最终IP后，才会作为单个response，将其交给下游。这里的下游，也就是dnsmasq/chinadns-ng。因此并不需要这些dnsmasq/chinadns-ng来执行递归操作。

举个最简单的例子，dig baidu.com
$ dig www.baidu.com

; <<>> DiG 9.18.12 <<>> www.baidu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49007
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; MBZ: 0x0005, udp: 1232
; COOKIE: e2578f1036b76b7b (echoed)
;; QUESTION SECTION:
;www.baidu.com.			IN	A

;; ANSWER SECTION:
www.baidu.com.		5	IN	CNAME	www.a.shifen.com.
www.a.shifen.com.	5	IN	A	14.119.104.254
www.a.shifen.com.	5	IN	A	14.119.104.189

;; Query time: 0 msec
;; SERVER: 192.168.136.2#53(192.168.136.2) (UDP)
;; WHEN: Fri Mar 31 15:22:15 CST 2023
;; MSG SIZE  rcvd: 161

是的 dnsmasq并没有做递归解析，在chinadns-ng中cname的aaaa ip已经存在（被解析过并且是v6）但是原域名的aaa被过滤。但不知道什么机制让dnsmasq得到了cname的aaaa ip。我这几天会多做些测试。

Smallthing · 2023-04-01T18:24:49Z

将dnsmasq的本地缓存时间改为10秒后测试多次，终于得到稳定复现的方法。
如果是我dnsmasq的配置问题（正在寻找解决方案），不知道有没有网友可以提供正确的配置。
POWERSHELL:

PS C:\Users\XXXXXX> nslookup www.halowaypoint.com 10.1.1.1
服务器:  RT-AC86U-XXXX
Address:  10.1.1.1

非权威应答:
名称:    part-0018.t-0009.fdv2-t-msedge.net
Addresses:  13.107.238.46
          13.107.237.46
Aliases:  www.halowaypoint.com
          waypoint-web-prod-gcb2d6gegzardhg0.z01.azurefd.net
          star-azurefd-prod.trafficmanager.net
          shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net

PS C:\Users\XXXXXX> nslookup shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net
服务器:  RT-AC86U-XXXX
Address:  240e:37a:xxxx:yyyy::1

非权威应答:
名称:    part-0018.t-0009.fdv2-t-msedge.net
Addresses:  2620:1ec:4f:1::46
          2620:1ec:4e:1::46
          13.107.237.46
          13.107.238.46
Aliases:  shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net

PS C:\Users\XXXXXX> nslookup www.halowaypoint.com 10.1.1.1
服务器:  RT-AC86U-XXXX
Address:  10.1.1.1

非权威应答:
名称:    part-0018.t-0009.fdv2-t-msedge.net
Addresses:  2620:1ec:4e:1::46
          2620:1ec:4f:1::46
          13.107.238.46
          13.107.237.46
Aliases:  www.halowaypoint.com
          waypoint-web-prod-gcb2d6gegzardhg0.z01.azurefd.net
          star-azurefd-prod.trafficmanager.net
          shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net

DNSMASQ;

dnsmasq: query[A] www.halowaypoint.com from 10.1.1.8
dnsmasq: forwarded www.halowaypoint.com to 127.0.0.1
dnsmasq: reply www.halowaypoint.com is <CNAME>
dnsmasq: reply waypoint-web-prod-gcb2d6gegzardhg0.z01.azurefd.net is <CNAME>
dnsmasq: reply star-azurefd-prod.trafficmanager.net is <CNAME>
dnsmasq: reply shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net is <CNAME>
dnsmasq: ipset add black_list 13.107.238.46 part-0018.t-0009.fdv2-t-msedge.net
dnsmasq: reply part-0018.t-0009.fdv2-t-msedge.net is 13.107.238.46
dnsmasq: ipset add black_list 13.107.237.46 part-0018.t-0009.fdv2-t-msedge.net
dnsmasq: reply part-0018.t-0009.fdv2-t-msedge.net is 13.107.237.46
dnsmasq: query[AAAA] www.halowaypoint.com from 10.1.1.8
dnsmasq: cached www.halowaypoint.com is <CNAME>
dnsmasq: cached waypoint-web-prod-gcb2d6gegzardhg0.z01.azurefd.net is <CNAME>
dnsmasq: cached star-azurefd-prod.trafficmanager.net is <CNAME>
dnsmasq: cached shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net is <CNAME>
dnsmasq: forwarded www.halowaypoint.com to 127.0.0.1
dnsmasq: nameserver 127.0.0.1 refused to do a recursive query
dnsmasq: query[A] shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net from 240e:37a:xxxx:yyyy:zzzz:aaaa:bbbb:cccc
dnsmasq: cached shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net is <CNAME>
dnsmasq: cached part-0018.t-0009.fdv2-t-msedge.net is 13.107.237.46
dnsmasq: cached part-0018.t-0009.fdv2-t-msedge.net is 13.107.238.46
dnsmasq: query[AAAA] shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net from 240e:37a:xxxx:yyyy:zzzz:aaaa:bbbb:cccc
dnsmasq: cached shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net is <CNAME>
dnsmasq: forwarded shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net to 127.0.0.1
dnsmasq: reply shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net is <CNAME>
dnsmasq: reply part-0018.t-0009.fdv2-t-msedge.net is 2620:1ec:4f:1::46
dnsmasq: reply part-0018.t-0009.fdv2-t-msedge.net is 2620:1ec:4e:1::46
dnsmasq: query[A] www.halowaypoint.com from 10.1.1.8
dnsmasq: cached www.halowaypoint.com is <CNAME>
dnsmasq: cached waypoint-web-prod-gcb2d6gegzardhg0.z01.azurefd.net is <CNAME>
dnsmasq: cached star-azurefd-prod.trafficmanager.net is <CNAME>
dnsmasq: cached shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net is <CNAME>
dnsmasq: cached part-0018.t-0009.fdv2-t-msedge.net is 13.107.238.46
dnsmasq: cached part-0018.t-0009.fdv2-t-msedge.net is 13.107.237.46
dnsmasq: query[AAAA] www.halowaypoint.com from 10.1.1.8
dnsmasq: cached www.halowaypoint.com is <CNAME>
dnsmasq: cached waypoint-web-prod-gcb2d6gegzardhg0.z01.azurefd.net is <CNAME>
dnsmasq: cached star-azurefd-prod.trafficmanager.net is <CNAME>
dnsmasq: cached shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net is <CNAME>
dnsmasq: cached part-0018.t-0009.fdv2-t-msedge.net is 2620:1ec:4e:1::46
dnsmasq: cached part-0018.t-0009.fdv2-t-msedge.net is 2620:1ec:4f:1::46

CHINADNS-NG:

2023-04-02 02:21:52 I: [handle_local_packet] query [www.halowaypoint.com] from 127.0.0.1#60741 (600)
2023-04-02 02:21:52 I: [handle_local_packet] forward [www.halowaypoint.com] to 127.0.0.1#1055 (trustdns)
2023-04-02 02:21:52 I: [handle_local_packet] forward [www.halowaypoint.com] to 127.0.0.1#1055 (trustdns)
2023-04-02 02:21:52 I: [handle_remote_packet] reply [www.halowaypoint.com] from 127.0.0.1#1055 (600), result: accept
2023-04-02 02:21:52 I: [handle_remote_packet] reply [www.halowaypoint.com] from 127.0.0.1#1055 (600), result: ignore
2023-04-02 02:21:52 I: [handle_local_packet] query [www.halowaypoint.com] from 127.0.0.1#26385 (601)
2023-04-02 02:21:52 I: [handle_local_packet] filter [www.halowaypoint.com] AAAA query, rule: tag_gfw
2023-04-02 02:21:53 I: [handle_local_packet] query [shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net] from 127.0.0.1#16452 (601)
2023-04-02 02:21:53 I: [handle_local_packet] forward [shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net] to 119.29.29.29#53 (chinadns)
2023-04-02 02:21:53 I: [handle_local_packet] forward [shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net] to 119.28.28.28#53 (chinadns)
2023-04-02 02:21:54 I: [handle_remote_packet] reply [shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net] from 119.28.28.28#53 (601), result: accept
2023-04-02 02:21:54 I: [handle_remote_packet] reply [shed.dual-low.part-0018.t-0009.fdv2-t-msedge.net] from 119.29.29.29#53 (601), result: ignore

Smallthing · 2023-04-01T18:29:34Z

简单的说，微软的某些特殊应用可能会记录最终的那个cname
第一次：访问该域名，CHINADNS-NG过滤掉了AAAA记录。DNSMASQ内部也一样没有获得AAAA。
第二次：当app内部直接向dnsmasq请求最后一个cname（我使用nslookup模拟）时，因为这个cname没有在gfwlist里面，没有发往trustdns，而是正常解析了，于是chinadns-ng里面，原始域名是没有AAAA的，而树的末端最终CNAME有AAAA。于是（不知道为啥，可能是我配置问题？）dnsmasq会使用这个cname的缓存内的AAAA直接覆盖掉上一个空白的（被过滤的）AAAA记录。
第三次：之后直接解析www.halowaypoint.com会直接得到AAAA记录。

幻想：如果可以在chinadns-ng这一头彻底解决这个问题就完美了，可能会增加复杂度，如，在使用--no-ipv6=gt等参数时，gfwlist递归出来的cname加入临时gfwlist，确保结果去除AAAA的完美。或者简单粗暴的去掉cname直接返回一个a记录（不知道会不会导致软件兼容性问题？）

Smallthing · 2023-04-01T18:45:39Z

https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011194.html
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011068.html
粗看了一些应该是dnsmasq的“行为”
在不能修改dnsmasq的情况下，是否可以增加一个选项以便在chinadns-ng里面处理掉特定名单下面递归的cname（动态加入名单）呢，非常感谢！

zfl9 · 2023-04-03T03:40:25Z

其实有个看起来不太优雅但确实有效的办法，那就是将这些CNAME加入gfwlist.txt，无非就是花些时间收集这些域名（甚至到时候你可以维护一个这样的域名列表，方便大家使用，哈哈）。因为域名这东西，我想应该也不会经常改动。

应该只需要收集到二级域名(最多也就3级感觉)。如：fdv2-t-msedge.net、trafficmanager.net、azurefd.net

Smallthing · 2023-04-03T13:29:39Z

其实有个看起来不太优雅但确实有效的办法，那就是将这些CNAME加入gfwlist.txt，无非就是花些时间收集这些域名（甚至到时候你可以维护一个这样的域名列表，方便大家使用，哈哈）。因为域名这东西，我想应该也不会经常改动。

应该只需要收集到二级域名(最多也就3级感觉)。如：fdv2-t-msedge.net、trafficmanager.net、azurefd.net

我现在就是这么做的，但其实也有几个问题，一个是这些 cname 里面其实有国内 cdn，另一个 fdv2-t 这种还真他妈的会变。。。感觉是 azure 云的负载均衡器

我想了又想还是觉得最简单粗暴的脏脏的选项就够用，即增加一个选项，修改 respone 中的 cname 类型为 a 。这样最终应用就不会知道这是个 cname，也就不会向 dnsmasq 请求 cname，即使请求了，他和原始域名的 a 记录也是两个东西，没有对应关系，不会被覆盖。

zfl9 · 2023-04-03T14:18:22Z

其实我一直有个疑问，win客户端是怎么拿到cname的。请求aaaa的时候都直接返回空response回去了

zfl9 · 2023-04-03T14:19:15Z

哦我知道了，a请求的时候带了cname回去

Smallthing · 2023-04-04T02:20:35Z

哦我知道了，a请求的时候带了cname回去

是的粗暴的解法就是gfwlist的域名，no-ipv6的时候去掉这个cname

Smallthing · 2023-04-07T06:00:58Z

pbs.twimg.com -> dualstack.twimg.twitter.map.fastly.net
auth0.openai.com -> openai-cd-x0fecetbbtd3bmdw.edge.tenants.openai.auth0app.com
也出现了这种情况,感觉会越来越多

zfl9 · 2023-04-07T07:47:20Z

使用 -N=gnt，而不是 -N=gt，估计可以过滤掉这些CNAME域名。

- rule g: filter the name with tag gfw
- rule m: filter the name with tag chn
- rule n: filter the name with tag none
- rule c: do not forward to china upstream
- rule t: do not forward to trust upstream
- rule C: check answer ip of china upstream
- rule T: check answer ip of trust upstream

换句话说，只允许 tag:chn (chnlist.txt) 中的域名查询 AAAA。

我还是倾向于不添加这些过滤CNAME的功能，总感觉不够优雅，容易滋生bug。

好吧，我已经看到你在使用 -d chn 选项了，所以不存在 tag:none 的域名 😂

zfl9 · 2023-04-07T08:27:37Z

我大概总结一下：

若使用模式为`-g gfwlist.txt -m chnlist.txt`，则v6过滤的常见组合：

AAAA 请求只走 china 上游

-N=gt：允许chnlist.txt域名(走china)、非chnlist.txt&&非gfwlist.txt域名(走china，不进行ipset过滤)
-N=gtC：允许chnlist.txt域名(走china)、非chnlist.txt&&非gfwlist.txt域名(走china，会进行ipset过滤)
-N=gnt：允许chnlist.txt域名(走china)

AAAA 请求只走 trust 上游

-N=mc：允许gfwlist.txt域名(走trust)、非chnlist.txt&&非gfwlist.txt域名(走trust，不进行ipset过滤)
-N=mcT：允许gfwlist.txt域名(走trust)、非chnlist.txt&&非gfwlist.txt域名(走trust，会进行ipset过滤)
-N=mnc：允许gfwlist.txt域名(走trust)

@Smallthing 的问题是使用了 -d 纯域名分流模式，导致不存在 tag:none（非gfwlist.txt非chnlist.txt域名）。

如果改为常规的 -g gfwlist.txt -m chnlist.txt，应该就可以比较舒服的避免此问题（这些CNAME通常都是tag:none）

UPDATE: 有个比较取巧的办法：让 -d 纯域名分流模式 只对非AAAA请求生效，说人话就是：

当客户端进行A查询时（或者其他类型的查询，只要不是AAAA查询就行），则使用 纯域名分流模式
当客户端进行AAAA查询时，使用传统 -g gfwlist.txt -m chnlist.txt 模式，这样我们又有了 tag:none 域名，所以可以应用之前说的 rule n 规则，过滤他们的 AAAA 查询。（当然，这个行为可以通过某个选项来控制）

也就是说，题主现在的启动参数为：

-g gfwlist.txt -d chn -N=gt

由于非gfwlist.txt域名都被判定为 tag:chn，比如那些 CNAME，而又因为 no-ipv6 只过滤 tag:gfw，所以有漏网之鱼。

如果改为刚刚说的取巧办法，则启动参数看起来像这样：

-g gfwlist.txt -m chnlist.txt -d chn_A -N=gnt
# 如果是 -d gfw 则 改为 -d gfw_A

这样 A 查询时，还是以“纯域名分流进行”，进行 AAAA 查询时，以传统的 tag:gfw、tag:chn、tag:none 模式运行（准确来说，不完全等价于-g gfwlist.txt -m chnlist.txt模式，因为none域名的AAAA查询被过滤了，所以这里只是为了获得tag:none域名列表而已，不会调用ipset相关逻辑），这样就可以过滤掉这些 CNAME 了。

Smallthing · 2023-04-07T09:49:11Z

实际我使用-d chn 只是不需要ipset想要完全跳过这个流程而已 ( 有自己的一套分流 ) 如果可以有更好的解决方案都好.
甚至-d可以是纯A 纯AAAA 默认A+AAAA

zfl9 · 2023-04-07T09:50:33Z

实际我使用-d chn 只是不需要ipset想要完全跳过这个流程而已 ( 有自己的一套分流 ) 如果可以有更好的解决方案都好.

嗯，我理解使用 -d 的目的。所以可以看看上面的“取巧办法”，应该可以解决问题（同样不会查询ipset，因为加载chnlist.txt仅仅为了no-ipv6过滤tag:none域名）

Smallthing · 2023-04-07T09:53:08Z

实际我使用-d chn 只是不需要ipset想要完全跳过这个流程而已 ( 有自己的一套分流 ) 如果可以有更好的解决方案都好.

嗯，我理解使用 -d 的目的。所以可以看看上面的“取巧办法”，应该可以解决问题（同样不会查询ipset，因为加载chnlist.txt仅仅为了no-ipv6过滤tag:none域名）

感觉这个会影响一些质量还不错的教育网论文网站之类的 ipv6直连(两个列表两不沾的那种)

zfl9 · 2023-04-07T09:54:48Z

但是相比移除CNAME 带来的问题，我感觉这个还是可以接受的（起码可以自己维护这些域名列表，加到 gfwlist.txt 或 chnlist.txt 去）

Smallthing · 2023-04-07T09:56:07Z

是的, 如果不好加入的话,有空我看看自己把-gt的函数加上过滤掉cname尾巴试试 :)

zfl9 · 2023-04-07T09:57:41Z

哈哈，也可以的。

zfl9 · 2023-04-07T10:03:22Z

不过如果要移除CNAME记录的话，就要重新构建response了，而且别忘了dns域名压缩指针（因为指针存的是一个从包头开始的偏移值，所以如果受到影响，记得修正它）

zfl9 · 2023-04-07T10:10:24Z

那我这边先不加入 -d chn_A、-d gfw_A 逻辑了，让你这边先折腾，后面再看采用什么方案吧 😂

我个人不赞同移除CNAME记录是因为这样做的杀伤力太大，因为这些CNAME实际上不是AAAA请求带来的（请求AAAA的时候，若该域名被no-ipv6规则命中，那么chinadns-ng实际上是直接返回空response回去的，并没有经过上游解析，所以这个阶段是拿不到CNAME的）；客户端获取这些CNAME的渠道其实是非AAAA请求带来的，比如A请求。因此，要实现题主的AAAA过滤需求，就需要对所有gfwlist域名（如果是-d gfw -N=mc，那么就是所有chnlist域名）的非AAAA请求的response进行处理，将其中的CNAME记录手动干掉，这样才能完全堵死CNAME获取渠道。但真要这样做，就会导致杀伤力过大，容易导致其他问题（我暂时无法举出移除CNAME会带来什么问题，但总感觉不够“安全”）。

如果使用-g gfwlist.txt -m chnlist.txt -d chn_A -N=gnt，则安全许多。这实际上只允许chnlist.txt域名的AAAA请求，即使出现遗漏的域名，那也可以简单的补充到chnlist.txt列表。相比移除CNAME的方案，这不会带来“不确定因素”，显然更不容易出bug。

Smallthing · 2023-05-14T08:30:03Z

碰到一个超级恶心的域名
Name: e87.dscb.akamaiedge.net
Address 1: 2600:1417:7800:4b6::57 g2600-1417-7800-04b6-0000-0000-0000-0057.deploy.static.akamaitechnologies.com
Address 2: 2600:1417:7800:4bc::57 g2600-1417-7800-04bc-0000-0000-0000-0057.deploy.static.akamaitechnologies.com
Address 3: 23.77.214.7 a23-77-214-7.deploy.static.akamaitechnologies.com

这个后面的cname似乎变化非常的快，而且我把deploy.static.akamaitechnologies.com加入gfw列表没用，是太长了？
非常奇葩的是在系统里面怎么弄都不会被v6污染，一进入游戏dns就被污染了，猜测游戏实现了一套内置的域名请求系统

做了一些代码修改，在构造多cname->多A记录的情况下总是有点错误，dns协议这方面经验确实不足见谅
那就使用gnt偷鸡法吧,至少用起来会比较舒服, 毕竟如果第三方应用直接能获取到上面这种cname(只有v6地址的cname)列表,似乎,避免不了污染吗,只能让他解析不出来,fallback回v4
我也不知道这些程序员脑子里装的什么.好像也没听说有人劫持他啊

zfl9 · 2023-05-15T08:17:37Z

这个cname看起来有点奇怪，直接把ip地址给编码进去了。。

Smallthing · 2023-08-21T09:41:45Z

试用了很久还是gfw_A chn_A这种比较好凑合解决问题。

Smallthing · 2023-08-21T12:00:37Z

整合一下吧，感恩。

zfl9 · 2023-08-21T12:15:59Z

目前没空哈，后面再说。

zfl9 · 2023-12-02T15:18:39Z

#144 完成后，不出意外，会来解决这个问题。

zfl9 · 2024-03-25T08:08:52Z

试试最新的 2024.03.25 版本，使用 chinadns-ng 的缓存，而不是 dnsmasq 的（关闭缓存），看能否解决此问题。

如果原因是你说的那样（dnsmasq 特有的一些缓存行为、怪癖），那使用 chinadns-ng 的缓存应该可以解决此问题。

zfl9 · 2024-04-10T09:01:09Z

试试最新的 2024.03.25 版本，使用 chinadns-ng 的缓存，而不是 dnsmasq 的（关闭缓存），看能否解决此问题。

如果原因是你说的那样（dnsmasq 特有的一些缓存行为、怪癖），那使用 chinadns-ng 的缓存应该可以解决此问题。

没问题的话，我先关了，后面有问题再 reopen。

Smallthing · 2024-04-16T18:46:03Z

试过了 dnsmasq的缓存设置为0 一切都非常舒服。ss-tproxy那边同步了这个更新吗

zfl9 · 2024-04-17T02:02:49Z

已经同步了，4.8版本

Smallthing changed the title ~~使用新版的--no-ipv6=gt 鹅-d chn功能后遇到一些问题~~ 使用新版的--no-ipv6=gt 和 -d chn功能后遇到一些问题 Mar 31, 2023

zfl9 added the invalid This doesn't seem right label Mar 31, 2023

zfl9 removed the invalid This doesn't seem right label Mar 31, 2023

Smallthing changed the title ~~使用新版的--no-ipv6=gt 和 -d chn功能后遇到一些问题~~ 使用新版的--no-ipv6=gt 和 -d chn功能后遇到一些问题(已复现） Apr 2, 2023

zfl9 changed the title ~~使用新版的--no-ipv6=gt 和 -d chn功能后遇到一些问题(已复现）~~ dnsmasq CNAME 缓存导致 AAAA 过滤失效的问题（待商讨） Apr 2, 2023

zfl9 changed the title ~~dnsmasq CNAME 缓存导致 AAAA 过滤失效的问题（待商讨）~~ CNAME 导致部分 AAAA 过滤失效（待商讨：使用-d chn_A/gfw_A方案，还是移除CNAME记录？） Apr 7, 2023

Smallthing mentioned this issue Dec 2, 2023

ChinaDNS-NG 2.0 #144

Closed

16 tasks

xhqpp mentioned this issue Feb 3, 2024

丢弃AAAA记录（--no-ipv6）gt 会有漏网之鱼 hq450/fancyss#33314

Open

zfl9 changed the title ~~CNAME 导致部分 AAAA 过滤失效（待商讨：使用-d chn_A/gfw_A方案，还是移除CNAME记录？）~~ CNAME 导致部分 AAAA 过滤失效（使用-d chn_A/gfw_A方案） Mar 15, 2024

zfl9 added the enhancement New feature or request label Mar 15, 2024

zfl9 closed this as completed Apr 10, 2024

CNAME 导致部分 AAAA 过滤失效（使用-d chn_A/gfw_A方案） #119

CNAME 导致部分 AAAA 过滤失效（使用-d chn_A/gfw_A方案） #119

Comments

Smallthing commented Mar 31, 2023 • edited Loading

zfl9 commented Mar 31, 2023

Smallthing commented Mar 31, 2023

zfl9 commented Mar 31, 2023

zfl9 commented Mar 31, 2023

zfl9 commented Mar 31, 2023

zfl9 commented Mar 31, 2023

Smallthing commented Mar 31, 2023 • edited Loading

Smallthing commented Mar 31, 2023

zfl9 commented Mar 31, 2023

zfl9 commented Mar 31, 2023

dnsmasq 日志

chinadns-ng 日志

dig 测试，查询 dnsmasq 的监听端口

dig 测试，查询 chinadns-ng 的监听端口

zfl9 commented Mar 31, 2023

chinadns-ng

dnsmasq

dig bing.com

dig www.halowaypoint.com

zfl9 commented Mar 31, 2023 • edited Loading

Smallthing commented Mar 31, 2023

zfl9 commented Mar 31, 2023

zfl9 commented Mar 31, 2023 • edited Loading

Smallthing commented Mar 31, 2023

Smallthing commented Apr 1, 2023 • edited Loading

Smallthing commented Apr 1, 2023 • edited Loading

Smallthing commented Apr 1, 2023

zfl9 commented Apr 3, 2023 • edited Loading

Smallthing commented Apr 3, 2023 • edited Loading

zfl9 commented Apr 3, 2023

zfl9 commented Apr 3, 2023 • edited Loading

Smallthing commented Apr 4, 2023

Smallthing commented Apr 7, 2023

zfl9 commented Apr 7, 2023 • edited Loading

zfl9 commented Apr 7, 2023 • edited Loading

若使用模式为-g gfwlist.txt -m chnlist.txt，则v6过滤的常见组合：

AAAA 请求只走 china 上游

AAAA 请求只走 trust 上游

Smallthing commented Apr 7, 2023 • edited Loading

zfl9 commented Apr 7, 2023 • edited Loading

Smallthing commented Apr 7, 2023

zfl9 commented Apr 7, 2023

Smallthing commented Apr 7, 2023

zfl9 commented Apr 7, 2023

zfl9 commented Apr 7, 2023

zfl9 commented Apr 7, 2023 • edited Loading

Smallthing commented May 14, 2023 • edited Loading

zfl9 commented May 15, 2023

Smallthing commented Aug 21, 2023

Smallthing commented Aug 21, 2023

zfl9 commented Aug 21, 2023

zfl9 commented Dec 2, 2023

zfl9 commented Mar 25, 2024 • edited Loading

zfl9 commented Apr 10, 2024

Smallthing commented Apr 16, 2024

zfl9 commented Apr 17, 2024

CNAME 导致部分 AAAA 过滤失效（使用`-d chn_A/gfw_A`方案） #119

CNAME 导致部分 AAAA 过滤失效（使用`-d chn_A/gfw_A`方案） #119

Smallthing commented Mar 31, 2023 •

edited

Loading

Smallthing commented Mar 31, 2023 •

edited

Loading

zfl9 commented Mar 31, 2023 •

edited

Loading

zfl9 commented Mar 31, 2023 •

edited

Loading

Smallthing commented Apr 1, 2023 •

edited

Loading

Smallthing commented Apr 1, 2023 •

edited

Loading

zfl9 commented Apr 3, 2023 •

edited

Loading

Smallthing commented Apr 3, 2023 •

edited

Loading

zfl9 commented Apr 3, 2023 •

edited

Loading

zfl9 commented Apr 7, 2023 •

edited

Loading

zfl9 commented Apr 7, 2023 •

edited

Loading

若使用模式为`-g gfwlist.txt -m chnlist.txt`，则v6过滤的常见组合：

Smallthing commented Apr 7, 2023 •

edited

Loading

zfl9 commented Apr 7, 2023 •

edited

Loading

zfl9 commented Apr 7, 2023 •

edited

Loading

Smallthing commented May 14, 2023 •

edited

Loading

zfl9 commented Mar 25, 2024 •

edited

Loading