zfl9
> 只是看到写了2.0的目标是 替代传统的 dnsmasq + chinadns-ng + dns2tcp/dnsproxy 组合 > > 所以最终还是要dnsmasq + chinadns-ng 2.0套娃，微信转圈只是举了一个例子，有的人可能和公司搞了穿透，公司域名要用公司的DNS解析。 我思考了下，在设计上确实可以再优化下，考虑到之前提出的几个新选项： > --forward-china 域名：等价于 --chnlist-file 中的域名，但仅限于 forward 上下文。 --forward-trust 域名：等价于 --gfwlist-file 中的域名，但仅限于 forward 上下文。 --add-chnip...
2.0 的开发时间可能会比预计的长，因为我需要先用 Zig 将当前的大部分 chinadns-ng 功能重写掉，基本的功能/性能测试通过后，才会着手 2.0 的改造。因此 2.0 的目标仍然未最终确定，大家有什么想法也欢迎提出。
> 抱歉这个功能的讨论搁置了这么久。。。 - https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-07.html - https://ns1.com/blog/ns1-announces-support-for-svcb-and-https-records - https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/ --- 看了下 rfc，qtype 64 是指查询 SVCB 记录，qtype 65 是指查询 HTTPS 记录。 HTTPS 记录是 SVCB 记录的一个特化（专门用于 HTTP 应用层协议），本质作用与 SVCB 相同，只是格式上有些许简化。 在 SVCB/HTTPS 的记录中，包含很多...
是的，ECH 的加密参数也会通过 SVCB/HTTPS 记录获得（按照 RFC 草案的说法）。污染问题完全可以通过 gfwlist.txt 来规避。
timeout 应该是 chinadns-ng 的上游没有返回，chinadns-ng 自身是可以处理 qtype 64/65 的（实际上只关心 qtype=A/AAAA，其他都直接转发）。
检查下 chinadns-ng 的日志（可以加上 -v 参数，看看 verbose log）。
```console # root @ archlinux in ~/chinadns-ng on git:dev x [10:50:37] $ dig @127.0.0.1 -p65353 google.com https ; DiG 9.18.19 @127.0.0.1 -p65353 google.com https ; (1 server found) ;; global...
> timeout 应该是 chinadns-ng 的上游没有返回，chinadns-ng 自身是可以处理 qtype 64/65 的（实际上只关心 qtype=A/AAAA，其他都直接转发）。 这个 issue 只是讨论要不要对 qtype 64/65 查询进行特殊处理（过滤？或其他，等等）。 chinadns-ng 对于 “不认识的qtype” 不做任何特殊操作，单纯 forward 给上游、将上游的 reply 转发给客户端罢了。
#144 新增了选项（还没发布） `--filter-qtype 64,65`
见 2024.04.13 版本。