记录一下 ChinaDNS 的工作原理和一些 DNS 相关的想法

ChinaDNS Flow.md

ChinaDNS 的工作流程

ChinaDNS 的上游 DNS 分为 国内 DNS 和 可信 DNS。

工作流程

1. ChinaDNS 会同时向上游的 DNS 发送请求。
2. 如果 可信 DNS 先返回，则直接采用 可信 DNS 的结果。
3. 如果 国内 DNS 先返回，分两种情况：如果返回的结果是国内的 IP, 则采用；否则丢弃并转而采用 可信 DNS 的结果。

结论

1. 要确保 国内 DNS 的查询速度要比 可信 DNS 快，才能达到线路优化的效果。
2. 不能在 可信 DNS 下做缓存，否则 可信 DNS 会一直先比 国内 DNS 先返回，达不到线路优化的效果。

更新

2021.04.18

新想法：定期查询 DNS 并缓存的工具，轮询域名列表，查询并缓存其 IP, 允许设置 TTL.

2019.08.14 DNS 请求的流程优化？(TODO: 不会返回被污染的结果？)

希望可以解决当前 ChinaDNS 在可信 DNS 端做缓存而导致达不到线路优化效果的问题。

设置两个上游 DNS，一个国内 DNS，一个可信 DNS（国内自建或者代理转发国外的，是干净的 DNS）。 同时请求，如果任意一个先返回的 DNS 的 IP 是国内 IP，则立即采用； 如果不是国内的 IP，则等待另一个 DNS 返回数据，如果此时返回的 IP 如果是国内 IP，则采用，如果不是国内 IP，也采用可信 DNS 的结果。

同时向两个上游 DNS 查询，如果先获得的响应中的 IP 是国内的，即采用；否则，采用可信 DNS 的。

2019.08.11

最近玩了一下 CleanDNS 和 overture, 看到一些比较好的特性，如果把这些特性搬到 ChinaDNS 上面，那可以总结一下：

1. 先额外准备好以下两个列表：chinalist.txt 中国域名列表、gfwlist.txt 黑名单域名列表。
2. 当接收到请求的时候，先去匹配请求的域名是否在 chinalist 列表里。如果存在，则直接使用 国内 DNS 解析；如果不存在，则去匹配 gfwlist 列表。如果在 gfwlist 里，则直接使用 可信 DNS 解析；如果不存在，则继续当前版本的 ChinaDNS 的解析流程。
3. 添加一个选项以支持 EDNS, 可以分别设置 EDNS 的 subnet 的 IP.
4. 支持缓存查询结果和修改 TTL.
5. 为了防止 UDP 丢包，在请求 DNS 的时候，连续(或者并发？)发送若干次(可自定义，默认不开启这个特性)请求，采用最先返回的结果。

# 看起来太臃肿了，还是用配置文件好...
chinadns \
  -b 0.0.0.0 \
  -p 5353 \
  -c /etc/chinadns_chnroute.txt \
  -m \
  -s 119.29.29.29/113.109.35.70,127.0.0.1:5300/45.78.21.70 \  # 上游 DNS, 格式：DNS/Subnet,DNS/Subnet,..., 当不填写 Subnet 时禁用单个 DNS 的 EDNS.
  -l /etc/chinadns_chinalist.txt \                            # 中国域名列表，不填写时禁用
  -g /etc/chinadns_gfwlist.txt \                              # 黑名单域名列表，不填写时禁用
  --min-ttl 600 \                                             # TTL 超时，不填写时禁用
  --cache-size 1000                                           # 缓存大小，不填写时禁用

参考

• aa65535/openwrt-chinadns#59
• https://cyberloginit.com/2019/04/08/chinadns-code-analysis.html

用了很长时间但一直没弄明白chinadns的控制流程，现在终于明白了，非常感谢分享心得！但为什么可信dns缓存就达不到线路优化呢？

@doublesixwings 很抱歉，github gist 没有提醒，现在才看到。

用了很长时间但一直没弄明白chinadns的控制流程，现在终于明白了，非常感谢分享心得！但为什么可信dns缓存就达不到线路优化呢？

可能是可信DNS一般是绑定本地 127.0.0.1 的，返回的速度始终是最快的

Note: Moved to content.

可信 DNS 在链路上是不是也会存在被 GFW 污染的可能？

可信 DNS 在链路上是不是也会存在被 GFW 污染的可能？

不会，中国大陆以外的地方不存在 GFW. (此处指使用 ss-tunnel 之类的方式转发)

@pexcn 我发现一个有趣的现象
我上游服务器 192.168.1.1,127.0.0.1:12345
第一个DNS是我光猫的地址
第二个转发通过ss转发到谷歌的
用浏览器访问淘宝的是后跳转到了world.taobao.com

@pexcn 我发现一个有趣的现象
我上游服务器 192.168.1.1,127.0.0.1:12345
第一个DNS是我光猫的地址
第二个转发通过ss转发到谷歌的
用浏览器访问淘宝的是后跳转到了world.taobao.com

用的是什么 DNS 工具？看看日志？

@pexcn 我发现一个有趣的现象
我上游服务器 192.168.1.1,127.0.0.1:12345
第一个DNS是我光猫的地址
第二个转发通过ss转发到谷歌的
用浏览器访问淘宝的是后跳转到了world.taobao.com

用的是什么 DNS 工具？看看日志？

CHINA-DNS 我回去试试ng 康康能正常不

@pexcn
是因为我ss对我这台机器开了全局导致的

DNS Flow (ver. 2022 v2) [DEPRECATED]

已弃用，仅作记录

Users -> AdGuard Home (DNS拦截/DNS重写...) -> dnsmasq (提供PTR/Hosts/DHCP...) -> chinadns-ng (DNS分流和线路优化)

                     -> smartdns (测速/dns prefetch/cache...) -> 223.5.5.5/119.29.29.29 -> 强国
chinadns-ng 方案一 ->
                     -> smartdns (测速/dns prefetch/cache...) -> 127.0.0.1:5300 (通过sstunnel转发可信DNS) -> 8.8.8.8 -> 🌐


                     -> smartdns (测速/dns prefetch/cache...) -> 223.5.5.5/119.29.29.29 -> 强国
chinadns-ng 方案二 ->
                     -> smartdns (测速/dns prefetch/cache...) -> 8.8.8.8 (将通过transproxy的UDP代理出去) -> 🌐

DNS Flow (ver. 2023 v1)

仅作记录

[User] -> AdGuard Home (DNS Block/DNS Rewrite) -> dnsmasq (PTR?) -> chinadns-ng (Non-poisoning DNS)

                      -> 223.5.5.5,119.29.29.29 -> [强国]
chinadns-ng plan 1 ->
                      -> 127.0.0.1:5300 (forwarded by sstunnel) -> 8.8.8.8 -> [🌐]


                      -> 223.5.5.5,119.29.29.29 -> [强国]
chinadns-ng plan 2 ->
                      -> 8.8.8.8 (via transproxy udp tproxy) -> [🌐]