功能请求：支持 EDNS Client Subnet (ECS) about chinadns-ng

[zfl9]

那先这样吧，后续继续观察，有其他情况再讨论。先关了哈。

[zfl9]

我觉得不用过于担心这个，我现在并不是很想在 chinadns-ng 中匹配域名列表，后续有时间我再研究研究吧。或许等到国庆假期？哈哈说不定。

[zfl9]

但愿能够 O(1) 的复杂度，其实我也是编程新手。

[zfl9]

ECS我觉得没有太大的意义。在你的应用中，ECS扮演什么作用？如果是这个：

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

那我觉得没有必要搞什么 ECS，因为走了代理的8.8.8.8解析出来的ip就是离vps最近的。另外走直连的114.114.114.114/119.29.29.29 这些解析出来的ip也是离本地位置最近的。所以。。。

[zfl9]

ECS主要的应用场景是，【dns请求客户端】与【递归dns服务器】在不同的区域（ip段不同），比如你本地网是上海电信，你使用的dns递归服务器却在北京电信。

[zfl9]

但是在 chinadns-ng 的应用场景中，上述情况是不存在的（当然如果用户硬要这么皮，我也没办法），而且国内环境大家都懂，自建dns等于找死，很快就会有人找上门。

[pexcn]

我这里通过 114.114.114.114/119.29.29.29 有时候不是得到最近的结果的，我在南方，有时候解析 qq.com/baidu.com 得到了北方的 IP...

但是在 chinadns-ng 的应用场景中，上述情况是不存在的（当然如果用户硬要这么皮，我也没办法），而且国内环境大家都懂，自建dns等于找死，很快就会有人找上门。

不是指自建 DNS 的意思，是指大概像 https://github.com/GangZhuo/CleanDNS 这样的 EDNS 功能

[zfl9]

可是有没有想过，本地ip是会变的。这种你怎么处理，我总觉得这没有太大的价值。

[zfl9]

而且国内现在好像没几个支持 ECS 请求的吧。没具体测试过。

[pexcn]

可是有没有想过，本地ip是会变的。这种你怎么处理，我总觉得这没有太大的价值。

但是运营商也不会经常换... 假如用上海电信，只要随便填一个上海电信的 IP 就行了，是不是自己的 IP 好像问题也不大

而且国内现在好像没几个支持 ECS 请求的吧。没具体测试过。

我以前用的时候 119.29.29.29 是支持的

[zfl9]

你测试过，指定subnet之后公共dns返回的就是准确的了（离得最近）？看上面的讨论，我觉得这个 ecs 选项仅对国内 dns 有点点用。8.8.8.8那边都不用关心。

[zfl9]

但是运营商也不会经常换... 假如用上海电信，只要随便填一个上海电信的 IP 就行了，是不是自己的 IP 好像问题也不大

好像也是这么回事，那行吧。明天或者什么时候加个 ecs 选项。

[pexcn]

几个月前玩 https://github.com/GangZhuo/CleanDNS 的时候测试过很多域名，准确，至少在同一个市了。
但是我刚刚测 119.29.29.29 的时候发现随便指定一个国内的 IP 会卡住很久，然后得不到结果，重试很多次才有一次得到结果，难道是因为这个原因：https://ephen.me/2017/PublicDns_2/ ？

ECS 的弊端

访问网站时的解析时间将可能增加

我们知道，DNS 是有逐级缓存的。我们常常访问的网站大多可以直接从本地 DNS 缓存中读取解析结果，只有当我们是整个区域及运营商中访问某个冷门站点的第一个用户，才会最终到权威 DNS 上去查询站点的解析结果。这时候解析时间会远高于访问热门站点。（不懂的话，再去温习一下《从理论到实践，全方位认识DNS（理论篇）》

如果 DNS 查询请求使用包含 ECS 信息（比如 192.168.1.0/24 ），那么 DNS 响应会返回一个 /0，即为每个人缓存。这代表每个子网的缓存结果都是独立的，如果你的子网中过去从未有人使用支持 EDNS 的本地 DNS 访问过某个网站，这意味着你将从头走一遍域名解析。

[zfl9]

不太清楚，感觉国内没有几个能完整支持edns的subnet（即使支持很多也是半残废）。update: 不知道是不是因为我这边的dns请求被运营商给劫持了。dig 119.29.29.29 带 ecs 信息的查询根本没有正常返回，dig 114.114.114.114 带 ecs 信息的查询倒是正常返回了，不过任由你指定什么 subnet，都是一样的解析结果。。

[pexcn]

不太清楚，感觉国内没有几个能完整支持edns的subnet（即使支持很多也是半残废）。

会不会是这个问题？: ustclug/discussions#45 (comment)
或许可以试试 8.8.8.8, 但是它不在 chnroute 列表之中，现在的版本能不能 --china-dns 8.8.8.8 这样？

[zfl9]

现在的版本能不能 --china-dns 8.8.8.8 这样？

当然是可以的，没有任何隐含的内部规则阻止你这么做。

[pexcn]

如果是支持 ECS, dig 的时候应该会有这种返回结果吧？

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; CLIENT-SUBNET: <IP 地址>/32/24
; COOKIE: 4ea5a169654d8ad9 (echoed)
;; QUESTION SECTION:
;www.baidu.com.                 IN      A

[zfl9]

是的

[pexcn]

不知道是不是因为我这边的dns请求被运营商给劫持了。dig 119.29.29.29 带 ecs 信息的查询根本没有正常返回，dig 114.114.114.114 带 ecs 信息的查询倒是正常返回了，不过任由你指定什么 subnet，都是一样的解析结果。。

我这里的 8.8.8.8 也被劫持了，测了一遍只有 119.29.29.29 能正常使用 EDNS...

[pexcn]

我有一个问题，如果使用 chinadns-ng 经常查询 google.com, youtube.com 等网站，因为它是同时向两个 DNS 发送请求的，会不会被国内 DNS 所记录？

[pexcn]

最好是能支持**特色社会主义 DNS 查询... 比如加一个"前置域名列表"？把 gfwlist 的域名导入进去，chinadns-ng 碰到这些域名就直接采用可信 DNS 查询。这样安全多了...

[zfl9]

我有一个问题，如果使用 chinadns-ng 经常查询 google.com, youtube.com 等网站，因为它是同时向两个 DNS 发送请求的，会不会被国内 DNS 所记录，从而判断你天天翻墙，有可能被请喝茶？

理论上是完全可以的，但是嘛，我觉得也不用太过担心，真等到这么严峻的时候再说吧。

最好是能支持**特色社会主义 DNS 查询... 比如加一个"前置域名列表"？把 gfwlist 的域名导入进去，chinadns-ng 碰到这些域名就直接采用可信 DNS 查询。这样安全多了...

这其实就是 dnsmasq + gfwlist-list 的方式，只是我个人觉得这种 gfwlist 长列表匹配的性能不是很好，好像现在主流且可行的两种防污染方式就是：1、chinadns 这种，基于 IP 地址的。2、dnsmasq 这种基于domain-name list的。它们各有所长，也各有不足。

[pexcn]

我暂时是用 dnsmasq 把 gfwlist 列表里的域名强制用可信 DNS 解析，但是如果加上 EDNS 功能，gfwlist 列表里的域名就会失去效果… (有一次美国西海岸的 VPS 用 8.8.8.8 解析 github.com IP 到了华盛顿去了…)

dnsmasq 在我 ar9341 cpu 的路由器上即使加载了几百 kb 的 (加上去广告之类的) 域名列表，也没感觉慢… 但是据说是线性查表？

[zfl9]

嗯，当然这两种方式我都用过，实际体验没区别。应该是 dnsmasq 对域名匹配优化过。

[zfl9]

那既然如此，ecs 新功能就不需要了？

[pexcn]

不不，我的意思是如果要添加 EDNS 支持，那么最好也加一个前置列表功能😅

[zfl9]

gfwlist 域名匹配不是可以由 dnsmasq 来做吗，集成到 chinadns-ng 有什么用处？

[pexcn]

让 dnsmasq 强制把 gfwlist 的域名让可信 DNS 解析会失去 EDNS 功能…

EDIT:
如果经过 chinadns-ng 就不一样了

[zfl9]

可是国外 dns（8.8.8.8这种），也没有必要指定 subnet 吧，解析到的结果本应该就是离 vps 机房最近的啊

[pexcn]

但是我发现有一次美国西海岸的 VPS 用 8.8.8.8 解析 github.com, 解析出来的 IP 的归属地是华盛顿的…

不知道这种情况是常态还是偶然？

[zfl9]

至少我自己这边的情况是这样的，绝大多数公共 dns 服务器都是有 anycast 任播技术的吧。8.8.8.8 更应该如此才对。

[pexcn]

那次是在 vps 上 ping 得到 github.com 的 IP 也是西海岸，但是通过 ss-tunnel 转发 8.8.8.8 作为可信 DNS, dig 可信 DNS 得到的 IP 有时候会不一样…

[zfl9]

判断ip归属地？你怎么判断的？也许是它的数据库不准，这种情况其实也很常见的吧。ping 的时候能感受到延迟不对？

[pexcn]

我通过 ip-api.com ，那时候忘记 ping 看看了…😌

[pexcn]

我通过 ip-api.com ，那时候忘记 ping 看看了…😌

刚刚试了一次，复现了（192.168.1.1:5300 是 ss-tunnel 转发 8.8.8.8）：

# 这是本地
C:\Users\Administrator\Desktop>dig github.com @192.168.1.1 -p 5300

; <<>> DiG 9.14.1 <<>> github.com @192.168.1.1 -p 5300
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48377
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
github.com.             59      IN      A       192.30.255.112

;; Query time: 570 msec
;; SERVER: 192.168.1.1#5300(192.168.1.1)
;; WHEN: Sat Sep 14 20:21:46 **标准时间 2019
;; MSG SIZE  rcvd: 55

# 这是 VPS
root@CN2:~# ping 192.30.255.112
PING 192.30.255.112 (192.30.255.112) 56(84) bytes of data.
64 bytes from 192.30.255.112: icmp_seq=1 ttl=56 time=26.2 ms
64 bytes from 192.30.255.112: icmp_seq=2 ttl=56 time=26.1 ms
64 bytes from 192.30.255.112: icmp_seq=3 ttl=56 time=26.1 ms
64 bytes from 192.30.255.112: icmp_seq=4 ttl=56 time=26.1 ms
64 bytes from 192.30.255.112: icmp_seq=5 ttl=56 time=26.1 ms
^C
--- 192.30.255.112 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 26.159/26.181/26.201/0.178 ms

EDIT:
这次的是西雅图？VPS 是洛杉矶的，难道 github.com 在洛杉矶没 CDN？

[zfl9]

什么复现了，没看明白。

[zfl9]

我通过 ip-api.com ，那时候忘记 ping 看看了…😌

刚刚试了一次，复现了（192.168.1.1:5300 是 ss-tunnel 转发 8.8.8.8）：

# 这是本地
C:\Users\Administrator\Desktop>dig github.com @192.168.1.1 -p 5300

; <<>> DiG 9.14.1 <<>> github.com @192.168.1.1 -p 5300
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48377
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
github.com.             59      IN      A       192.30.255.112

;; Query time: 570 msec
;; SERVER: 192.168.1.1#5300(192.168.1.1)
;; WHEN: Sat Sep 14 20:21:46 **标准时间 2019
;; MSG SIZE  rcvd: 55

# 这是 VPS
root@CN2:~# ping 192.30.255.112
PING 192.30.255.112 (192.30.255.112) 56(84) bytes of data.
64 bytes from 192.30.255.112: icmp_seq=1 ttl=56 time=26.2 ms
64 bytes from 192.30.255.112: icmp_seq=2 ttl=56 time=26.1 ms
64 bytes from 192.30.255.112: icmp_seq=3 ttl=56 time=26.1 ms
64 bytes from 192.30.255.112: icmp_seq=4 ttl=56 time=26.1 ms
64 bytes from 192.30.255.112: icmp_seq=5 ttl=56 time=26.1 ms
^C
--- 192.30.255.112 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 26.159/26.181/26.201/0.178 ms

EDIT:
这次的是西雅图？VPS 是洛杉矶的，难道 github.com 在洛杉矶没 CDN？

在vps上 ping github.com 呢，每次的延迟是否差不多。解析出来的 ip 应该有多个吧

[zfl9]

然后你自己带上 subnet 选项，在 vps 上 dig，什么结果？我感觉应该没什么差别。

[pexcn]

什么复现了，没看明白。

刚刚又通过 3 个西海岸的 VPS ping github.com, 可能是 github.com 在洛杉矶没有 CDN, 出来的 IP 都是华盛顿州西雅图，可能是上次看错成华盛顿特区，我的错...

[zfl9]

那么这个新功能就没有什么用处了吧？

[pexcn]

然后你自己带上 subnet 选项，在 vps 上 dig，什么结果？我感觉应该没什么差别。

又测了几遍，结果准确，本地 dig github.com 会得到新加坡的 IP.

那么这个新功能就没有什么用处了吧？

主要是国内 DNS 不准确，刚才说前置列表那个问题是因为想尽量用到 EDNS 完善一点...
在您的那边测下这堆域名？看看用国内的 DNS 能否得到最接近的结果？

baidu.com
www.baidu.com
qq.com
www.qq.com
taobao.com
www.taobao.com
163.com
www.163.com
alipay.com
www.alipay.com

[zfl9]

全国各地都有。。。

[pexcn]

全国各地都有。。。

我发现顶级域名似乎都没有 CDN...? www 前缀的才有...

我测试了一遍，dig 用上 EDNS 的结果和不用 EDNS 的结果是一样的，这个功能应该是不需要了，您认为呢？

[zfl9]

北京、广州、天津、杭州、上海。等等都有。

[zfl9]

全国各地都有。。。

我发现顶级域名似乎都没有 CDN...? www 前缀的才有...

我测试了一遍，dig 用上 EDNS 的结果和不用 EDNS 的结果是一样的，这个功能应该是不需要了，您认为呢？

我感觉也差不多，应该是 www 的都是 网站吧，所以才部署了 cdn。

[pexcn]

北京、广州、天津、杭州、上海。

我得到的结果也差不多，可能是因为没有 CDN

[zfl9]

在没有 ecs 之前，其实都好好的。ecs 主要应用场景我感觉还是之前说的：请求客户端与本地解析器在不同的地理位置。

[pexcn]

嗯，即使用上了 ECS 应该也会得到相同的结果。

[pexcn]

最好是能支持**特色社会主义 DNS 查询... 比如加一个"前置域名列表"？把 gfwlist 的域名导入进去，chinadns-ng 碰到这些域名就直接采用可信 DNS 查询。这样安全多了...

还是希望能加这个功能，我目前用 dnsmasq 规则强制把 gfwlist 的域名用可信 DNS 解析，但是这样导致了 gfwlist 里的域名用不上 chinadns-ng 而失去 --repeat-times 4 的效果（我的网络 UDP 丢包...）@zfl9

[pexcn]

嗯嗯，好😄，我现在只能把高频访问的域名在 dnsmasq 的**特色社会主义规则里去掉，从而让它使用 chinadns-ng 了~

gfwlist 的列表有几千条，如果要支持这个功能，是打算用 O(1) 的匹配算法吗？（占用的 RAM 会比较多？）

[pexcn]

😄😄

[rampageX]

完全没必要去支持域名列表，目前这样简洁就很好。

[basncy]

在没有 ecs 之前，其实都好好的。ecs 主要应用场景我感觉还是之前说的：请求客户端与本地解析器在不同的地理位置。

你们有没有把本程序部署在vps上的需求(省掉国内中转)? 方便没有ipset的系统(非linux, 手机, TV, 机顶盒, windows)使用.
场景A: 本地adg缓存 -> chinadns-ng(on vps), 然后app可以使用GEOIP的分流规则.
场景B: chinadns-ng(on vps) -> unbound(部分DNS重写)
PS: 在考虑让旧手机当软路由跑(省电, 性能还强悍).

[zfl9]

但你这样的话，本地->国外vps 这段dns查询路径，会被gfw污染吧？

[basncy]

如何过墙超出本repo范围, 但可以参考:
1.让梯子代理, vps可能需要添加DNAT.
2.走vps上的非标准DoH.

[zfl9]

你这样的话，国内域名解析延迟就比较高了。

而且既然都在本地运行 adg 了，不如在此基础上，在本地挂一个 chnlist.txt 分流，让国内域名走本地DNS（因此不需要ECS），其他域名走 vps 上的 DNS（因此也不需要 ECS）。

比如 chinadns-ng -m chnlist.txt -d gfw -c 本地/国内公共DNS -t VPS上的DNS 不需要 ipset/nftset。

[basncy]

主要是想解决本地DNS挂掉(或关机)时访问国内服务IP离中(送中反义), 顺便只维护一份配置, 由vps统一下发正确DNS. adg缓存只是按需运行,并不是每台设备都方便安装运行.

如果改动比较复杂, 也可以在vps上继续套娃实现. /dog

[zfl9]

哈哈，那就在 vps 上套娃吧，反正也不经常改动 vps 上的东西，多一个组件无所谓。

主要是常规场景下没这个需求（chinadns-ng 基本都运行在用户侧，所以 ECS 没啥用），有点不想搞。

[basncy]

多谢回复. 那继续在vps上套娃, 哈哈.