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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 1971 天前的主题，其中的信息可能已经有所发展或是发生改变。

问题现象如下：

在境内的服务器上运行一下命令，针对 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

23 条回复 • 2019-08-06 16:39:17 +08:00

sbw

2019-08-05 15:55:41 +08:00

就是投毒

Nitroethane

2019-08-05 15:58:21 +08:00 via Android

Tip：普通 DNS 服务使用 UDP 协议

Buges

2019-08-05 16:01:23 +08:00 via Android

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 via iPhone

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 via Android

@Buges 劫持的目的呢？

artandlol

2019-08-05 17:59:31 +08:00 via Android

应该是刚回国

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 via Android

https://minidump.info/blog/2019/07/coredns-no-dns-poisoning/
CoreDNS 搭建无污染 DNS
了解一下

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 污染，这都多少年了，如果不是刚回国的话，问出这问题不应该呀。

jamesliu96

2019-08-06 09:18:13 +08:00 via Android

dnssec dnsovertls 一日不普及国内 dns 一日不干净，不过有了也没卵用

leopku

2019-08-06 09:45:57 +08:00 via iPhone

@missdeer 狂点赞！！！

bclerdx

2019-08-06 16:39:17 +08:00 via Android

@CEBBCAT 怎么确认和测试抢答？