折腾修改公共 DNS 的意义，以及 DNS 同时并发 query 在 surge 上的实现疑问
neiltroyer849 · 2021-07-17 18:03:59 +08:00 · 1828 次点击这是一个创建于 1217 天前的主题，其中的信息可能已经有所发展或是发生改变。
现在折腾修改公共 DNS （ DNSPod 119.29.29.29/AliDNS 223.5.5.5 之类的）到底还有没有意义？老帖（ https://www.v2ex.com/t/714955 ）报告 raw 仓库地址 raw.githubusercontent.com 在三大运营商 DNS 已经被投毒，但国内公共 DNS 问题还不大，所以这样看来改为公共 DNS 还可以避免一些运营商的小操作。但我今天自己测试发现 DNSPod 解析改地址也是返回无效 ip 了，只有 AliDNS 还正常：
; <<>> DiG 9.10.6 <<>> @223.5.5.5 raw.githubusercontent.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1932
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;raw.githubusercontent.com. IN A
;; ANSWER SECTION:
raw.githubusercontent.com. 707 IN A 185.199.109.133
raw.githubusercontent.com. 707 IN A 185.199.110.133
raw.githubusercontent.com. 707 IN A 185.199.108.133
raw.githubusercontent.com. 707 IN A 185.199.111.133
;; Query time: 52 msec
;; SERVER: 223.5.5.5#53(223.5.5.5)
;; WHEN: Sat Jul 17 17:41:08 CST 2021
;; MSG SIZE rcvd: 107
----------------------------------------------------------------------------------------------------------------------
; <<>> DiG 9.10.6 <<>> @119.29.29.29 raw.githubusercontent.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16038
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;raw.githubusercontent.com. IN A
;; ANSWER SECTION:
raw.githubusercontent.com. 3600 IN A 0.0.0.0
;; Query time: 55 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Sat Jul 17 17:39:26 CST 2021
;; MSG SIZE rcvd: 70
Surge 的一个好处是自己写的 DNS client 可以绕开运营商的 53 端口抢答实现走公共 DNS 。不过目前的网络环境下，我明白更多时候只能是走白名单代理开完，只是在 surge 配置文件改参数时还在犹豫怎么操作 DNS 。Surge 据称是实现类似于 dnsmasq 的同时并发询问各 DNS 服务器以最快 respond 的为结果。不过如上所示，我自己做了实验后有个小小的疑问：抓包显示 surge 响应 baidu 用的是 DNSPod，但用 dig baidu.com 却可以发现明显本地运营商响应得要比 DNSPod 快得多（ 9ms 对 57ms ）:
; <<>> DiG 9.10.6 <<>> baidu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3161
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;baidu.com. IN A
;; ANSWER SECTION:
baidu.com. 308 IN A 39.156.69.79
baidu.com. 308 IN A 220.181.38.148
;; Query time: 9 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Jul 17 17:47:48 CST 2021
;; MSG SIZE rcvd: 59
------------------------------------------------------------
; <<>> DiG 9.10.6 <<>> @119.29.29.29 baidu.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8538
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;baidu.com. IN A
;; ANSWER SECTION:
baidu.com. 64 IN A 220.181.38.148
baidu.com. 64 IN A 39.156.69.79
;; Query time: 57 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Sat Jul 17 17:47:24 CST 2021
;; MSG SIZE rcvd: 70
所以实际上是更慢的 DNS query 被采用了？还是说这是个协议误差问题（ UDP/TCP ） or 其他因素使 dig 的时间不能反映真实 DNS query 结果。
综上所述，所以现在到底改公共 DNS 有多大意义呢？这么实验和分析下来可能改了公共 DNS 可能还是负优化……（比如解析 baidu 的时候本地运营商 DNS 会把本运营商机房的 ip 放在前而 DNSPod 的优先顺序并不然……）
; <<>> DiG 9.10.6 <<>> @223.5.5.5 raw.githubusercontent.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1932
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;raw.githubusercontent.com. IN A
;; ANSWER SECTION:
raw.githubusercontent.com. 707 IN A 185.199.109.133
raw.githubusercontent.com. 707 IN A 185.199.110.133
raw.githubusercontent.com. 707 IN A 185.199.108.133
raw.githubusercontent.com. 707 IN A 185.199.111.133
;; Query time: 52 msec
;; SERVER: 223.5.5.5#53(223.5.5.5)
;; WHEN: Sat Jul 17 17:41:08 CST 2021
;; MSG SIZE rcvd: 107
----------------------------------------------------------------------------------------------------------------------
; <<>> DiG 9.10.6 <<>> @119.29.29.29 raw.githubusercontent.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16038
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;raw.githubusercontent.com. IN A
;; ANSWER SECTION:
raw.githubusercontent.com. 3600 IN A 0.0.0.0
;; Query time: 55 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Sat Jul 17 17:39:26 CST 2021
;; MSG SIZE rcvd: 70
Surge 的一个好处是自己写的 DNS client 可以绕开运营商的 53 端口抢答实现走公共 DNS 。不过目前的网络环境下，我明白更多时候只能是走白名单代理开完，只是在 surge 配置文件改参数时还在犹豫怎么操作 DNS 。Surge 据称是实现类似于 dnsmasq 的同时并发询问各 DNS 服务器以最快 respond 的为结果。不过如上所示，我自己做了实验后有个小小的疑问：抓包显示 surge 响应 baidu 用的是 DNSPod，但用 dig baidu.com 却可以发现明显本地运营商响应得要比 DNSPod 快得多（ 9ms 对 57ms ）:
; <<>> DiG 9.10.6 <<>> baidu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3161
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;baidu.com. IN A
;; ANSWER SECTION:
baidu.com. 308 IN A 39.156.69.79
baidu.com. 308 IN A 220.181.38.148
;; Query time: 9 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Jul 17 17:47:48 CST 2021
;; MSG SIZE rcvd: 59
------------------------------------------------------------
; <<>> DiG 9.10.6 <<>> @119.29.29.29 baidu.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8538
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;baidu.com. IN A
;; ANSWER SECTION:
baidu.com. 64 IN A 220.181.38.148
baidu.com. 64 IN A 39.156.69.79
;; Query time: 57 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Sat Jul 17 17:47:24 CST 2021
;; MSG SIZE rcvd: 70
所以实际上是更慢的 DNS query 被采用了？还是说这是个协议误差问题（ UDP/TCP ） or 其他因素使 dig 的时间不能反映真实 DNS query 结果。
综上所述，所以现在到底改公共 DNS 有多大意义呢？这么实验和分析下来可能改了公共 DNS 可能还是负优化……（比如解析 baidu 的时候本地运营商 DNS 会把本运营商机房的 ip 放在前而 DNSPod 的优先顺序并不然……）
7 条回复 • 2021-07-19 04:54:07 +08:00
 |
1
xmlf 2021-07-17 18:11:15 +08:00 via Android
安卓端设置私密 dns 后，ss 无法联网
|
 |
2
BlackGlory 2021-07-17 21:44:39 +08:00
这是 DNS 轮询, 顺序对客户端来说是随机的.
|
 |
3
neiltroyer849 OP @BlackGlory 不是轮询，也不是随机，翻译的 Surge Manual 是这么描述 DNS 功能的：
“Surge 通过并发查询提高性能，会使用返回结果最快的服务器，这类似于 dnsmasq 命令的 --all-servers 选项。Surge iOS 版和 macOS 版的 Dashboard 会显示返回结果最快的那个服务器地址。如果 Surge 在 2 秒内没有收到任何响应，它将再次查询所有预设的 DNS 服务器。重试 4 次后如果还没有结果，Surge 将放弃查询并报告 DNS 错误。 某些域名可能具有性能较差的权限域名服务器，导致上游 DNS 服务器由于服务器端超时或其他连接问题返回空结果。如果所有上游 DNS 服务器确实都返回空的 DNS 查询结果，或者某些服务器返回空的结果，但其他服务器在 2 秒内没有响应，那 Surge 也将返回 DNS 查询结果为空的错误。 当 IPv6 可用并启用时，Surge DNS 客户端将向上游 DNS 服务器同时发送 A 和 AAAA 查询。将使用返回的第一个 A 或 AAAA 查询结果。” |
|
4
BlackGlory 2021-07-17 23:50:36 +08:00
@neiltroyer849 啊, 我以为你问的是响应结果那部分, 不好意思. 第一个响应的速度更快可能是因为 Optimistic DNS 机制, 先返回了旧的响应. 不过说到底国内的公共 DNS 都是被污染的, 并发查询多个被污染的服务器确实没有意义, 实际价值也不如 Optimistic DNS 吧.
|
 |
5
xenme 2021-07-18 07:11:38 +08:00 via iPhone
1. 建议开 doh，避免污染，公共 wifi 避免监控和探测
2. 并发 dns 没有特别大的意义 |
|
6
neiltroyer849 OP @xenme doh 的话我知道性能影响不会很明显但总是有心理就会不爽；真遇到需要保护隐私的时候就虚拟机前置代理➕tor 了
|
|
7
neiltroyer849 OP @BlackGlory 查了一下确实很有可能是 optimistic dns 的原因。而且某个版本更新后之后用了 Network Extension 会自动开启 Optimistic DNS 所以…. 这样想想并发 dns 还是被污染过的确实意义不是很大就是了
|
Select Language