zfl9
第三点，你使用 remote-dns 来解析 vps 域名，是怕国内 dns 污染？ 除此之外还有其他作用吗？
本质上来说，之所以不能简单的实现你的需求，是因为 tag:gfw 和 tag:chn 承担了两个角色： - 转发给特定上游dns - 将域名解析结果加入ipset/nftset 如果我们将这两个功能拆分开，那么问题就迎刃而解。也即，将它们分别对应两个域名列表txt： - forward-to-upstream.txt：用于查询时的转发判定 - add-ip-to-set.txt：用于响应时的添加ip至set 考虑到绝大多数 tag:chn、tag:gfw 域名都需要执行上述两种功能（也即转发判定，结果ip添加至set），为了方便（也主要是考虑到程序效率，以及兼容老的chinadns-ng），可以给 chinadns-ng 新增一个选项，比如： `--special-domains `，文件格式类似 ini，比如这样： ```ini [forward.china] xxx.com ... [forward.trust] yyy.com ... [add.chnip]...
chinadns-ng 2.0 准备加入配置文件支持，因为目前选项有点多了，使用配置文件会好一点，起码看起来清爽许多。 也许另一个选择是不添加上述说的 `--special-domains ` 选项，而是添加几个更简单的选项来搞定，因为这种特殊需求的域名数量不多，似乎没必要单独划分一个文件出来。 chinadns.conf 配置文件，语法很简单，一行一个（长）选项，空行和井号开头的行被忽略 ```bash # 监听地址和端口 bind-addr 127.0.0.1 bind-port 65353 # china上游，可以重复指定，也支持传统的逗号隔开 china-dns 223.5.5.5 china-dns 119.29.29.29 # trust上游，同上 trust-dns 8.8.8.8 trust-dns 1.1.1.1 # 域名列表文件，因为文件很大，所以用单独txt存储...
总结一下，可以通过新增 4 个更细分的 命令行选项/配置 来满足这种特别的需求： > 注意，这可能不是最终实现方案，具体请看此 issue 的最新评论。 - `--forward-china 域名`：等价于 --chnlist-file 中的域名，但仅限于 forward 上下文。 - `--forward-trust 域名`：等价于 --gfwlist-file 中的域名，但仅限于 forward 上下文。 - `--add-chnip 域名`：等价于 --chnlist-file 中的域名，但仅限于 add-ip 上下文。...
> 提一个疑问 > > 如果配置文件里 没有指定 ipset 相关的配置 也就是国内 国外的 2个 txt 里的 只是区分了 转发的目标 并不会加入对应的ipset, 然后 上面说的这个其实和 txt 里写域名等效了 对吧? EDIT: 是的，具体见上面我的新评论，我举了更详细的几个例子，以及用途说明。
如果广告域名是类似 gfwlist.txt/chnlist.txt 这样的域名后缀，那么应该很简单。但是如果涉及到正则表达式等模式，那么不会考虑。 我不清楚通过 dns 过滤广告的效果如何，我觉得很多广告都是内嵌到网页里面的，仅在 域名解析 上动手，感觉不是非常理想。我很久之前也折腾过类似的基于 dns 的广告过滤（当然，并不是 AdGuardHome 哈），不过后来我还是用浏览器插件了。
> 可能部分用户还有另一个需求，就是腾讯的域名用腾讯的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不都得废？）
> 还要能支持 kms的 _vlmcs._tcp 吧 这个我看了下，核心是让 chinadns-ng 支持创建 SRV 记录，响应相关查询。 目前来说不确定是否要支持，等 2.0 完成了再看看吧。
还是想重申下，chinadns-ng 2.0 虽然会考虑实现一些较为常用的功能，但目的不是替换 dnsmasq。 我仍然想让 chinadns-ng 保持简单和愚蠢，如果有些特殊需求无法满足，那我只能表示抱歉，希望大家理解。
嗯，确实描述不当，我做了修改： 之前：2.0 预计将使用单个 chinadns-ng 进程，替代传统的 dnsmasq + chinadns-ng + dns2tcp/dnsproxy 组合。 现在：2.0 预计将使用单个 chinadns-ng 进程，替代**经典用例**下的 dnsmasq + chinadns-ng + dns2tcp/dnsproxy 组合。