[增强] ipv6应答的过滤已经实现，请问可否增加多一项开关能把qtype 64及qtype 65的请求/应答过滤掉？

[fox85]

希望大佬能考虑一下增加，现在在chinadns-ng的基础上还得搭配用GO写的一些DNS服务程序才能实现过滤qtype 64/65

小小的路由器上，flash空间实在捉襟见肘，GO编译出来的程序实在太大了，如果大佬能采纳就太好了 :)

[zfl9]

抱歉这个功能的讨论搁置了这么久。。。

• 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 的记录中，包含很多 key=value 格式的服务参数，其中值得我们注意的是：ipv4hint、ipv6hint。这两参数指定了服务的 ipv4/ipv6 地址，目的是减少客户端的 DNS 查询量以及解析延迟，从某种程度上讲，它的作用相当与传统的 A/AAAA 查询。

在国内这种 dns 环境下，ISP/防火墙 可能会对 ipv4hint、ipv6hint 中的 ip 地址进行投毒/污染，比如替换为无法连接的 ip 或错误的 ip。我想这就是你们想要屏蔽 SVCB/HTTPS 查询的原因吧。

但我想了下，如果 ISP/防火墙 打算对某个域名进行污染，那么该域名几乎肯定会在 gfwlist.txt 中（如果不是，你当然也可以手动将相关域名加入 gfw 列表），因为 tag:gfw 域名的所有 qtype 的查询，都只走 trust 可信上游，所以实际上应该不存在 DNS 污染。

所以按照我个人的理解，filter qtype 64/65 似乎不是很有用（因为可以走 tag:gfw 机制完全避开）。

当然，欢迎大家发表不同看法和意见。

[xtccc]

我的意见是不用过滤SVCB HTTPS记录 以后ECH 是不是还要用这些功能呢

我的理解是ECH以后是趋势吧，那就没必要过滤SVCB HTTPS

[zfl9]

是的，ECH 的加密参数也会通过 SVCB/HTTPS 记录获得（按照 RFC 草案的说法）。污染问题完全可以通过 gfwlist.txt 来规避。

[tanst]

当设置 AdGuard Home 上游为 ChinaDNS-NG 的时候，会有大量 HTTPS 类型的请求报 timeout

dnsproxy: upstream 127.0.0.1:15354 failed to exchange ;ajs.ipip.net. IN HTTPS in 20.002165825s: exchanging with 127.0.0.1:15354 over udp: read udp 127.0.0.1:55311->127.0.0.1:15354: i/o timeout

版本：chinadns-ng - 2023.10.28-1

[zfl9]

timeout 应该是 chinadns-ng 的上游没有返回，chinadns-ng 自身是可以处理 qtype 64/65 的（实际上只关心 qtype=A/AAAA，其他都直接转发）。

[zfl9]

检查下 chinadns-ng 的日志（可以加上 -v 参数，看看 verbose log）。

[zfl9]

# 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 options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24610
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
google.com.		3140	IN	HTTPS	1 . alpn="h2,h3"

;; Query time: 26 msec
;; SERVER: 127.0.0.1#65353(127.0.0.1) (UDP)
;; WHEN: Fri Nov 24 10:50:51 CST 2023
;; MSG SIZE  rcvd: 64


# root @ archlinux in ~/chinadns-ng on git:dev x [10:50:51]
$ dig @127.0.0.1 -p65353 r2wind.cn https

; <<>> DiG 9.18.19 <<>> @127.0.0.1 -p65353 r2wind.cn https
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40717
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;r2wind.cn.			IN	HTTPS

;; ANSWER SECTION:
r2wind.cn.		126	IN	HTTPS	5 . alpn="h3,h3-29,h3-Q050,h2" port=443

;; Query time: 26 msec
;; SERVER: 127.0.0.1#65353(127.0.0.1) (UDP)
;; WHEN: Fri Nov 24 10:50:58 CST 2023
;; MSG SIZE  rcvd: 83

# root @ archlinux in ~/chinadns-ng on git:dev x [10:50:44] C:130
$ chinadns-ng -v -d chn
2023-11-24 10:50:45 I [main.c:384 main] local listen addr: 127.0.0.1#65353
2023-11-24 10:50:45 I [main.c:387 main] chinadns server#1: 114.114.114.114
2023-11-24 10:50:45 I [main.c:391 main] trustdns server#1: 8.8.8.8
2023-11-24 10:50:45 I [main.c:396 main] default domain name tag: chn
2023-11-24 10:50:45 I [main.c:420 main] dns query timeout: 5 seconds
2023-11-24 10:50:45 I [main.c:424 main] filter no-ip reply from chinadns
2023-11-24 10:50:45 I [main.c:428 main] print the verbose running log

2023-11-24 10:50:51 I [main.c:155 handle_local_packet] query [google.com] from 127.0.0.1#41028 (0)
2023-11-24 10:50:51 I [main.c:203 handle_local_packet] forward [google.com] to 114.114.114.114 (chinadns)
2023-11-24 10:50:51 I [main.c:322 handle_remote_packet] reply [google.com] from 114.114.114.114 (0), result: accept

2023-11-24 10:50:58 I [main.c:155 handle_local_packet] query [r2wind.cn] from 127.0.0.1#54342 (1)
2023-11-24 10:50:58 I [main.c:203 handle_local_packet] forward [r2wind.cn] to 114.114.114.114 (chinadns)
2023-11-24 10:50:58 I [main.c:322 handle_remote_packet] reply [r2wind.cn] from 114.114.114.114 (1), result: accept
^C

[zfl9]

timeout 应该是 chinadns-ng 的上游没有返回，chinadns-ng 自身是可以处理 qtype 64/65 的（实际上只关心 qtype=A/AAAA，其他都直接转发）。

这个 issue 只是讨论要不要对 qtype 64/65 查询进行特殊处理（过滤？或其他，等等）。

chinadns-ng 对于 “不认识的qtype” 不做任何特殊操作，单纯 forward 给上游、将上游的 reply 转发给客户端罢了。

[tanst]

timeout 应该是 chinadns-ng 的上游没有返回，chinadns-ng 自身是可以处理 qtype 64/65 的（实际上只关心 qtype=A/AAAA，其他都直接转发）。

的确是，我国内上游用的运营商的，HTTPS 类型的查询超时，用阿里的 223.5.5.5 就 OK 了
感谢！

[zfl9]

#144
新增了选项（还没发布）
--filter-qtype 64,65

[zfl9]

见 2024.04.13 版本。