ChinaDNS-NG 2.0

[zfl9]

为减少 DNS 工具链的“套娃”，提高 chinadns-ng 的易用性，计划开发 1.0、2.0 版本。

---

1.0 版本要实现的功能 (已完成，见 2024.03.07 版本)：

• 支持 TCP + UDP 监听，尽量符合相关 RFC 规范
• 支持多个监听 IP 地址，方便 IPv4 + IPv6 双栈等用例
• 支持 TCP + UDP 上游，处理方式类似 dnsmasq，但可能会有所增强（如：强制 TCP 上游或 UDP 上游）
• 每个上游组允许配置多个 DNS（超过 2 个），允许混用多个不同协议的 DNS 上游（TCP、UDP）
• 引入配置文件支持，语法类似 dnsmasq，一行一个长选项

---

2.0 版本要实现的功能：

• 支持 DNS 缓存，支持缓存白名单（不被缓存的域名），支持 stale 缓存模式。
• 缓存 tag:none 域名的判定结果，减少不必要的转发/判定，减少 DNS 泄露。
• 支持读取 hosts 文件（本地 A/AAAA 记录），支持定义本地 A/AAAA 记录。
• 考虑支持 DNS over HTTPS 上游（可选的，不带 DoH 的可能称为 lite 版）
• --cache-stale 参数最大值调整，目前最大是 65535（u16），某些情况下不太够
• 允许过滤具有某些 qtype 的查询消息，如 qtype=64/65，用于某些特殊需求 #82
• 必要的 dnsmasq 类似功能（--server、--ipset、定义其他类型的 DNS 记录）
• tcp:// 上游增加 pipeline 长连接支持，目前是采用的是 tcp 短连接 #151
• 支持 DNS over TLS 上游（会发布两种版本，不需要此功能的请选 lite 版）
• add ip to ipset/nftset 时，允许指定 element 级别的 timeout 参数 #155
• 支持定义其他类型的本地 DNS 记录，如 SRV （有需求请单独开 issue）

---

预计将使用单个 chinadns-ng 进程，替代 经典用例 下的 dnsmasq + chinadns-ng + dns2tcp/dnsproxy 组合。

[InspoOnU]

dnsmasq还有一个功能是提供本地PTR查询，可以通过查询DHCP(v6)的租约文件实现

[zfl9]

dnsmasq还有一个功能是提供本地PTR查询，可以通过查询DHCP(v6)的租约文件实现

这个功能涉及到 DHCP 领域，暂不考虑哈。

---

目前来说，我只想在合理的范围内，增加必要的功能。因此，完全取代 dnsmasq 并不是 chinadns-ng 的目的。

[kuyagic]

有没有打算做一个 广告域名的 配置呢?
如果有 我这边可以少一层套娃.

[zfl9]

如果广告域名是类似 gfwlist.txt/chnlist.txt 这样的域名后缀，那么应该很简单。但是如果涉及到正则表达式等模式，那么不会考虑。

我不清楚通过 dns 过滤广告的效果如何，我觉得很多广告都是内嵌到网页里面的，仅在 域名解析 上动手，感觉不是非常理想。我很久之前也折腾过类似的基于 dns 的广告过滤（当然，并不是 AdGuardHome 哈），不过后来我还是用浏览器插件了。

[kuyagic]

如果广告域名是类似 gfwlist.txt/chnlist.txt 这样的域名后缀，那么应该很简单。但是如果涉及到正则表达式等模式，那么不会考虑。

我不清楚通过 dns 过滤广告的效果如何，我觉得很多广告都是内嵌到网页里面的，仅在 域名解析 上动手，感觉不是非常理想。我很久之前也折腾过类似的基于 dns 的广告过滤（当然，并不是 AdGuardHome 哈），不过后来我还是用浏览器插件了。

总之目前我还是插件. dns级别 需求其实不是非常高 多谢解答

[cattyhouse]

有没有打算做一个 广告域名的 配置呢? 如果有 我这边可以少一层套娃.

Unix philosophy: Write programs that do one thing and do it well , 广告过滤交给其他专业软件吧, DNS 级别的广告过滤基本上没什么太大用处, 很多都无法过滤, 比如 youtube 广告, AdguardHome 都对此无能为力, 还得靠浏览器插件.

[muziling]

碰到 了一个见鬼的域名s5.m3u8.cool，dig显示huaweicloud，只能附加部分国家的ecs才能解析出地址，比如cloudcone就解析不到IP，oracle韩国可以， oracle美国好像不行。
类似这种：https://ping.chinaz.com/r2.hfyrw.com ，内地可以，外网反而有部分解析不到

chinadns-ng 2.0 会有这功能吗？ 目前只有mosdns能满足需求

可能部分用户还有另一个需求，就是腾讯的域名用腾讯的DNS解析，解决微信转圈的问题

如果替代dnsmasq，还要能支持 kms的 _vlmcs._tcp 吧

[zfl9]

可能部分用户还有另一个需求，就是腾讯的域名用腾讯的DNS解析，解决微信转圈的问题

你直接使用腾讯的 119.29.29.29 作为 china 上游组，应该就可以了吧？

如果你的意思是让 chinadns-ng 能够为 特定域名 使用单独的 dns 上游，如 腾讯域名列表(tencent.txt) 使用 腾讯DNS上游(119.29.29.29)，那可能永远不会支持，因为 chinadns-ng 的核心就是两组 DNS 上游（china + trust），如果要进行这种更改，则将违反核心设计。

更新：2024.04.13 版本起，使用自定义组即可满足类似需求。公司域名走公司DNS、腾讯域名走腾讯DNS。

另外，我似乎没有遇到过你说的微信转圈问题（也许是部分地区？或者特殊网络环境？），如果这种情况很普遍，那岂不是说腾讯/微信相关的域名必须使用腾讯自己的DNS？（我认为不大可能，否则除了腾讯DNS外的其他公共DNS不都得废？）

[cattyhouse]

目前导致微信/京东某些界面转圈/打不开 基本上是阿里 dns (包括阿里的DoH DoT)造成的. 换成腾讯DNS或者114等其他的国内dns就不会有此问题.

[zfl9]

还要能支持 kms的 _vlmcs._tcp 吧

这个我看了下，核心是让 chinadns-ng 支持创建 SRV 记录，响应相关查询。

目前来说不确定是否要支持，等 2.0 完成了再看看吧。

[zfl9]

还是想重申下，chinadns-ng 2.0 虽然会考虑实现一些较为常用的功能，但目的不是替换 dnsmasq。

我仍然想让 chinadns-ng 保持简单和愚蠢，如果有些特殊需求无法满足，那我只能表示抱歉，希望大家理解。

[muziling]

只是看到写了2.0的目标是
替代传统的 dnsmasq + chinadns-ng + dns2tcp/dnsproxy 组合

所以最终还是要dnsmasq + chinadns-ng 2.0套娃，微信转圈只是举了一个例子，有的人可能和公司搞了穿透，公司域名要用公司的DNS解析。

[zfl9]

更新下进度，1.0版本已基本完成，测试了几天，暂未发现问题。

快的话这几天会更新master分支、README、发布1.0的release版本。

见 2024.03.07 版本。

[muziling]

想了下，好像和dnsmasq套娃是必须的， 所以实不实现dnsmasq的功能好像都没关系， 路由器需要dnsmasq来提供DHCP服务。
最终方案都是 dnsmasq + chinadns-ng

[zfl9]

想了下，好像和dnsmasq套娃是必须的， 所以实不实现dnsmasq的功能好像都没关系， 路由器需要dnsmasq来提供DHCP服务。 最终方案都是 dnsmasq + chinadns-ng

路由器上，你说的是有道理的（但不绝对）

实际上你可以关闭 dnsmasq 的 DNS 功能，只用 DHCP。
因为 dnsmasq 的 TCP DNS 实现效率很低，会 fork 很多 dnsmasq 进程出来。

不是所有人都在（主）路由器上使用，所以实现某些常用/必要功能仍然有意义。

[xtccc]

想了下，好像和dnsmasq套娃是必须的， 所以实不实现dnsmasq的功能好像都没关系， 路由器需要dnsmasq来提供DHCP服务。
最终方案都是 dnsmasq + chinadns-ng

也不一定吧，我现在使用systemd-networkd 的dhcp server，用着也还可以

[22ccy]

Make chinadns-ng great again!

[zfl9]

见最新 2024.03.25 版本，新增了以下功能：

• DNS 缓存、缓存忽略、缓存预刷新等。
• tag:none 域名的判定结果缓存。

---

2024.03.27 版本，新增了以下功能：

• 支持读取 hosts 文件
• 支持定义本地 A/AAAA 记录

---

剩下的 TODO 要稍微等一段时间，先忙些其他事情了。

[zfl9]

计划有变，由于 DoH 最低推荐 HTTP/2，纯手撸一个 HTTP/2 客户端不现实，看了其他实现，要么是使用语言(标准库)自带的 http 库，要么是使用第三方库（如 libcurl）；C/Zig 没有自带的 http 库。

也看了一些有关 DoH 和 DoT 的讨论，最终决定使用 DoT，相比较 DoH，少了一层 http 协议，可以减少协议开销。

想了下，浏览器更“喜欢” DoH 是因为浏览器本身就有完备的 HTTPS 客户端支持，而其他更底层的实现（如 systemd-resolved）则更偏好于 DoT，虽然不知道具体原因，但肯定有很大一部分是 HTTP/2 协议带来的复杂度导致的。

关于 DoH 和 DoT 的争论，主要是这一点：

• DoH 使用 443 端口，可藏匿于常规 HTTPS 流量中
• DoT 使用 853 端口，相比较 HTTPS/443，更容易被识别

不过我想说的是，真想找出哪些是 DoH 流量，哪些是 HTTPS 流量，太简单了，直接 ip 识别即可（dst_ip=公共DNS && dst_port=443），所以这个观点站不住脚；更何况 DoH 流量的数据包大小明显不同于常规网站 HTTPS 的数据包大小。

也就是说，国内DNS“藏不住”，国外DNS没必要藏（反正都走了代理）。

[zfl9]

这是我自己写dns时候的一点想法，作者看看有没有价值 我的ss-tproxy用的chnroute 模式 前两个是照抄chinadns-ng的，第三个是我根据自己的需求思考的

• 白名单内的域名: dns 解析使用223.5.5.5 , 直接访问ip
• 黑名单内的域名: dns 解析使用1.1.1.1 , 使用代理访问ip
• 对于vps的域名处理: dns 解析使用 1.1.1.1 , 使用直连访问ip
  域名在黑名单里
  新建立一个文件vps_doamins.ext 记录vps的域名，如果dns 查询域名是vps域名，则不将其ip加入sstp_black[6]中,而是将其ip地址添加到sstp_white[6]中

已实现，使用自定义组即可，自由搭配 upstream、ipset/nftset。

@xtccc

[Ir1Ka]

请问有计划在 gfwlist.ext 和 ignlist.ext 中实现正则表达式做分流支持吗？

[zfl9]

没有这个计划。

什么需求会要用到正则？

[Ir1Ka]

我看到一些能找到的 gfwlist 文件是用 AutoProxy 写的，里面很多会用到正则表达式，如果做转换为 chinadns-ng 支持的格式比较麻烦。

还有就是请问下对 chinadns-ng 里面对 子域名的子域名 是怎么处理的？
比如我在 gfwlist.ext 中写了 xxxx.com，它能匹配 a.xxxx.com，它是否能匹配 b.a.xxxx.com？

[zfl9]

我看到一些能找到的 gfwlist 文件是用 AutoProxy 写的，里面很多会用到正则表达式，如果做转换为 chinadns-ng 支持的格式比较麻烦。

这个大可不必担心，有很多成熟的 gfwlist2dnsmasq 工具，也有很多现成的 gfwlist.txt 域名列表。它们会处理正则表达式（一般也就是 google.*、blogspot.*，都是可以简单枚举出来的）。

---

chinadns-ng 的 dnl（domain name list，域名列表），里面配置的是 “域名后缀”。模式 xxx.com 可以匹配：

• xxx.com
• a.xxx.com
• b.a.xxx.com
• c.b.a.xxx.com
• 以此类推

[zfl9]

2.0 已完成，见最新 2024.04.27 版本。其他问题请单独开 issue 讨论。