我发现在华硕路由器使用 DNSPod DNS over TLS (DoT) 后,DNS 请求有些异常:
dig "@router.asus.com" o-o.myaddr.google.com TXT
; <<>> DiG 9.16.34 <<>> @router.asus.com o-o.myaddr.google.com TXT
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31621
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;o-o.myaddr.google.com. IN TXT
;; ANSWER SECTION:
o-o.myaddr.google.com. 180 IN TXT "edns0-client-subnet 120.204.17.12/0"
o-o.myaddr.google.com. 180 IN TXT "120.204.17.12"
;; Query time: 525 msec
;; SERVER: 192.168.50.1#53(192.168.50.1)
;; WHEN: Mon Dec 05 22:13:08 ;; MSG SIZE rcvd: 124
通过 Google 提供的方式查询出口 DNS 和 ECS 信息可以发现,ECS 信息是出口 DNS ,且网段为 /0 。
这意味着实际上 ECS 被错误配置为 0.0.0.0/0
了。
kdig @dot.pub +tls-ca o-o.myaddr.google.com TXT
;; TLS session (TLS1.2)-(ECDHE-SECP256R1)-(ECDSA-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 49816
;; Flags: qr rd ra; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; PADDING: 341 B
;; QUESTION SECTION:
;; o-o.myaddr.google.com. IN TXT
;; ANSWER SECTION:
o-o.myaddr.google.com. 180 IN TXT "edns0-client-subnet 116.*.*.0/24"
o-o.myaddr.google.com. 180 IN TXT "113.96.17.193"
;; Received 468 B
;; Time 2022-12-05 22:20:13 CST
;; From 120.53.53.53@853(TCP) in 1199.2 ms
而直接向 dot.pub
请求数据,却又是正常的。
通常而言,这个问题是路由器的问题,但是我注意到 Google Public DNS 的结果又不太一样。
在路由器上使用 dns.google
DoT ,不会显示 ECS 信息,既不支持 ECS 。
而直接向 dns.google
DoT 请求数据,会正常显示 ECS 信息。
360 安全 DNS
和阿里云公共 DNS
的 DoT 不支持 ECS ,所以没法进一步测试究竟是什么问题。
有没有大佬能够解惑一下? @naizhao 大佬救一下
这个主要导致对网站分流有影响,比如 vip1.loli.io
dig '@router.asus.com' vip1.loli.io
; <<>> DiG 9.16.34 <<>> @router.asus.com vip1.loli.io
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15800
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;vip1.loli.io. IN A
;; ANSWER SECTION:
vip1.loli.io. 582 IN CNAME vip1.loli.io.cdn.cloudflare.net.
vip1.loli.io.cdn.cloudflare.net. 282 IN A 172.67.214.101
vip1.loli.io.cdn.cloudflare.net. 282 IN A 104.21.86.31
;; Query time: 9 msec
;; SERVER: 192.168.50.1#53(192.168.50.1)
;; WHEN: Mon Dec 05 22:30:02 ;; MSG SIZE rcvd: 118
它在中国内地应当是 CNAME 至 vip1-cdn-jp1.loli.io
dig '@dns.alidns.com' vip1.loli.io
; <<>> DiG 9.16.34 <<>> @dns.alidns.com vip1.loli.io
; (4 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56002
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1408
;; QUESTION SECTION:
;vip1.loli.io. IN A
;; ANSWER SECTION:
vip1.loli.io. 1 IN CNAME vip1-cdn-jp1.loli.io.
vip1-cdn-jp1.loli.io. 1 IN A 103.121.211.234
;; Query time: 19 msec
;; SERVER: 2400:3200:baba::1#53(2400:3200:baba::1)
;; WHEN: Mon Dec 05 22:29:59 ;; MSG SIZE rcvd: 84
找到了: https://www.snbforums.com/threads/customize-stubby-yml.71920/#post-682523 需要修改 Stubby 配置,这是华硕原本就是这么设置的。
创建 /jffs/scripts/stubby.postconf
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_replace "edns_client_subnet_private: 1" "edns_client_subnet_private: 0" $CONFIG
1
johnjiang85 2022-12-05 22:43:46 +08:00 1
应该是路由的 dot 配置了禁止 ecs ,携带了 0.0.0.0/0 向 DNSPod 的 dot 请求,需要找下对应配置,选择开启 ecs 。
``` kdig @dot.pub +tls o-o.myaddr.google.com txt +subnet=8.8.8.8/0 ;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-128-GCM) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 4866 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR ;; CLIENT-SUBNET: 0.0.0.0/0/24 ;; PADDING: 332 B ;; QUESTION SECTION: ;; o-o.myaddr.google.com. IN TXT ;; ANSWER SECTION: o-o.myaddr.google.com. 180 IN TXT "113.96.17.244" o-o.myaddr.google.com. 180 IN TXT "edns0-client-subnet 113.96.17.244/0" ;; Received 468 B ;; Time 2022-12-05 22:45:59 CST ;; From 120.53.53.53@853(TCP) in 163.0 ms ``` |
2
872517414 OP @johnjiang85 似乎确实是这样,Asuswrt-Merlin 禁止了 ECS 。但为什么会携带 0.0.0.0/0……以及如果 DNSPod 方面能够将 /0 的信息直接屏蔽就好了。
|
3
872517414 OP 噢,似乎 Asuswrt-Merlin 没有禁用 ECS ,那为什么会这样……
|
4
wanacry 2022-12-06 00:00:40 +08:00
在华硕路由器使用 DNSPod DNS over TLS (DoT) 时,DNS 请求会出现异常。通过 Google 提供的方式查询出口 DNS 和 ECS 信息可以发现,ECS 信息是出口 DNS ,且网段为 /0 。这意味着实际上 ECS 被错误配置为 0.0.0.0/0 了。直接向 dot.pub 请求数据时,ECS 信息是正常的。这可能是路由器的问题,但是使用 dns.google DoT 时,不会显示 ECS 信息。这可能是 DNSPod DNS 服务器的问题。建议更换其他 DNS 服务器或更新路由器固件来解决这个问题。
|
5
872517414 OP 找到了: https://www.snbforums.com/threads/customize-stubby-yml.71920/#post-682523
需要修改 Stubby 配置,这是华硕原本就是这么设置的。 |
6
johnjiang85 2022-12-06 11:51:10 +08:00 1
@872517414
@wanacry > 通常而言,这个问题是路由器的问题,但是我注意到 Google Public DNS 的结果又不太一样。 在路由器上使用 dns.google DoT ,不会显示 ECS 信息,既不支持 ECS 。 而直接向 dns.google DoT 请求数据,会正常显示 ECS 信息。 这取决与公共 DNS 是否会将客户端请求携带的 ecs 0.0.0.0/0 携带到权威进行查询,根据 RFC 7871 ,可以不携带,也可以携带自己的 ecs 信息; dns.google 没有携带 0.0.0.0/0 到权威,所以不显示; DNSPod 的公共 DNS 会原样携带 0.0.0.0/0 到权威 DNS ,所以可以显示。 权威对 0.0.0.0/0 的一般处理方式是按照递归 DNS 的出口 IP 进行解析,这与不携带 0.0.0.0/0 完全一致; 部分权威也有可能解析到默认线路,这也是一种正常的处理方式; 两种方式都不会太准确,如果就是不想暴露自己客户端的外网 IP ,而不想要更准确的解析结果,可以传递 0.0.0.0/0 ,如果需要更准确的解析结果,则不能传递 0.0.0.0/0 ,对应的公共 DNS 可能将客户端 IP 作为 ECS 发送到权威 DNS 进行查询。 |
7
yaozijin 2022-12-06 11:54:59 +08:00
有个问题,AliDNS 我记得是支持 ECS 的啊
|
8
872517414 OP @yaozijin 但确实不支持,也许是接收来自终端 ECS ,但是不会提供给权威 DNS ?既然谷歌那边没有返回 ECS 信息,那他们那边肯定没收到来自阿里云公共 DNS 的 ECS 。dig / kdig 输出: https://rentry.org/g44u9z
|
9
huangtao728 2022-12-15 04:29:34 +08:00 via Android
踩过这个坑
Merlin 确实会添加 0.0.0.0/0 作为 subnet 传递给 DoT 服务器(可以通过临时搭建 DoT 服务器,设置上游为一个 UDP 服务器来降级请求,抓包验证) 常见 DNS 服务器(支持 ECS )对于无附带 subnet 的请求取客户端连接 IP 作为 subnet 进行 EDNS 查询,而对于自带 subnet 则认为客户端有意强制指定,会遵守这个 subnet 发给上游 对于 ASUS Merlin ,能正常返回经过 EDNS 结果的服务器应该都做了特殊处理,例如: dns.google 按你的描述应该是把 subnet=0.0.0.0/0 的请求视作不附带 subnet 了 或者像我自建的 mosdns 忽略了 DoT 请求中的 subnet ,直接采用客户端连接 IP |
10
huangtao728 2022-12-15 05:23:31 +08:00 via Android
|