search

zfl9 / chinadns-ng

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

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

Closed Smallthing closed 4 months ago

Smallthing commented 1 year ago

请问 在使用

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）

zfl9 commented 1 year ago

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

Smallthing commented 1 year ago

我的命令打错了 不好意思 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 commented 1 year ago

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

zfl9 commented 1 year ago

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

zfl9 commented 1 year ago 
$ grep bing.com gfwlist.txt
global.bing.com
zfl9 commented 1 year ago

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

Smallthing commented 1 year ago

加入过了 经测试 应该是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 commented 1 year ago

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

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

zfl9 commented 1 year ago

麻烦整理一下issue信息哈：

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

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

zfl9 commented 1 year ago

我这边无法重现你说的问题（我手动将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 commented 1 year ago

这是去掉 -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 commented 1 year ago

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

Smallthing commented 1 year ago

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

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

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

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

zfl9 commented 1 year ago

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

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

zfl9 commented 1 year ago

关于你说的 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 commented 1 year ago

关于你说的 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 commented 1 year ago

将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 commented 1 year ago

简单的说，微软的某些特殊应用可能会记录最终的那个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 commented 1 year ago

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 commented 1 year ago

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

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

Smallthing commented 1 year ago

其实有个看起来不太优雅但确实有效的办法，那就是将这些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 commented 1 year ago

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

zfl9 commented 1 year ago

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

Smallthing commented 1 year ago

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

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

Smallthing commented 1 year ago

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

zfl9 commented 1 year ago

使用 -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 commented 1 year ago

我大概总结一下：

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

AAAA 请求只走 china 上游

AAAA 请求只走 trust 上游

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

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

UPDATE: 有个比较取巧的办法：让 -d 纯域名分流模式 只对 非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 commented 1 year ago

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

zfl9 commented 1 year ago

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

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

Smallthing commented 1 year ago

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

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

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

zfl9 commented 1 year ago

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

Smallthing commented 1 year ago

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

zfl9 commented 1 year ago

哈哈，也可以的。

zfl9 commented 1 year ago

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

zfl9 commented 1 year ago

那我这边先不加入 -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 commented 1 year ago

碰到一个超级恶心的域名 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 commented 1 year ago

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

Smallthing commented 1 year ago

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

Smallthing commented 1 year ago

整合一下吧，感恩。

zfl9 commented 1 year ago

目前没空哈，后面再说。

zfl9 commented 8 months ago

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

zfl9 commented 5 months ago

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

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

zfl9 commented 4 months ago

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

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

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

Smallthing commented 4 months ago

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

zfl9 commented 4 months ago

已经同步了，4.8版本