chinadns-ng
chinadns-ng copied to clipboard
zfl9
CNAME 导致部分 AAAA 过滤失效（待商讨：使用`-d chn_A/gfw_A`方案，还是移除`CNAME`记录？）
请问 在使用
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）
你这里chinadns-ng监听的端口是7913，但是你dig访问的是53，我觉得问题可能不在chinadns-ng，请检查dns解析链路。 另外我仔细看了代码，也验证过不存在你说的“处理遗漏问题”
我的命令打错了 不好意思 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
加入过了 经测试 应该是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地址 非常感谢.
gfwlist.txt并未包括bing.com，只有global.bing.com，所以bing.com显然被判定为chn域名。
我的gfwlist已合并了自己的域名.怪我没说清楚. 请看一下后面的 谢谢
麻烦整理一下issue信息哈：
- 有问题的域名是哪个？
- chinadns-ng参数，以及log
- dnsmasq的log
- dig测试输出
请带上chinadns-ng的详细日志(-v参数) 如果涉及gfwlist/chnlist.txt，请说明相关域名属于哪个列表
是
bing.com、还是www.halowaypoint.com？还是二者？
我这边无法重现你说的问题（我手动将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
这是去掉 -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）
我这里也不是每次必然出现的. 一天有个几次会出现最后一个cname的ipv6地址.重新插拔设备网线时比较容易复现,是否是在缓存里没有的时候dnsmasq先收到了优先的aaaa查询?
具体我继续测试,如果找出原因我会继续提交日志.
ChinaDNS-NG 2023.03.10 <https://github.com/zfl9/chinadns-ng>
刚发现加上-d chn后, 老的-M没有删除,我先删除 观察一阵
关于你说的 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
关于你说的
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。我这几天会多做些测试。
将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
简单的说，微软的某些特殊应用可能会记录最终的那个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记录（不知道会不会导致软件兼容性问题？）
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（动态加入名单）呢，非常感谢！
其实有个看起来不太优雅但确实有效的办法，那就是将这些CNAME加入gfwlist.txt，无非就是花些时间收集这些域名（甚至到时候你可以维护一个这样的域名列表，方便大家使用，哈哈）。因为域名这东西，我想应该也不会经常改动。
应该只需要收集到二级域名(最多也就3级感觉)。如：
fdv2-t-msedge.net、trafficmanager.net、azurefd.net
其实有个看起来不太优雅但确实有效的办法，那就是将这些CNAME加入gfwlist.txt，无非就是花些时间收集这些域名（甚至到时候你可以维护一个这样的域名列表，方便大家使用，哈哈）。因为域名这东西，我想应该也不会经常改动。
应该只需要收集到二级域名(最多也就3级感觉)。如：
fdv2-t-msedge.net、trafficmanager.net、azurefd.net
我现在就是这么做的，但其实也有几个问题，一个是这些 cname 里面其实有国内 cdn，另一个 fdv2-t 这种还真他妈的会变。。。感觉是 azure 云的负载均衡器
我想了又想还是觉得最简单粗暴的脏脏的选项就够用，即增加一个选项，修改 respone 中的 cname 类型为 a 。这样最终应用就不会知道这是个 cname，也就不会向 dnsmasq 请求 cname，即使请求了，他和原始域名的 a 记录也是两个东西，没有对应关系，不会被覆盖。
pbs.twimg.com -> dualstack.twimg.twitter.map.fastly.net auth0.openai.com -> openai-cd-x0fecetbbtd3bmdw.edge.tenants.openai.auth0app.com 也出现了这种情况,感觉会越来越多
使用 -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的域名 😂
我大概总结一下：
若使用模式为-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 了。
实际我使用-d chn 只是不需要ipset想要完全跳过这个流程而已 ( 有自己的一套分流 ) 如果可以有更好的解决方案都好. 甚至-d可以是纯A 纯AAAA 默认A+AAAA
实际我使用-d chn 只是不需要ipset想要完全跳过这个流程而已 ( 有自己的一套分流 ) 如果可以有更好的解决方案都好.
嗯，我理解使用 -d 的目的。所以可以看看上面的“取巧办法”，应该可以解决问题（同样不会查询ipset，因为加载chnlist.txt仅仅为了no-ipv6过滤tag:none域名）
实际我使用-d chn 只是不需要ipset想要完全跳过这个流程而已 ( 有自己的一套分流 ) 如果可以有更好的解决方案都好.
嗯，我理解使用 -d 的目的。所以可以看看上面的“取巧办法”，应该可以解决问题（同样不会查询ipset，因为加载chnlist.txt仅仅为了no-ipv6过滤tag:none域名）
感觉这个会影响一些质量还不错的教育网论文网站之类的 ipv6直连(两个列表两不沾的那种)