Coder Social home page Coder Social logo

zfl9 / chinadns-ng Goto Github PK

View Code? Open in Web Editor NEW
1.0K 42.0 179.0 2.18 MB

chinadns 重构增强版，支持域名分流、ipset/nftset、UDP/TCP/DoT

License: GNU Affero General Public License v3.0

C 28.34% Shell 0.59% Zig 71.07%
chinadns chinadns-ng ipset netlink ss-tproxy dns gfwlist dnsmasq nftables dot

chinadns-ng's Issues

How to compile arm base binary file?

I tried to change command to make CC=arm-linux-gnueabihf-gcc, and there is no respond for it.

it only report"make: Nothing to be done for 'all'." it looks like that can not finish cross compile if the method I tried is right.

Thanks if you have time to reply!

-4, --ipset-name4 <ipv4-setname> 这个参数不使用也是默认在用吗?

请教作者

-4, --ipset-name4 ipset ipv4 set name, default: chnroute
说明文档中说该参数默认是 chnroute, 如果我在命令行中不使用-4, 程序也是默认使用chnroute的吗? 还是说命令行中没有-4 就不使用ipset了? 只是在用-4 不指定时默认chnroute?

我想问的意思是是不是不管命令行有没有-4的参数, 这个ipset都是起作用的?

dnsutils.c 似乎和centos 6不兼容？

2020-03-03 20:03:23 ERR: [dns_qheader_check] this is a query packet, but header->qr != 0
2020-03-03 20:03:28 ERR: [dns_qheader_check] this is a query packet, but header->qr != 0
2020-03-03 20:03:33 ERR: [dns_qheader_check] this is a query packet, but header->qr != 0
完全无法解析，修改dns_qheader_check函数，直接return true倒是可以绕过

有俩网址，原版没问题，但是chinadns-ng就不行？该怎么设置，哪里的问题呀？

版本是最新的ChinaDNS-NG v1.0-beta.15

跑在路由器上的，配合ss的dnsmsq，ss是gfwlist模式

这两个网址，同样跑在路由器上原版chinadns使用服务器202.106.195.68,202.106.46.151,dns.google可以打开
https://cn.wsj.com/
https://cn.nytimes.com/

ss没有改动任何配置情况下ng版打不开这俩网址，试了下边这几个参数都打不开

  • -g /opt/app/chinadns_ng/gfwlist.txt
  • -g /opt/app/chinadns_ng/gfwlist.txt -f
  • -f
  • 空，没加任何参数

gfwlist是采用https://github.com/gfwlist/gfwlist ，包含
.nytimes.com
||nytimes.com
.wsj.com
||wsj.com

然后ng版本，测试访问google，youtube正常

新功能请求：并发请求

记录一些能想到的一些新功能：

  1. 并发请求，来自这里 e768685#r34908475
    2. 添加一个 --cache-size <num> 选项，用于设置缓存域名的个数，默认值为 0，即不设置缓存。
    当有客户端请求域名时，先查找缓存中是否有该域名的结果，如果有，则不向上游请求，直接从缓存中返回；如果没有再接着当前版本的逻辑执行下去。缓存过期时间默认为 TTL 超时的时间。
    3. 再添加一个 --min-cache-ttl <seconds> 选项，用于重新设置缓存结果的 TTL 超时时间，默认值为 0，即不设置，这时的 TTL 为默认上游返回的时间。

待定：
1. 是否应该缓存无效的结果？例如一些不存在的域名：dig jdhfjdufjsisgovojdjdjf.com...
2. 是否应该添加一个 --min-ttl <seconds> 用于设置不开启缓存时候的 TTL 超时时间？
3. 当不存在指定的 ipset 时，是不是应该直接退出程序显得比较合理？不然没有意义。

@zfl9

failed: connection refused 

root@iZwz9d1rjhrzzxa4lsoi93Z:~# dig pixiv.net @127.0.0.1 -p 5360
;; Truncated, retrying in TCP mode.
;; Connection to 127.0.0.1#5360(127.0.0.1) for pixiv.net failed: connection refused.

root@iZwz9d1rjhrzzxa4lsoi93Z:~# dig pixiv.net @127.0.0.1 -p 5360

; <<>> DiG 9.10.3-P4-Debian <<>> pixiv.net @127.0.0.1 -p 5360
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44245
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;pixiv.net.                     IN      A

;; ANSWER SECTION:
pixiv.net.              168     IN      A       210.140.131.219

;; Query time: 5 msec
;; SERVER: 127.0.0.1#5360(127.0.0.1)
;; WHEN: Tue Mar 31 22:31:45 CST 2020
;; MSG SIZE  rcvd: 43

第一TCP查询失败，第二次才正常，怎么解决这中问题？
A}$KPTIBX7DXN$~~@ZV8ZHJ

逻辑上的一点儿小疑问

举例

网址：iptv.pdsu.edu.cn，不在黑名单和白名单里
A：211.69.16.31，不在chnroute
AAAA：2001:250:4814:1::200，在chnroute6

软件设置：指定国内dns和可信dns，指定黑名单和白名单，白名单优先，公平模式，
备注：上游dns禁止返回AAAA，只能返回A记录，

按照公平模式来的话，实测最终只返回了211.69.16.31这个结果。

因为是双栈的，所以我没太明白，国内的dns返回结果因为211.69.16.31不在chnroute就连同AAAA地址一起都被丢弃了吗？

出错提示failed to bind address to socket 

# /usr/local/bin/chinadns-ng -v
2019-10-28 14:23:16 INF: [main] local listen addr: 127.0.0.1#65353
2019-10-28 14:23:16 INF: [main] chinadns server#1: 114.114.114.114#53
2019-10-28 14:23:16 INF: [main] trustdns server#1: 8.8.8.8#53
2019-10-28 14:23:16 INF: [main] ipset ip4 setname: chnroute
2019-10-28 14:23:16 INF: [main] ipset ip6 setname: chnroute6
2019-10-28 14:23:16 INF: [main] dns query timeout: 3 seconds
2019-10-28 14:23:16 INF: [main] core judgment mode: fast mode
2019-10-28 14:23:16 INF: [main] print the verbose running log
2019-10-28 14:23:16 ERR: [main] failed to bind address to socket: (98) Address already in use

需求建议

由于某些原因我希望用sniproxy来实现(半)透明代理。
sniproxy运行在VPS上，局域网里某台机器443端口tunnel到sniproxy上。
希望能实现若国内DNS的解析结果是国外IP/不在ipset里，则返回自定义IP，不需要去跟可信DNS解析。
不知道是否方便实现？

功能请求：支持 EDNS Client Subnet (ECS)

用过一些支持 EDNS 的工具，可以把 IP 地址传递给 DNS，以获得距离用户位置更近、精度更高的解析效果。

希望能添加这两个选项：

--china-dns-subnet <subnet>    # 向国内 DNS 请求时所附带的信息
--trust-dns-subnet <subnet>    # 向可信 DNS 请求时所附带的信息

它们的值可以为：

# China DNS
--china-dns-subnet 203.208.39.216
--china-dns-subnet 203.208.39.216/32
--china-dns-subnet 203.208.39.0/24
# Trust DNS
--trust-dns-subnet 172.217.11.78
--trust-dns-subnet 172.217.11.78/32
--trust-dns-subnet 172.217.11.0/24
  • 当这两个参数为空时，关闭 EDNS 功能，逻辑和目前的版本一样。
  • 这两个参数可以被独立使用，即当 --china-dns-subnet 被指定，--trust-dns-subnet 不指定，则只向国内 DNS 使用 EDNS, 反之亦然。

这样就能得到距离自己实际位置最近的结果，和距离自己 VPS 最近的结果了。

参考

  1. https://tools.ietf.org/html/rfc7871
  2. https://en.wikipedia.org/wiki/EDNS_Client_Subnet

googleapis.cn的域名解析为污染地址

log dump
query [services.googleapis.cn] from 127.0.0.1#53351
[handle_remote_packet] reply [services.googleapis.cn] from 114.114.114.114#53, result: accept
[handle_remote_packet] reply [services.googleapis.cn] from 127.0.0.1#5300, result: ignore

googleapis.cn解析发送给了国内DNS。

root@OpenWrt:~/chinadns-ng-latest# dig services.googleapis.cn @127.0.0.1 -p 5300

; <<>> DiG 9.14.8 <<>> services.googleapis.cn @127.0.0.1 -p 5300
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41291
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;services.googleapis.cn. IN A

;; ANSWER SECTION:
services.googleapis.cn. 299 IN A 74.125.200.94

127.0.0.1#5300为可信DNS，因为cn后缀没有转发给它，所以我还还要在dnsmasq中单独添加一条/googleapis.cn/127.0.0.1#5300

交叉编译的文件不能运行

我用entware的toolchain交叉编译出来的文件，在K3上不能运行，提示 -sh: ./chinadns-ng: not found 。编译过程中没有报错。

chinadns-ng 与 Unbound EDNS 配合貌似有问题

大神您好，我使用的是 Unbound 做缓存 + 上游 chinadns-ng （使用国内dns 119.29.29.29 + dot/doh 可信dns），但是我测试的时候发现当 Unbound 开启 edns 后，会频繁出现上游链接超时，不开启 edns 上游就不超时，而且很多域名无法解析，关闭 unbound edns 就正常了，我有三台机器全部能复现，使用 dnsdist 开启 edns 后也是这个样子，搞不清楚是哪里的问题，请教一下大神。

2020-03-11 17:45:32 INF: [handle_remote_packet] reply [sb.scorecardresearch.com.edgekey.net] from 127.0.0.1#5354, result: delay
2020-03-11 17:45:32 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 335
2020-03-11 17:45:32 INF: [handle_local_packet] query [c.bing.com] from 127.0.0.1#65445
2020-03-11 17:45:32 INF: [handle_remote_packet] reply [c.bing.com] from 127.0.0.1#5354, result: delay
2020-03-11 17:45:33 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 336
2020-03-11 17:45:33 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 337
2020-03-11 17:45:34 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 338
2020-03-11 17:45:35 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 339
2020-03-11 17:45:35 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 340
2020-03-11 17:45:35 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 341
2020-03-11 17:45:35 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 342
2020-03-11 17:45:35 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 343
2020-03-11 17:45:35 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 344
2020-03-11 17:45:35 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 345
2020-03-11 17:45:35 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 346
2020-03-11 17:45:36 INF: [handle_local_packet] query [www.bing.com] from 127.0.0.1#50444
2020-03-11 17:45:39 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 347

feature request：白名单域名支持

首先，chinadns-ng很好用，在我的使用情形下，域名能得到正确的解析，并且有相当好的cdn效果。很喜欢-g, --gfwlist-file功能，但是在使用中遇到一些问题：

1. -g模式下：

运行命令：chinadns-ng -l 7913 -t 127.0.0.1#1055 -g /path/to/gfwlist.txt
设置详情：其中，国内DNS默认114DNS，国外DNS127.0.0.1#1055是我的dns2socks上游，通过ss-local转发到vps进行远程解析，无污染可信任，gfwlist.txt来自本项目，chnroute从ipip源生成。
问题描述：此情况下，一些希望解析到国内IP的域名，被解析到了国外，比如clientservices.googleapis.com，查了下gfwlist.txt，应该是gfwlist.txt里收录了googleapis.com原因导致（链接）。 虽然谷歌在大陆关闭了搜索等业务，但是还是有很多服务是在国内的，找到dnsmasq-china-list项目整理了一份列表：google.china.conf，这里的域名应该用国内DNS解析，以达到国内cdn的效果。
我简单写了个脚本，在-g模式下对google.china.conf进行了DNS查询，结果如下：

1	203.208.40.88	mainland_ip!	265.com
2	--------------	-------------	2mdn.net
3	172.217.24.66	overseas_ip!	adservice.google.com
4	203.208.40.103	mainland_ip!	app-measurement.com
5	203.208.41.119	mainland_ip!	beacons.gcp.gvt2.com
6	203.208.41.111	mainland_ip!	beacons.gvt2.com
7	203.208.41.127	mainland_ip!	beacons3.gvt2.com
8	216.58.220.194	overseas_ip!	c.admob.com
9	--------------	-------------	c.android.clients.google.com
10	172.217.25.14	overseas_ip!	cache.pack.google.com
11	216.58.200.3	overseas_ip!	cdn.ampproject.org
12	216.58.221.227	overseas_ip!	checkin.gstatic.com
13	203.208.41.40	mainland_ip!	clickserve.dartsearch.net
14	172.217.24.195	overseas_ip!	clientservices.googleapis.com
15	172.217.31.227	overseas_ip!	connectivitycheck.gstatic.com
16	172.217.25.3	overseas_ip!	crl.pki.goog
17	172.217.24.67	overseas_ip!	csi.gstatic.com
18	172.217.24.78	overseas_ip!	dl.google.com
19	172.217.161.174	overseas_ip!	dl.l.google.com
20	216.58.221.238	overseas_ip!	doubleclick.net
21	172.217.31.234	overseas_ip!	fonts.googleapis.com
22	216.58.220.195	overseas_ip!	fonts.gstatic.com
23	172.217.161.132	overseas_ip!	google-analytics.com
24	203.208.41.121	mainland_ip!	googleadservices.com
25	172.217.161.164	overseas_ip!	googleanalytics.com
26	216.58.199.4	overseas_ip!	googlesyndication.com
27	203.208.41.94	mainland_ip!	googletagmanager.com
28	--------------	-------------	googletagservices.com
29	203.208.40.94	mainland_ip!	gtm.oasisfeng.com
30	172.217.24.42	overseas_ip!	imasdk.googleapis.com
31	172.217.163.238	overseas_ip!	kh.google.com
32	172.217.161.142	overseas_ip!	khm.google.com
33	172.217.24.206	overseas_ip!	khm.googleapis.com
34	172.217.161.142	overseas_ip!	khm0.google.com
35	172.217.163.238	overseas_ip!	khm0.googleapis.com
36	172.217.161.142	overseas_ip!	khm1.google.com
37	172.217.161.174	overseas_ip!	khm1.googleapis.com
38	172.217.161.142	overseas_ip!	khm2.google.com
39	216.58.200.78	overseas_ip!	khm2.googleapis.com
40	172.217.161.142	overseas_ip!	khm3.google.com
41	216.58.220.206	overseas_ip!	khm3.googleapis.com
42	172.217.24.78	overseas_ip!	khmdb.google.com
43	216.58.199.14	overseas_ip!	khmdb.googleapis.com
44	64.233.189.100	overseas_ip!	media.admob.com
45	216.58.221.227	overseas_ip!	ocsp.pki.goog
46	172.217.31.225	overseas_ip!	pagead-googlehosted.l.google.com
47	203.208.40.87	mainland_ip!	recaptcha.net
48	216.58.199.110	overseas_ip!	redirector.gvt1.com
49	216.58.200.14	overseas_ip!	safebrowsing-cache.google.com
50	172.217.31.234	overseas_ip!	safebrowsing.googleapis.com
51	203.208.41.88	mainland_ip!	settings.crashlytics.com
52	172.217.161.136	overseas_ip!	ssl-google-analytics.l.google.com
53	216.58.197.99	overseas_ip!	ssl.gstatic.com
54	216.58.199.4	overseas_ip!	toolbarqueries.google.com
55	216.58.221.227	overseas_ip!	tools.google.com
56	216.58.221.227	overseas_ip!	tools.l.google.com
57	216.58.197.106	overseas_ip!	translate.googleapis.com
58	216.58.200.3	overseas_ip!	update.googleapis.com
59	203.208.40.94	mainland_ip!	www-googletagmanager.l.google.com
60	172.217.161.131	overseas_ip!	www.gstatic.com

------------------------------------------------------------------------
总共尝试了60个域名，耗时11秒
57个域名得到了解析，3个域名解析失败！
解析到大陆的12个，解析到海外的45个
------------------------------------------------------------------------

结果是很多域名都被解析到了国外，原因当然是因为这些域名和gfwlist的匹配

2. 非-g模式下：

运行命令：chinadns-ng -l 7913 -t 127.0.0.1#1055
设置详情：同上，去除-g选项

1	203.208.40.88	mainland_ip!	265.com
2	--------------	-------------	2mdn.net
3	203.208.41.90	mainland_ip!	adservice.google.com
4	203.208.40.100	mainland_ip!	app-measurement.com
5	203.208.41.88	mainland_ip!	beacons.gcp.gvt2.com
6	203.208.40.120	mainland_ip!	beacons.gvt2.com
7	203.208.41.120	mainland_ip!	beacons3.gvt2.com
8	203.208.41.122	mainland_ip!	c.admob.com
9	--------------	-------------	c.android.clients.google.com
10	203.208.40.98	mainland_ip!	cache.pack.google.com
11	203.208.41.63	mainland_ip!	cdn.ampproject.org
12	203.208.40.119	mainland_ip!	checkin.gstatic.com
13	203.208.41.37	mainland_ip!	clickserve.dartsearch.net
14	203.208.41.127	mainland_ip!	clientservices.googleapis.com
15	203.208.41.88	mainland_ip!	connectivitycheck.gstatic.com
16	203.208.40.127	mainland_ip!	crl.pki.goog
17	203.208.41.87	mainland_ip!	csi.gstatic.com
18	203.208.41.66	mainland_ip!	dl.google.com
19	203.208.41.78	mainland_ip!	dl.l.google.com
20	216.58.221.238	overseas_ip!	doubleclick.net
21	203.208.41.98	mainland_ip!	fonts.googleapis.com
22	203.208.40.111	mainland_ip!	fonts.gstatic.com
23	172.217.161.132	overseas_ip!	google-analytics.com
24	203.208.41.122	mainland_ip!	googleadservices.com
25	172.217.161.164	overseas_ip!	googleanalytics.com
26	216.58.199.4	overseas_ip!	googlesyndication.com
27	203.208.41.94	mainland_ip!	googletagmanager.com
28	--------------	-------------	googletagservices.com
29	203.208.40.94	mainland_ip!	gtm.oasisfeng.com
30	203.208.40.98	mainland_ip!	imasdk.googleapis.com
31	203.208.41.99	mainland_ip!	kh.google.com
32	203.208.40.71	mainland_ip!	khm.google.com
33	203.208.40.35	mainland_ip!	khm.googleapis.com
34	203.208.40.66	mainland_ip!	khm0.google.com
35	203.208.40.110	mainland_ip!	khm0.googleapis.com
36	203.208.40.72	mainland_ip!	khm1.google.com
37	203.208.41.37	mainland_ip!	khm1.googleapis.com
38	203.208.40.64	mainland_ip!	khm2.google.com
39	203.208.41.40	mainland_ip!	khm2.googleapis.com
40	203.208.40.71	mainland_ip!	khm3.google.com
41	203.208.40.35	mainland_ip!	khm3.googleapis.com
42	--------------	-------------	khmdb.google.com
43	203.208.41.78	mainland_ip!	khmdb.googleapis.com
44	64.233.189.139	overseas_ip!	media.admob.com
45	203.208.41.119	mainland_ip!	ocsp.pki.goog
46	203.208.40.107	mainland_ip!	pagead-googlehosted.l.google.com
47	203.208.40.88	mainland_ip!	recaptcha.net
48	203.208.40.41	mainland_ip!	redirector.gvt1.com
49	203.208.40.46	mainland_ip!	safebrowsing-cache.google.com
50	203.208.41.71	mainland_ip!	safebrowsing.googleapis.com
51	203.208.41.87	mainland_ip!	settings.crashlytics.com
52	203.208.41.94	mainland_ip!	ssl-google-analytics.l.google.com
53	203.208.40.56	mainland_ip!	ssl.gstatic.com
54	203.208.41.83	mainland_ip!	toolbarqueries.google.com
55	203.208.40.87	mainland_ip!	tools.google.com
56	203.208.40.79	mainland_ip!	tools.l.google.com
57	203.208.40.35	mainland_ip!	translate.googleapis.com
58	203.208.40.63	mainland_ip!	update.googleapis.com
59	203.208.40.94	mainland_ip!	www-googletagmanager.l.google.com
60	203.208.40.47	mainland_ip!	www.gstatic.com

------------------------------------------------------------------------
总共尝试了60个域名，耗时13秒
56个域名得到了解析，4个域名解析失败！
解析到大陆的51个，解析到海外的5个
------------------------------------------------------------------------

结果更多的域名得到了国内解析，不过还不能达到完美，还有5个地址被解析到国外。

3. 域名白名单功能 feature request

  • 请作者考虑是否可以添加-m, --mainland-file 功能，起域名白名单功能，-m里指定的域名强制使用国内DNS解析，并且优先级高于-g，这样在-g + -m模式下，诸如clientservices.googleapis.com这样的域名就不会解析到国外去了。
  • 另外，dnsmasq-china-list项目项目里，还有整理超过6万条使用国内DNS解析加速的域名列表：accelerated-domains.china.conf，如果有域名白名单功能，那么这份列表就能能用chinadns-ng了，得益于chinadns-ng高效的hash查询方式，运行起来应该没有问题。如果使用遍历查询的dnsmasq来实现，查询速度大大折扣不说，cpu占用率还超高。

[ipset_addr4_is_exists] received an error code from kernel: (-1)

Hi, 我遇到了一些问题，按照readme的提示，安装完简单测试的时候会出现下面的错误提示

2020-01-03 23:52:38 ERR: [ipset_addr4_is_exists] received an error code from kernel: (-1) Operation not permitted
2020-01-03 23:52:52 ERR: [ipset_addr6_is_exists] received an error code from kernel: (-1) Operation not permitted

启动程序的命令
chinadns-ng -l 1314 -t 8.8.8.8#53 -g ~/Downloads/chinadns-ng-master/gfwlist.txt
测试:
dig @127.0.0.1 -p1314 www.google.com
测试结果:

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> @127.0.0.1 -p1314 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63019
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.google.com.			IN	A

;; ANSWER SECTION:
www.google.com.		148	IN	A	172.217.160.68

;; Query time: 69 msec
;; SERVER: 127.0.0.1#1314(127.0.0.1)
;; WHEN: Fri Jan 03 23:52:38 HKT 2020
;; MSG SIZE  rcvd: 59

也测了百度，测试结果好像没什么问题，但是控制台那里每发出一次查询就会出现上边的错误提示，
希望有空帮忙看看，不胜感激

目前两个模式的逻辑疑似存在问题

我用的是电信网，有公网IPv4，也有原生双栈的支持，但因一些原因，我改用6in4作为IPv6地址。
我将您的这个项目布置在刷了openwrt的路由器上，用了一段时间，感觉没有任何问题。
然而好景不长，目前我发现了您的这个项目存在逻辑问题：当国内DNS返回国内网站的IPv6地址查询结果为空时，会将从国外DNS的IPv6地址查询结果混进来，并可能因此导致访问体验劣化

图一 我再路由器的5453口部署了stubby并直接使用了DoT来进行DNS查询，图一是只从那个端口进行dig的结果.

图二 我再直接向114DNS进行dig查询，显而易见的是没有IPv6结果的.

图三 那我再向路由器进行nslookup查询会如何？图三就是结果

图四 这是我在用的配置，免得又说无图言O之类的

我只想说目前的逻辑看起来存在没有细分IPv4和IPv6结果的逻辑问题，还望改进

OpenWRT 上编译错误

root@OpenWrt:~/chinadns-ng# make gcc -std=c99 -Wall -Wextra -O3 -c chinadns.c -o chinadns.o chinadns.c: In function 'parse_command_args': chinadns.c:210:42: error: 'PATH_MAX' undeclared (first use in this function) if (strlen(optarg) + 1 > PATH_MAX) { ^ chinadns.c:210:42: note: each undeclared identifier is reported only once for each function it appears in make: *** [Makefile:23: chinadns.o] Error 1

chinadns.c 里加了 #include <linux/limits.h> 就通过了

讨论：一个关于国内、可信dns返回的处理的逻辑问题

当可信dns先返回，如果是国内ip，则结束此次回话，直接以这个国内ip作为标准。这里一个问题是，可能一些网站，国外解析线路都会解析到沿海（比如广东移动），来加速国外访问，这时候如果我是联通，可能访问就炸了。

what will happen if china-dns return 127.0.0.1

In the README, it was said that "if a result from china-dns is in ipset CHNRoute, we use that result, and ignore any other results", while in "chnroute.ipset", 127.0.0.1/8 is included;
so, if china-dns return 127.0.0.1 for sites like google.com, chinadns-ng will use that result too?

关于trust-dns 的问题

trust-dns 可以为本地的dnscrypt-proxy么？
我看readme里说访问可信DNS必须经过代理，不过我这里的trust-dns 是本地的dnscrypt-proxy（127.0.0.1:5753），应该是可以的吧？ 多谢！

macOS support 

gcc -std=c99 -Wall -Wextra -O3 -c chinadns.c -o chinadns.o
gcc -std=c99 -Wall -Wextra -O3 -c dnsutils.c -o dnsutils.o
gcc -std=c99 -Wall -Wextra -O3 -c dnlutils.c -o dnlutils.o
gcc -std=c99 -Wall -Wextra -O3 -c maputils.c -o maputils.o
gcc -std=c99 -Wall -Wextra -O3 -c netutils.c -o netutils.o
netutils.c:12:10: fatal error: chinadns.c:20:'sys/timerfd.h'10: fatal error: 'sys/epoll.h' file not found
 file not found
#include <sys/timerfd.h>
         ^~~~~~~~~~~~~~~
#include <sys/epoll.h>
         ^~~~~~~~~~~~~
1 error generated1.
 error generated.
make: *** [netutils.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [chinadns.o] Error 1

It seems macOS should use kqueue instead.

设置两个国内DNS或两个可信DNS时，其中一个DNS不可用可能导致查询失败

作者你好，

想请教下，当设置两个国内DNS和两个可信DNS时，当其中一个国内DNS或其中一个可信DNS不可用时（e.g. 国内DoH服务器故障，或可信DNS走的代理失效），有时候会导致ChinaDNS-ng timeout无法给出结果。我想知道查询的逻辑是同时查询两个DNS，还是会先查询第一个，如果失效再查询第二个呢？看log感觉似乎是前者，但不太理解为何有时把失效的DNS放在第二个时又能给出结果。

谢谢！

功能请求：提供未命中黑白名单的查询结果的更多处理方式

按照目前文档的描述，无论如何设置，最终都会判断上游 dns 的返回 IP 是否为国内的，如果不为国内的 IP 就会丢弃 china-dns 的结果，只使用上游 trus-dns 的返回结果。

如果说我 trus-dns 的查询是走代理的，一些未被污染的国外域名且未被墙的（其 IP 非国内）查询到的结果最终也是通过代理查询到的，其返回的 IP 地址对代理服务器是最优的，然而对于我本地来说却可能不是最优的。

基于此，希望能提供一个选项来提供未命中黑白名单的查询结果的更多处理方式。如：

  1. 未命中黑白名单的请求结果判断其 IP 是否命中 chnroute， 如果命中使用 china-dns 的结果，负责使用 trus-dns 的结果
  2. 未命中黑白名单的请求结果统一使用 china-dns 的结果
  3. 未命中黑白名单的请求结果统一使用 trus-dns 的结果
  4. 未命中黑白名单的请求结果使用 china-dns 和 trus-dns 最先返回的结果

请问gfwlist是否可以只解析ipv4？

我不会设置ipv6分流规则，好像路由的ip6tables也不支持nat，同时，我有pt需要，不能禁用ipv6。

所以希望gfwlist只解析ipv4，不知道该如何设置？还是默认就可以不需要设置？

谢谢。

最新的commit 在 CentOS7上编译失败

Makefile:22: *** mixed implicit and static pattern rules. Stop.

然后我把第22行改成 .c.o:
编译成功

gcc -std=c99 -Wall -Wextra -O2 -c chinadns.c -o chinadns.o
gcc -std=c99 -Wall -Wextra -O2 -c dnsutils.c -o dnsutils.o
gcc -std=c99 -Wall -Wextra -O2 -c dnlutils.c -o dnlutils.o
gcc -std=c99 -Wall -Wextra -O2 -c maputils.c -o maputils.o
gcc -std=c99 -Wall -Wextra -O2 -c netutils.c -o netutils.o
gcc -std=c99 -Wall -Wextra -O2 -s -o chinadns-ng chinadns.o dnsutils.o dnlutils.o maputils.o netutils.o

查询一些特定的域名有问题？

查询一些特定的域名，比如 scontent-sin6-2.cdninstagram.com, scontent-lax3-2.cdninstagram.com 等（浏览器打开 instagram.com 就能重现），国内 DNS 是查不到结果的，而国外 DNS 却可以查到结果。

按照目前的逻辑，只能等到超时，在这种情况下非常的慢。以下是我的启动命令和日志，可以看出，从发起请求到得到结果耗时 8 秒。而 ChinaDNS 原版的逻辑是直接采用可信 DNS 的结果，那样虽然很快，但是却没有了线路优化的效果，前几个 issue 提到过。

我想能不能优化一下这种情况？
比如（加一个 --fast 选项？）或者把逻辑改成，当国内 DNS 超过 200ms 没有响应时，直接采用可信 DNS 的结果？
EDIT:
似乎没有比较好的方式...？

# server
chinadns-ng -b 0.0.0.0 -l 5354 -c 114.114.114.114 -t 127.0.0.1#5300 -4 chnroute -6 chnroute6 -o 3 -v

# client
dig scontent-sin6-2.cdninstagram.com @192.168.1.1 -p 5354

# log
2019-08-30 03:44:03 INF: [handle_local_packet] query [scontent-sin6-2.cdninstagram.com] from 192.168.1.107#54729
2019-08-30 03:44:03 INF: [handle_remote_packet] reply [scontent-sin6-2.cdninstagram.com] from 127.0.0.1#5300, result: delay
2019-08-30 03:44:06 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 35
2019-08-30 03:44:07 INF: [handle_local_packet] query [scontent-sin6-2.cdninstagram.com] from 192.168.1.107#54729
2019-08-30 03:44:07 INF: [handle_remote_packet] reply [scontent-sin6-2.cdninstagram.com] from 127.0.0.1#5300, result: delay
2019-08-30 03:44:10 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 36
2019-08-30 03:44:10 INF: [handle_local_packet] query [scontent-sin6-2.cdninstagram.com] from 192.168.1.107#54729
2019-08-30 03:44:10 ERR: [dns_rheader_check] the response code not equal to RCODE_NOERROR
2019-08-30 03:44:10 INF: [handle_remote_packet] reply [scontent-sin6-2.cdninstagram.com] from 114.114.114.114#53, result: filter
2019-08-30 03:44:10 ERR: [dns_rheader_check] the response code not equal to RCODE_NOERROR
2019-08-30 03:44:10 INF: [handle_remote_packet] reply [scontent-sin6-2.cdninstagram.com] from 114.114.114.114#53, result: ignore
2019-08-30 03:44:10 ERR: [dns_rheader_check] the response code not equal to RCODE_NOERROR
2019-08-30 03:44:10 INF: [handle_remote_packet] reply [scontent-sin6-2.cdninstagram.com] from 114.114.114.114#53, result: ignore
2019-08-30 03:44:11 INF: [handle_remote_packet] reply [scontent-sin6-2.cdninstagram.com] from 127.0.0.1#5300, result: accept

顺便问下，日志里的 [dns_rheader_check] the response code not equal to RCODE_NOERROR 是怎么回事？

使用Alpine镜像编译报错 error: unknown type name 'time_t'; did you mean 'size_t'?

报错信息如下

/chinadns-ng # make
gcc -std=c99 -Wall -Wextra -O3 -c chinadns.c -o chinadns.o
gcc -std=c99 -Wall -Wextra -O3 -c dnsutils.c -o dnsutils.o
gcc -std=c99 -Wall -Wextra -O3 -c maputils.c -o maputils.o
In file included from maputils.h:6,
                 from maputils.c:2:
netutils.h:43:22: error: unknown type name 'time_t'; did you mean 'size_t'?
 int new_once_timerfd(time_t second);
                      ^~~~~~
                      size_t
make: *** [Makefile:23: maputils.o] Error 1
/chinadns-ng # cat /etc/os-release 
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.9.3
PRETTY_NAME="Alpine Linux v3.9"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"
/chinadns-ng #

编译过程使用的命令

docker run -it --rm alpine sh

sed -i 's/dl-cdn.alpinelinux.org/mirrors.huaweicloud.com/g' /etc/apk/repositories

apk add build-base git

git clone https://github.com/zfl9/chinadns-ng

cd chinadns-ng

make # 这步报错

make install

抢答模式感觉有问题

启动脚本：chinadns-ng -b 127.0.0.1 -l 6333 -c 114.114.114.114 -t 8.8.8.9#535 -v
然后用 nslookup www.baidu.com 127.0.0.1#6333

可以明显感觉到解析域名要卡两秒钟。
按抢答模式的理解是，即使可信DNS配置不正确或各种原因连不上，
收到国内DNS响应并且是国内IP，就应该返回解析结果了。

卡两秒的感觉是在等待可信DNS。

alpine编译报错

你好，我在使用alpine编译时报错，错误信息如下：

alpine:~/chinadns-ng# make
gcc -std=c99 -Wall -Wextra -O3 -c chinadns.c -o chinadns.o
In file included from chinadns.h:6,
                 from chinadns.c:2:
netutils.h:5:10: fatal error: time.h: No such file or directory
 #include <time.h>
          ^~~~~~~~
compilation terminated.
make: *** [Makefile:23: chinadns.o] Error 1
alpine:~/chinadns-ng# uname -a
Linux alpine 5.4.5-0-lts

希望可以解决一下。

默认延时的问题

不知道是不是我部署的问题，我用默认参数延时为5的时候，老是出问题，很多时候返回被污染的数据，手动用-o 10 设成10秒之后，基本没任何问题了，但是其实不可能有这么大延时啊，解析很快的，就算是5秒也应该绰绰有余了，很奇怪。

upstream dns server reply timeout

2020-03-14 15:28:49 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 12916
2020-03-14 15:28:51 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 12918
2020-03-14 15:28:51 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 12919
2020-03-14 15:28:51 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 12920
2020-03-14 15:28:51 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 12921
2020-03-14 15:28:52 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 12922
2020-03-14 15:28:53 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 12923
2020-03-14 15:28:53 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 12924
2020-03-14 15:28:55 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 12925
2020-03-14 15:29:04 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 12927

日志有非常多的报错，提示上游dns服务器replay超时，但是我测试是没有问题的，不知道这个超时的机制是如何判断的，或者能否修改超时的判断和时延。多谢！

使用时报错

root@Mashiro:/ovo# chinadns-ng -l 7913 -c 127.0.0.1#53 -t 127.0.0.1#7053 -g /var/etc/passwall/gfwlist.txt
2020-06-07 22:47:06 INF: [main] local listen addr: 127.0.0.1#7913
2020-06-07 22:47:06 INF: [main] chinadns server#1: 127.0.0.1#53
2020-06-07 22:47:06 INF: [main] trustdns server#1: 127.0.0.1#7053
2020-06-07 22:47:06 INF: [main] ipset ip4 setname: chnroute
2020-06-07 22:47:06 INF: [main] ipset ip6 setname: chnroute6
2020-06-07 22:47:06 INF: [main] dns query timeout: 5 seconds
2020-06-07 22:47:06 INF: [main] gfwlist entries count: 5499
2020-06-07 22:47:06 INF: [main] filter reply without ip addr
2020-06-07 22:47:06 INF: [main] cur judgment mode: fast mode
2020-06-07 22:47:08 ERR: [new_once_timerfd] failed to create timer fd: (24) No file descriptors available

请问这个怎么解决

Windows 10 WSL问题，Protocol not supported

如下，ipset出现了奇怪的错误，反而是老版chinadns能用，但是它又不能过滤AAAA的查询。

:~/chinadns-ng$ sudo ./chinadns-ng -c 114.114.114.114,223.5.5.5 -t 208.67.222.222#5353,208.67.220.
220#5353
2020-05-19 11:20:26 INF: [main] local listen addr: 127.0.0.1#65353
2020-05-19 11:20:26 INF: [main] chinadns server#1: 114.114.114.114#53
2020-05-19 11:20:26 INF: [main] chinadns server#2: 223.5.5.5#53
2020-05-19 11:20:26 INF: [main] trustdns server#1: 208.67.222.222#5353
2020-05-19 11:20:26 INF: [main] trustdns server#2: 208.67.220.220#5353
2020-05-19 11:20:26 INF: [main] ipset ip4 setname: chnroute
2020-05-19 11:20:26 INF: [main] ipset ip6 setname: chnroute6
2020-05-19 11:20:26 INF: [main] dns query timeout: 5 seconds
2020-05-19 11:20:26 INF: [main] filter reply without ip addr
2020-05-19 11:20:26 INF: [main] cur judgment mode: fast mode
2020-05-19 11:20:26 ERR: [ipset_create_nlsocket] failed to create netlink socket: (93) Protocol not supported

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.