zfl9 / chinadns-ng Goto Github PK

View Code? Open in Web Editor NEW

978.0 42.0 175.0 2.13 MB

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

License: GNU Affero General Public License v3.0

C 28.22% Shell 0.59% Zig 71.19%

chinadns chinadns-ng ipset netlink ss-tproxy dns gfwlist dnsmasq nftables dot

chinadns-ng's People

Contributors

Stargazers

Watchers

Forkers

rampagex macjiaoluo cqjerry flyarong moecao hollychen503 ctyb cybort bybzmt xrichardp hcm82 hiboyhiboy chinanjh ktgr771 xf22001 looxxp zhaozhejun tournet shawnupup zhanglei yuiosxiao hema84870000 hcym roy63258015 taskiller dorianha edisnat ameykyl kiss2u tangkv fbion beerkala consatan u0225 leepapa bzzjh poplovetorock scolate tabing010102 stamhe yofo-me pexcn-todo meliber taochingchung ryanraw giddily wxma1 dayu2020 xbcyl813 876602818 eamon-cai robbie-cao sangdan daivad michaelscde fyfh ksatera beyond-far asdlei99 xi1314 fastlyos peter-tank liuyaohong888 hncskhkm sharermax expost zhendongjia nnssz nmapleaf crackercat ly19811105 wrtriuwiu anotherfish monokoo flyn0618 davidalphafox cdlaimin hwx929 emacsnt dylu6699 guyezi surichard wpq3142 jedicloudmil aristotlelai asushugo zealass ythyty kevincuidada micseo qfrank living1069 hubing0917 blog2i2j loso3000 setsena yesterday17 packingbox hybtw tulai

chinadns-ng's Issues

received an error code from kernel: (-2) No such file or directory

any tips for me to find the root cause? thanks in advanced!
[ipset_addr4_is_exists] received an error code from kernel: (-2) No such file or directory

当 --repeat-times 参数为负数的时候的 bug

# 当 -p -1 时，日志显示：
2019-09-05 09:31:10 INF: [main] enable repeat mode, times: 255

# 当 -p -2 时，日志显示：
2019-09-05 09:31:13 INF: [main] enable repeat mode, times: 254

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?

默认延时的问题

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

功能请求：支持 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 最近的结果了。

参考

逻辑上的一点儿小疑问

举例

网址：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地址一起都被丢弃了吗？

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

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

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

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

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

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

未命中黑白名单的请求结果判断其 IP 是否命中 chnroute，如果命中使用 china-dns 的结果，负责使用 trus-dns 的结果

未命中黑白名单的请求结果统一使用 china-dns 的结果

未命中黑白名单的请求结果统一使用 trus-dns 的结果

未命中黑白名单的请求结果使用 china-dns 和 trus-dns 最先返回的结果

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

大佬你这个支持DoH?

目前是用的ss-tproxy，所以问问这个chinadns-ng是不是支持DoH?

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!

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占用率还超高。

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

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查询失败，第二次才正常，怎么解决这中问题？

使用时报错

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

请问这个怎么解决

新功能请求：并发请求

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

并发请求，来自这里 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

有俩网址，原版没问题，但是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正常

能否出个docker 版本的chinadns-ng

可否恳请出个docker版本的，多谢!

请求支持ANY查询

命令行选项的问题 / DNS 请求的流程优化

尝试把 chinadns-ng 移植到了 OpenWrt, 参考了 openwrt-chinadns 的代码。但是出现了一个问题，--china-dns 和 --trust-dns 参数的 # 号被忽略了，请问是这个软件本身对 # 号的处理有问题吗？（openwrt-chinadns 没有这个问题）
https://github.com/pexcn/openwrt-chinadns-ng/blob/master/files/chinadns-ng.init#L149-L150

描述得不是很清楚，截了几个图：

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倒是可以绕过

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

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

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

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

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

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

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

[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

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

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

希望可以解决一下。

apps.apple.com 的问题

假如要访问美区的 https://apps.apple.com/us/app/speedtest-by-ookla/id1153157709, chinadns-ng 会返回国内的 IP 的结果，在网页上会显示 404（https://apps.apple.com/us/ 屏蔽了国内的 IP？）。

在 dnsmasq 添加 apps.apple.com 强制让可信 DNS 解析应该可以解决，想问下有没有更好的方法？

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]打印上游DNS的响应时间

在日志中打印上游DNS的响应时间，以便评估上游DNS的延时情况。

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

查询一些特定的域名，比如 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 是怎么回事？

使用ChinaDNS NG作为PSW的DNS模式在访问国外网站时能否通过代理隧道用本地DNS解析域名？

关于trust-dns 的问题

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

抢答模式感觉有问题

启动脚本：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。

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.

想请教一下bind_address是否支持绑定ipv6地址

想请教一下bind_address是否支持绑定ipv6地址，具体格式上需不需要加中括号？

-4 和 -6 参数能否支持完整的路径？

想在 OpenWrt 上面运行，指定那两个文件的完整路径

现在的版本有原版的压缩指针功能吗？

原版的 README: https://github.com/shadowsocks/ChinaDNS#usage 里面说到有个 -m 选项可以开启压缩指针功能。
想问一下，压缩指针的作用是什么？chinadns-ng 有这个功能吗（自带了，默认开启？）？

需求建议

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

交叉编译的文件不能运行

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

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

请教作者

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

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

如何为 arm_cortex-a9_vfpv3 编译此库？

不胜感激涕零

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

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

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

谢谢。

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

作者你好，

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

谢谢！

请求支持 TCP DNS 服务器

因为众所周知的原因国内出境 UDP 流量不是很好，所以希望可以支持 TCP DNS 服务器

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超时，但是我测试是没有问题的，不知道这个超时的机制是如何判断的，或者能否修改超时的判断和时延。多谢！

出错提示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

使用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

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> 就通过了

能否支持原版 ChinaDNS 那种格式的路由表文件？

就像这样的：

# chnroute.txt
1.0.1.0/24
1.0.2.0/23
1.0.8.0/21
1.0.32.0/19
1.1.0.0/24

# chnroute6.txt
2001:250::/35
2001:250:2000::/35
2001:250:4000::/34
2001:250:8000::/33
2001:251::/32

zfl9 / chinadns-ng Goto Github PK

chinadns-ng's People

Contributors

Stargazers

Watchers

Forkers

chinadns-ng's Issues

参考

1. -g模式下：

2. 非-g模式下：

3. 域名白名单功能 feature request

Recommend Projects

Recommend Topics

Recommend Org

1. `-g`模式下：

2. 非`-g`模式下：