Comments (42)
zfl9
commented on August 20, 2024
你这里chinadns-ng监听的端口是7913，但是你dig访问的是53，我觉得问题可能不在chinadns-ng，请检查dns解析链路。
另外我仔细看了代码，也验证过不存在你说的“处理遗漏问题”
from chinadns-ng.
Smallthing
commented on August 20, 2024
我的命令打错了
不好意思 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
from chinadns-ng.
zfl9
commented on August 20, 2024
那请把chinadns-ng运行日志，以及dig -p7913的输出发我。
from chinadns-ng.
zfl9
commented on August 20, 2024
gfwlist.txt并未包括bing.com，只有global.bing.com，所以bing.com显然被判定为chn域名。
from chinadns-ng.
zfl9
commented on August 20, 2024
$ grep bing.com gfwlist.txt
global.bing.comfrom chinadns-ng.
zfl9
commented on August 20, 2024
如果需要将bing.com(含所有子域)判定为gfw域名，请加入gfwlist.txt，重启chinadns-ng再试。
from chinadns-ng.
Smallthing
commented on August 20, 2024
加入过了
经测试 应该是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地址
非常感谢.
from chinadns-ng.
Smallthing
commented on August 20, 2024
gfwlist.txt并未包括bing.com，只有global.bing.com，所以bing.com显然被判定为chn域名。
我的gfwlist已合并了自己的域名.怪我没说清楚.
请看一下后面的 谢谢
from chinadns-ng.
zfl9
commented on August 20, 2024
麻烦整理一下issue信息哈：
- 有问题的域名是哪个？
- chinadns-ng参数，以及log
- dnsmasq的log
- dig测试输出
请带上chinadns-ng的详细日志(-v参数)
如果涉及gfwlist/chnlist.txt，请说明相关域名属于哪个列表
是
bing.com、还是www.halowaypoint.com？还是二者？
from chinadns-ng.
zfl9
commented on August 20, 2024
我这边无法重现你说的问题（我手动将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-IPv6chinadns-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_gfwdig 测试，查询 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: 61dig 测试，查询 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: 61from chinadns-ng.
zfl9
commented on August 20, 2024
这是去掉 -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: acceptdnsmasq
$ 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::39dig 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: 85dig 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）
from chinadns-ng.
zfl9
commented on August 20, 2024
我希望你这边能够按照上述流程（测试样板），复现一下。请务必带上chinadns-ng的日志，dnsmasq日志如果可以也请带上。
from chinadns-ng.
Smallthing
commented on August 20, 2024
我这里也不是每次必然出现的.
一天有个几次会出现最后一个cname的ipv6地址.重新插拔设备网线时比较容易复现,是否是在缓存里没有的时候dnsmasq先收到了优先的aaaa查询?
具体我继续测试,如果找出原因我会继续提交日志.
ChinaDNS-NG 2023.03.10 <https://github.com/zfl9/chinadns-ng>
刚发现加上-d chn后, 老的-M没有删除,我先删除 观察一阵
from chinadns-ng.
zfl9
commented on August 20, 2024
是否是在缓存里没有的时候dnsmasq先收到了优先的aaaa查询?
A和AAAA查询是两个独立的dns query请求，我不认为存在所谓优先级。
from chinadns-ng.
zfl9
commented on August 20, 2024
关于你说的 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: 161from chinadns-ng.
Smallthing
commented on August 20, 2024
关于你说的
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。我这几天会多做些测试。
from chinadns-ng.
Smallthing
commented on August 20, 2024
将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
from chinadns-ng.
Smallthing
commented on August 20, 2024
简单的说，微软的某些特殊应用可能会记录最终的那个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记录（不知道会不会导致软件兼容性问题？）
from chinadns-ng.
Smallthing
commented on August 20, 2024
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（动态加入名单）呢，非常感谢！
from chinadns-ng.
zfl9
commented on August 20, 2024
这。。。属实是 小刀拉屁股，开眼了。有点为难我胖虎啊。我先研究dnsmasq源码吧，后面再看看咋搞。
from chinadns-ng.
zfl9
commented on August 20, 2024
其实有个看起来不太优雅但确实有效的办法，那就是将这些CNAME加入gfwlist.txt，无非就是花些时间收集这些域名（甚至到时候你可以维护一个这样的域名列表，方便大家使用，哈哈）。因为域名这东西，我想应该也不会经常改动。
应该只需要收集到二级域名(最多也就3级感觉)。如：
fdv2-t-msedge.net、trafficmanager.net、azurefd.net
from chinadns-ng.
Smallthing
commented on August 20, 2024
其实有个看起来不太优雅但确实有效的办法，那就是将这些CNAME加入gfwlist.txt，无非就是花些时间收集这些域名（甚至到时候你可以维护一个这样的域名列表，方便大家使用，哈哈）。因为域名这东西，我想应该也不会经常改动。
应该只需要收集到二级域名(最多也就3级感觉)。如：
fdv2-t-msedge.net、trafficmanager.net、azurefd.net
我现在就是这么做的，但其实也有几个问题，一个是这些 cname 里面其实有国内 cdn，另一个 fdv2-t 这种还真他妈的会变。。。感觉是 azure 云的负载均衡器
我想了又想还是觉得最简单粗暴的脏脏的选项就够用，即增加一个选项，修改 respone 中的 cname 类型为 a 。这样最终应用就不会知道这是个 cname，也就不会向 dnsmasq 请求 cname，即使请求了，他和原始域名的 a 记录也是两个东西，没有对应关系，不会被覆盖。
from chinadns-ng.
zfl9
commented on August 20, 2024
其实我一直有个疑问，win客户端是怎么拿到cname的。请求aaaa的时候都直接返回空response回去了
from chinadns-ng.
zfl9
commented on August 20, 2024
哦我知道了，a请求的时候带了cname回去
from chinadns-ng.
Smallthing
commented on August 20, 2024
哦我知道了，a请求的时候带了cname回去
是的 粗暴的解法就是gfwlist的域名，no-ipv6的时候 去掉这个cname
from chinadns-ng.
Smallthing
commented on August 20, 2024
pbs.twimg.com -> dualstack.twimg.twitter.map.fastly.net
auth0.openai.com -> openai-cd-x0fecetbbtd3bmdw.edge.tenants.openai.auth0app.com
也出现了这种情况,感觉会越来越多
from chinadns-ng.
zfl9
commented on August 20, 2024
使用 -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的域名 😂
from chinadns-ng.
zfl9
commented on August 20, 2024
我大概总结一下：
若使用模式为-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 了。
from chinadns-ng.
Smallthing
commented on August 20, 2024
实际我使用-d chn 只是不需要ipset想要完全跳过这个流程而已 ( 有自己的一套分流 ) 如果可以有更好的解决方案都好.
甚至-d可以是纯A 纯AAAA 默认A+AAAA
from chinadns-ng.
zfl9
commented on August 20, 2024
实际我使用-d chn 只是不需要ipset想要完全跳过这个流程而已 ( 有自己的一套分流 ) 如果可以有更好的解决方案都好.
嗯，我理解使用 -d 的目的。所以可以看看上面的“取巧办法”，应该可以解决问题（同样不会查询ipset，因为加载chnlist.txt仅仅为了no-ipv6过滤tag:none域名）
from chinadns-ng.
Smallthing
commented on August 20, 2024
实际我使用-d chn 只是不需要ipset想要完全跳过这个流程而已 ( 有自己的一套分流 ) 如果可以有更好的解决方案都好.
嗯，我理解使用 -d 的目的。所以可以看看上面的“取巧办法”，应该可以解决问题（同样不会查询ipset，因为加载chnlist.txt仅仅为了no-ipv6过滤tag:none域名）
感觉这个会影响一些质量还不错的教育网论文网站之类的 ipv6直连(两个列表两不沾的那种)
from chinadns-ng.
zfl9
commented on August 20, 2024
但是相比 移除CNAME 带来的问题，我感觉这个还是可以接受的（起码可以自己维护这些域名列表，加到 gfwlist.txt 或 chnlist.txt 去）
from chinadns-ng.
Smallthing
commented on August 20, 2024
是的, 如果不好加入的话,有空我看看自己把-gt的函数加上过滤掉cname尾巴试试 :)
from chinadns-ng.
zfl9
commented on August 20, 2024
哈哈，也可以的。
from chinadns-ng.
zfl9
commented on August 20, 2024
不过如果要移除CNAME记录的话，就要重新构建response了，而且别忘了dns域名压缩指针（因为指针存的是一个从包头开始的偏移值，所以如果受到影响，记得修正它）
from chinadns-ng.
zfl9
commented on August 20, 2024
那我这边先不加入 -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。
from chinadns-ng.
Smallthing
commented on August 20, 2024
碰到一个超级恶心的域名
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
我也不知道这些程序员脑子里装的什么.好像也没听说有人劫持他啊
from chinadns-ng.
zfl9
commented on August 20, 2024
这个cname看起来有点奇怪，直接把ip地址给编码进去了。。
from chinadns-ng.
Smallthing
commented on August 20, 2024
试用了很久 还是gfw_A chn_A这种比较好 凑合解决问题。
from chinadns-ng.
Smallthing
commented on August 20, 2024
整合一下吧，感恩。
from chinadns-ng.
zfl9
commented on August 20, 2024
目前没空哈，后面再说。
from chinadns-ng.
zfl9
commented on August 20, 2024
#144 完成后，不出意外，会来解决这个问题。
from chinadns-ng.
Related Issues (20)
- Openwrt中运行一段时间后，chinadns-ng会出现大概率返回超时的情况 HOT 56
- 新功能: 将tag:gfw的解析结果也加入ipset/nftset HOT 2
- 关于 --add-tagchn-ip --add-taggfw-ip 的两点建议 HOT 16
- 动态添加IP问题(选项没指定，语法错误) HOT 19
- 请教redsocks和iptables搭配chinadns-ng进行DNS分流的食用方法 HOT 20
- 编译时报错 HOT 3
- mirrors.aliyuncs.com 解析失败 HOT 13
- nftset flags: timeout HOT 15
- chinadns-ng和mosdns有啥区别呢 HOT 1
- ac68u上的崩溃日志 HOT 3
- 用 int 承接 ts 会导致 2038问题, 建议所有ts都用time_t 或者 long long HOT 1
- 如何对查询结果附加(append)三方DNS记录 HOT 3
- 对于tag:none的组能否添加ipset的支持 HOT 5
- 问一下， chinadns-ng如果接管127.0.0.1:53后会缓存dns结果吗？ HOT 2
- 监听0.0.0.0的时候能否连带ipv6的 [::]也监听了呢？ HOT 3
- DNS上游没有响应任何查询，并非死循环。 HOT 48
- 对分流有个优化思路 HOT 1
- 问一个关于ChinaDNS-NG 域名默认标签“智能dns”的逻辑问题 HOT 7
- ChinaDNS-NG 2.0 HOT 62
- 可信DNS解析结果没有加入ipset的集合中，麻烦看一下是配置哪里有问题哦 HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from chinadns-ng.