如何判断谷歌 DNS 是否被 ISP 劫持

V2EX = way to explore

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

现在注册

已注册用户请登录

DNS 参考资料

› List of DNS Record Types

› dig 使用说明

› djbdns

› DNS Parameters

› dnslib for Python

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

移动宽带 ping 8.8.8.8 零丢包，只需要 25ms ，
比 114 还快， nslookup whether.114dns.com 114.114.114.114 能正常返回，
求谷歌 DNS 判断方法

第 1 条附言 · 2015-09-18 21:41:38 +08:00

traceroute to 8.8.8.8 (8.8.8.8 ), 64 hops max, 72 byte packets
1 内网 2.273 ms 1.418 ms 1.588 ms
2 内网 1.560 ms 1.503 ms 1.308 ms
3 172.*** (172.***) 49.570 ms 84.148 ms 108.177 ms
4 120.196.14.217 (120.196.14.217 ) 11.917 ms 7.365 ms 7.313 ms
5 120.196.244.29 (120.196.244.29 ) 15.243 ms 16.530 ms 14.711 ms
6 211.136.208.25 (211.136.208.25 ) 19.400 ms 19.693 ms 19.681 ms
7 211.139.134.178 (211.139.134.178 ) 20.352 ms 20.007 ms 20.108 ms
8 183.235.225.206 (183.235.225.206 ) 21.886 ms
120.198.204.18 (120.198.204.18 ) 23.612 ms 21.909 ms
9 211.136.193.142 (211.136.193.142 ) 18.939 ms
120.198.206.130 (120.198.206.130 ) 22.942 ms 21.651 ms
10 183.235.224.242 (183.235.224.242 ) 21.243 ms 20.942 ms 26.260 ms
11 google-public-dns-a.google.com (8.8.8.8 ) 20.204 ms 22.196 ms 20.566 ms

DNS

114.114.114.114

零丢包

8.8.8.8

42 条回复 • 2015-10-27 09:55:16 +08:00

laiyingdong

2015-09-18 17:47:36 +08:00

ping 25ms 是不是到香港的 Google 服务器？

ScotGu

2015-09-18 18:04:41 +08:00

我一般先用
nslookup www.google.com 8.8.8.8
nslookup -vc www.google.com 8.8.8.8
看看返回结果是否相同来判断。

Strikeactor

2015-09-18 18:10:46 +08:00

traceroute 看看呢

yexm0

2015-09-18 18:24:16 +08:00

用延迟来判断毫无用处.

fengxiang

2015-09-18 18:29:41 +08:00

低于 220 不用看了，肯定假的。

halczy

2015-09-18 18:31:26 +08:00 via iPhone

Windows 下 tracert 8.8.8.8
Linux / OSX mtr 8.8.8.8

移动正常应该走 HKIX ，电信 163 网正常是 202.97.x.x 后和 Google 台湾直连。

halczy

2015-09-18 18:40:48 +08:00

@fengxiang 看情况. 广州电信连 Google DNS 有时是走香港的, 有时走台湾. 香港是 10ms 左右, 台湾 30ms 左右.

yicun

2015-09-18 19:18:52 +08:00

@halczy windows 下有什么 traceroute 的工具？

meelo

2015-09-18 19:27:55 +08:00

@yicun windows 下是 tracert

xiaoc19

2015-09-18 19:28:26 +08:00

@halczy
@Strikeactor

traceroute to 8.8.8.8 (8.8.8.8 ), 64 hops max, 72 byte packets
1 内网 2.273 ms 1.418 ms 1.588 ms
2 内网 1.560 ms 1.503 ms 1.308 ms
3 172.*** (172.***) 49.570 ms 84.148 ms 108.177 ms
4 120.196.14.217 (120.196.14.217 ) 11.917 ms 7.365 ms 7.313 ms
5 120.196.244.29 (120.196.244.29 ) 15.243 ms 16.530 ms 14.711 ms
6 211.136.208.25 (211.136.208.25 ) 19.400 ms 19.693 ms 19.681 ms
7 211.139.134.178 (211.139.134.178 ) 20.352 ms 20.007 ms 20.108 ms
8 183.235.225.206 (183.235.225.206 ) 21.886 ms
120.198.204.18 (120.198.204.18 ) 23.612 ms 21.909 ms
9 211.136.193.142 (211.136.193.142 ) 18.939 ms
120.198.206.130 (120.198.206.130 ) 22.942 ms 21.651 ms
10 183.235.224.242 (183.235.224.242 ) 21.243 ms 20.942 ms 26.260 ms
11 google-public-dns-a.google.com (8.8.8.8 ) 20.204 ms 22.196 ms 20.566 ms

yicun

2015-09-18 19:30:46 +08:00

@meelo 谢谢指正，那 windows 下有什么 tracert 的工具，有下载吗？

xiaoc19

2015-09-18 19:34:11 +08:00

@yicun win 下直接使用 cmd

xiaoc19

2015-09-18 19:35:30 +08:00

@halczy 183.235.224.242 来自广东省阳江市移动，看起来悲剧

lenran

2015-09-18 19:42:34 +08:00

@yicun 系统自带，请在命令行下使用

meelo

2015-09-18 19:43:00 +08:00

@yicun 我的意思是， windows 下自带的 tracert 命令，就相当于 Linux 中的 traceroute

yicun

2015-09-18 19:48:56 +08:00

@xiaoc19 thank you
tracert 8.8.8.8
1 * <1 毫秒 <1 毫秒 192.168.0.1
2 1 ms 7 ms 1 ms 183.55.140.1
3 2 ms 1 ms 1 ms 119.146.39.93
4 9 ms 11 ms 11 ms 119.146.36.233
5 12 ms 11 ms 11 ms 119.146.125.93
6 * * * 请求超时。
7 11 ms 12 ms 10 ms 202.97.60.50
8 17 ms 17 ms 15 ms 202.97.61.118
9 * * 14 ms 202.97.62.214
10 18 ms * * 209.85.241.58
11 15 ms * * 216.239.40.13
12 * * 39 ms 209.85.253.89
13 44 ms * 45 ms 209.85.243.23
14 * * * 请求超时。
15 44 ms * * google-public-dns-a.google.com [8.8.8.8]
16 * * * 请求超时。
17 * * 143 ms google-public-dns-a.google.com [8.8.8.8]
跟踪完成。

tracert 8.8.4.4
1 17 ms <1 毫秒 <1 毫秒 192.168.0.1
2 2 ms 2 ms 1 ms 183.55.140.1
3 2 ms 2 ms 1 ms 119.146.39.93
4 8 ms 7 ms 7 ms 119.146.126.149
5 10 ms 7 ms 7 ms 119.146.125.38
6 14 ms 14 ms 10 ms 202.97.33.202
7 * * * 请求超时。
8 14 ms 15 ms 14 ms 202.97.61.26
9 10 ms 10 ms 10 ms 202.97.122.70
10 13 ms 12 ms 15 ms 216.239.42.193
11 11 ms 12 ms 12 ms 72.14.232.175
12 12 ms 12 ms 12 ms google-public-dns-b.google.com [8.8.4.4]

shizzmk

2015-09-18 20:04:32 +08:00

@yicun 不需要， Win 自帶有的

miyuki

2015-09-18 20:08:03 +08:00 via Android

@yicun cmd 下 reacert

win 下还有一个 gui 的工具 winmtr

fengxing

2015-09-18 20:56:23 +08:00

@yicun ipip.net 的 ITRACERT for WINDOWS ，不过是命令行工具
win 下还有 WinMTR ， gui 工具
TracertGUI ， gui 工具，不过经常出错误

pmpio

2015-09-18 21:24:14 +08:00

各省移动网络不太一样的，我们湖南的貌似是直接在 NAT 服务器上将所有 UDP 53 端口的查询重定向到了移动自己的 DNS ，最明显的效果，使用 dig +trace 时，直接就给你返回最终结果，不是一层一层的返回的。所以，这样子的话，你无论设置哪个 ip 作为 dns 服务器都一样的效果，比如你搞成 1.1.1.1 ，尽管互联网上这个 ip 上可能并无 dns 服务，你查询时也会得到正确结果~！这就传说中最牛 B 的 dns 劫持。

我以前在公司内网的网关上用 iptables + bind 试过了的。

pmpio

2015-09-18 21:26:22 +08:00

正在 Ping 8.8.8.8 具有 32 字节的数据:
来自 8.8.8.8 的回复: 字节=32 时间=7ms TTL=55
来自 8.8.8.8 的回复: 字节=32 时间=8ms TTL=55
来自 8.8.8.8 的回复: 字节=32 时间=7ms TTL=55
来自 8.8.8.8 的回复: 字节=32 时间=7ms TTL=55

8.8.8.8 的 Ping 统计信息:
数据包: 已发送 = 4 ，已接收 = 4 ，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 7ms ，最长 = 8ms ，平均 = 7ms

我这貌似更快，还经过了 5 重 NAT 才出去呢，我家里两次 NAT ，路由器和光猫，运营商那儿还有三次！

pmpio

2015-09-18 21:29:57 +08:00

通过最多 30 个跃点跟踪到 8.8.8.8 的路由

1 <1 毫秒 <1 毫秒 <1 毫秒 192.168.X.1
2 1 ms <1 毫秒 <1 毫秒 192.168.Y.1
3 108 ms 37 ms 12 ms 172.17.3.214
4 7 ms 4 ms 5 ms 172.17.3.213
5 * * * 请求超时。
6 5 ms 4 ms 5 ms 111.8.27.181
7 8 ms 9 ms 8 ms 211.142.209.157
8 11 ms 11 ms 10 ms 111.8.18.218
9 8 ms 7 ms 8 ms 8.8.8.8

跟踪完成。

看看湖南移动有多变态！！！直接自己弄个假的 8.8.8.8 ！

yicun

2015-09-18 21:44:19 +08:00

@miyuki @fengxing thank you
用了这个 WinMTR
https://github.com/oott123/WinMTR

gdtv

2015-09-18 21:48:25 +08:00

怎么解决这种劫持呢？

gdtv

2015-09-18 23:22:12 +08:00

@gdtv 我自问自答吧，最简单的解决方法是在 OpenWrt 里设置 DNS 转发为 /#/208.67.222.222#5353

zro

2015-09-18 23:58:34 +08:00

@gdtv 移动网络无法连接 208.67.222.222 ，肿么破？

youling

2015-09-19 01:23:20 +08:00

@fengxiang 不知道 google 的 DNS 是云 DNS ？自动判断最近的 google DNS 服务器，因此在中国也能达到 50 以下的延迟，并且 0 丢包。
http://www.infoq.com/cn/news/2015/05/gcp-network-data

vpslover

2015-09-19 01:27:37 +08:00 via iPhone

我这里 8.8.8.8 延迟 2-3ms 不用说肯定假的

wheat

2015-09-19 10:09:05 +08:00

8.8.8.8 的 dns 是被污染，不是被劫持， dns 默认为 udp ，无连接，所以 dns 请求发出后， gfw 跟 8.8.8.8 都会返回结果给你，但是系统以收到的第一个返回作为结果， gfw 抢先于 8.8.8.8 答复 dns 请求，造成 dns 污染，

详情可以用 tcpdump 查看 dns 请求即可
sudo tcpdump -i en0 -S -X -n -vv 'udp and (src 8.8.8.8 or dst 8.8.8.8 )'

在另外一个窗口
dig twitter.com @8.8.8.8

以下为 tcpdump 结果

＃发送请求
tcpdump: listening on en0, link-type EN10MB (Ethernet ), capture size 65535 bytes
10:01:04.714855 IP (tos 0x0, ttl 64, id 21027, offset 0, flags [none], proto UDP (17 ), length 57 )
10.0.0.110.59488 > 8.8.8.8.53: [udp sum ok] 42946+ A? twitter.com. (29 )
0x0000: 4500 0039 5223 0000 4011 0e14 0a00 006e E..9R#[email protected]
0x0010: 0808 0808 e860 0035 0025 8638 a7c2 0100 .....`.5.%.8....
0x0020: 0001 0000 0000 0000 0774 7769 7474 6572 .........twitter
0x0030: 0363 6f6d 0000 0100 01 .com.....
＃ gfw 冒充 8.8.8.8 返回错误的 dns 结果
10:01:04.758214 IP (tos 0x0, ttl 55, id 28944, offset 0, flags [none], proto UDP (17 ), length 84 )
8.8.8.8.53 > 10.0.0.110.59488: [udp sum ok] 42946 q: A? twitter.com. 1/0/0 twitter.com. A 159.106.121.75 (56 )
0x0000: 4500 0054 7110 0000 3711 f80b 0808 0808 E..Tq...7.......
0x0010: 0a00 006e 0035 e860 0040 4d25 a7c2 8180 ...n.5.`.@M%....
0x0020: 0001 0001 0000 0000 0774 7769 7474 6572 .........twitter
0x0030: 0363 6f6d 0000 0100 0107 7477 6974 7465 .com......twitte
0x0040: 7203 636f 6d00 0001 0001 0000 0ad4 0004 r.com...........
0x0050: 9f6a 794b .jyK
10:01:04.758553 IP (tos 0x0, ttl 117, id 59329, offset 0, flags [none], proto UDP (17 ), length 73 )
8.8.8.8.53 > 10.0.0.110.59488: [udp sum ok] 42946 q: A? twitter.com. 1/0/0 twitter.com. A 203.98.7.65 (45 )
0x0000: 4500 0049 e7c1 0000 7511 4365 0808 0808 E..I....u.Ce....
0x0010: 0a00 006e 0035 e860 0035 d8fc a7c2 8180 ...n.5.`.5......
0x0020: 0001 0001 0000 0000 0774 7769 7474 6572 .........twitter
0x0030: 0363 6f6d 0000 0100 01c0 0c00 0100 0100 .com............
0x0040: 0007 7600 04cb 6207 41 ..v...b.A

＃真正的 8.8.8.8 返回点结果
10:01:04.791550 IP (tos 0x0, ttl 44, id 37748, offset 0, flags [none], proto UDP (17 ), length 89 )
8.8.8.8.53 > 10.0.0.110.59488: [udp sum ok] 42946 q: A? twitter.com. 2/0/0 twitter.com. A 104.244.42.129, twitter.com. A 104.244.42.193 (61 )
0x0000: 4500 0059 9374 0000 2c11 e0a2 0808 0808 E..Y.t..,.......
0x0010: 0a00 006e 0035 e860 0045 5ece a7c2 8180 ...n.5.`.E^.....
0x0020: 0001 0002 0000 0000 0774 7769 7474 6572 .........twitter
0x0030: 0363 6f6d 0000 0100 01c0 0c00 0100 0100 .com............
0x0040: 0000 2b00 0468 f42a 81c0 0c00 0100 0100 ..+..h.*........
0x0050: 0000 2b00 0468 f42a c1 ..+..h.*.

xiaoc19

2015-09-19 10:13:37 +08:00

@wheat 我这种情况是 ISP 直接把 8.8.8.8 劫持为自己的 DNS

gdtv

2015-09-19 10:55:44 +08:00

@zro 我这里移动光纤可以连接 208.67.222.222#5353

xiaoc19

2015-09-19 11:00:56 +08:00

@gdtv 我这边也是， 20ms 左右，到香港服务器，不过感觉慢

pmpio

2015-09-19 11:47:16 +08:00

@gdtv 我这也可以连。

traceroute to 208.67.222.222 (208.67.222.222 ), 30 hops max, 38 byte packets
1 192.168.*.1 0.676 ms 0.602 ms 0.728 ms
2 172.17.3.214 5.132 ms 5.058 ms 6.024 ms
3 172.17.3.213 7.357 ms 5.250 ms 3.633 ms
4 * * *
5 111.8.27.181 5.234 ms 3.494 ms 3.814 ms
6 211.142.209.157 6.760 ms 7.587 ms 7.655 ms
7 221.176.20.233 8.362 ms 9.357 ms 8.813 ms
8 221.176.17.182 30.584 ms 40.369 ms 30.839 ms
9 * 221.176.22.110 33.016 ms 31.257 ms
10 221.176.24.146 26.571 ms 23.536 ms 221.176.24.142 33.711 ms
11 211.136.1.105 23.698 ms 29.544 ms 30.478 ms
12 223.118.2.169 84.412 ms 73.491 ms 223.118.2.161 30.759 ms
13 123.255.90.189 37.130 ms 33.845 ms 40.325 ms
14 208.67.222.222 30.112 ms 31.458 ms 29.624 ms

不过感觉也是假的！上一跳 123.255.90.189 是香港的 ip ，不可能就直接到美国的这个 dns 服务器了，在美国国内至少得有几跳才可能。。。。

要知道移动在香港也有分部的。

wclebb

2015-09-19 15:41:51 +08:00

其实 DNS 貌似的确会被劫持
我也无法解释，不管用 DNS 是什么，打开的时候是运营商我就「惊喜」。

lanlanlan

2015-09-19 16:17:00 +08:00

记得前些天移动劫持了 223.5.5.5/32 223.6.6.6/32 8888 8844 到他们自己的递归 DNS 服务器上数小时后恢复正常

wql

2015-09-20 20:18:34 +08:00

其实由于是 Anycast ，运营商只要建立一台服务器，规定他是 8.8.8.8 ，然后发布恶意的 BGP 黑路由。这样就能劫持了。
看来不 FQ 不行。

zro

2015-10-02 17:11:30 +08:00

@gdtv 我这从网关出来，接下来的第二跳就开始* * *状态了，一直跳到 30 跳都是 * * *

@lanlanlan 移动现在还直接劫持 12306 到自己的镜像服务器，账号密码估计都能随时看

gdtv

2015-10-02 17:49:21 +08:00

@zro

"移动现在还直接劫持 12306 到自己的镜像服务器"? 吓死我了

zro

2015-10-02 19:54:26 +08:00

@gdtv 貌似是个很高级的代理，具体原理不太懂，访问的 IP 不是 12306 自己的，是本省移动的， PING 时 13ms 左右（用来抢票是不是会很快？），路由器 Traceroute 到 kyfw.12306.cn 只有 6 跳，没有一跳是出省的。。。

lanlanlan

2015-10-05 11:45:33 +08:00

@zro 12306 用的网宿 CDN 没有出省可能是节点跟你同省了.6 跳也差不多了我这儿是 7 跳从 ZJ 到南京的网宿节点
6 19 ms 112.25.56.242 [AS56046] 中国江苏南京
7 149 ms 112.25.56.58 [AS56046] 中国江苏南京
8 18 ms wangsu.CDN.promote.auth-dns.local [112.25.35.79] [AS56046]
中国江苏南京

xrjr2015

2015-10-23 13:58:43 +08:00

本人这里经过长期多次的监测， 8.8.4.4 好很多，速度也很快 30ms+，估计是香港的服务器！

xiaoc19

2015-10-27 09:55:16 +08:00

@xrjr2015 我这边 8.8.4.4 也被劫持