为什么 dig @8.8.8.8 news.ycombinator.com 返回了错误的 ip

2019-08-05 15:50:07 +08:00
 tonywangcn

问题现象如下:

在境内的服务器上运行一下命令,针对 news.ycombinator.com 每次返回的都是不同的 ip,好像在 3-5 个之间,

而其实际地址应该是 209.216.230.240, 详细测试结果 ( https://tools.ipip.net/ping.php?view=news.ycombinator.com ).

dig @8.8.8.8 news.ycombinator.com

; <<>> DiG 9.14.1 <<>> @8.8.8.8 news.ycombinator.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33306
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;news.ycombinator.com.      IN  A

;; ANSWER SECTION:
news.ycombinator.com.   178 IN  A   67.228.221.221

;; Query time: 6 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Aug 05 07:19:26 UTC 2019
;; MSG SIZE  rcvd: 65


dig @8.8.8.8 news.ycombinator.com

; <<>> DiG 9.14.1 <<>> @8.8.8.8 news.ycombinator.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18922
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;news.ycombinator.com.      IN  A

;; ANSWER SECTION:
news.ycombinator.com.   130 IN  A   31.13.77.55

;; Query time: 11 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Aug 05 07:19:58 UTC 2019
;; MSG SIZE  rcvd: 65

虽然 news.ycombinator.com 在境内被强,但是 8.8.8.8 及 1.1.1.1 均可正常使用,但为何针对 news.ycombinator.com 却返回错误 IP 呢?

这个问题会导致 curl https://news.ycombinator.com 出现报错 curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to news.ycombinator.com:443

最初以为是本地 openssl 的问题,结果发现是 dns 返回了错误的 ip,疑为被投毒。

请问各位大佬,有没有解决方案,已测试过 alidns。

dig dns.google

; <<>> DiG 9.14.1 <<>> dns.google
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27355
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;dns.google.            IN  A

;; ANSWER SECTION:
dns.google.     729 IN  A   8.8.8.8
dns.google.     729 IN  A   8.8.4.4

;; Query time: 206 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Aug 05 07:26:26 UTC 2019
;; MSG SIZE  rcvd: 71


root @ / 
 [165] 🐳  → ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=37 time=5.92 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=37 time=11.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=37 time=7.29 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 7ms
rtt min/avg/max/mdev = 5.917/8.085/11.053/2.172 ms
3745 次点击
所在节点    程序员
23 条回复
sbw
2019-08-05 15:55:41 +08:00
就是投毒
Nitroethane
2019-08-05 15:58:21 +08:00
Tip:普通 DNS 服务使用 UDP 协议
Buges
2019-08-05 16:01:23 +08:00
DNS 问题一律推荐 dnscrypt-proxy2,强制只使用 doh,解决一切投毒污染的疑难杂症。
lance86
2019-08-05 16:06:01 +08:00
这个是 dns 劫持,并不是真正的 8.8.8.8 向你响应的,而是中间的某一个环节比如 ISP 发现你发送向 8.8.8.8 的 dns 请求,那么就直接给你返回了一个响应,默认的 dns 请求是 udp 包,未加密,所以你的电脑也不会意识到是假的响应。

注意你向 8.8.8.8 发送到 fns 请求的 query time 是 6ms 11ms,如果这个是真的服务器,8.8.8.8 肯定不在国内吧,最近的估计也是香港吧,6ms 不可能来得及。
edsheeran
2019-08-05 16:10:49 +08:00
gfvv
tonywangcn
2019-08-05 16:18:34 +08:00
@Nitroethane
@Buges
@lance86

谢谢,目前问题在 docker 和 宿主机均有出现,正常浏览器及软件使用有 ss 软件,并没有受到影响,但 docker 和 宿主机内的应用则十分受此问题困扰,在每个 docker 中均安装相关软件工作量略大,请问有没有办法,在宿主机或云服务器假设一个服务,然后 docker 及宿主机简单配置即可解决此类问题呢? 类似于在宿主机配置好 ss,docker 中配置 https_proxy 即可。

简单的搜索了些 dnscrypt-proxy2 相关的资料,貌似与 ss 颇为类似,将流量加密避免被中间投毒。
azh7138m
2019-08-05 16:30:33 +08:00
@tonywangcn 浏览器,比如 chrome 配置了代理之后,DNS 请求是会走代理的
4 个 8 能 11ms 返回结果你不觉得有点假吗?
leonard916
2019-08-05 16:57:35 +08:00
这个 IP 早就被某墙劫持(抢答)了 你们才发现吗?
Buges
2019-08-05 17:16:48 +08:00
@tonywangcn #6 在网关设备(路由器,虚拟机的宿主机等)部署上 dnscrypt-proxy 的服务,然后劫持所有 dns 请求

以宿主机地址 10.0.0.1,端口 5335 为例:
iptables -t nat -A PREROUTING -p udp --dport 53 ! -d 9.9.9.9 -j DNAT --to-destination 10.0.0.1:5335
iptables -t nat -A PREROUTING -p tcp --dport 53 ! -d 9.9.9.9 -j DNAT --to-destination 10.0.0.1:5335
iptables -t nat -A OUTPUT -p udp --dport 53 ! -d 9.9.9.9 -j DNAT --to-destination 127.0.0.1:5335
iptables -t nat -A OUTPUT -p tcp --dport 53 ! -d 9.9.9.9 -j DNAT --to-destination 127.0.0.1:5335
gesse
2019-08-05 17:25:49 +08:00
楼主是不是刚回国?
fromxt
2019-08-05 17:43:29 +08:00
本地 hosts 里面指定一下
bclerdx
2019-08-05 17:53:06 +08:00
@Buges 劫持的目的呢?
artandlol
2019-08-05 17:59:31 +08:00
应该是刚回国
tonywangcn
2019-08-05 18:00:07 +08:00
@Buges 谢谢大佬,这应该是目前唯一可行的方案了。
CEBBCAT
2019-08-05 18:46:51 +08:00
https://www.solidot.org/story?sid=61590

楼主有一点说错了,8.8.8.8 从今年儿童节就不能用了,因为有抢答,+tcp 也会被 reset

我当时用 DNS over HTTPS 解决了这一问题。注意,红鱼 DNS 已经不是一个好选项,他们进行了自我阉割
missdeer
2019-08-05 18:50:58 +08:00
SampleNaive
2019-08-05 19:09:41 +08:00
你有 ss 或者 ssr 的话, 用 win2socks 远程 DNS 可以解决投毒问题.
wwbfred
2019-08-06 01:45:53 +08:00
在天朝,我们管这个叫 IP 自信.
wwbfred
2019-08-06 01:54:02 +08:00
因为被污染的 IP 地址基本固定,可以考虑把这样的规则加入防火墙.
iptables -t mangle -N dns_chain
iptables -t mangle -I PREROUTING -p udp --sport 53 -j dns_chain
iptables -t mangle -A dns_chain -m string --algo bm --hex-string "|453FB20D|" --from 60 --to 180 -j DROP
iptables -t mangle -A dns_chain -m string --algo bm --hex-string "|430F81D2|" --from 60 --to 180 -j DROP
...
因为使用了匹配算法,效率会有影响.但不是大型服务器问题不大.
msg7086
2019-08-06 07:31:01 +08:00
DNS 污染,这都多少年了,如果不是刚回国的话,问出这问题不应该呀。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/589223

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX