V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
xiaoc19
V2EX  ›  DNS

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

  •  
  •   xiaoc19 · 2015-09-18 17:46:02 +08:00 · 23427 次点击
    这是一个创建于 3340 天前的主题,其中的信息可能已经有所发展或是发生改变。
    移动宽带 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
    42 条回复    2015-10-27 09:55:16 +08:00
    laiyingdong
        1
    laiyingdong  
       2015-09-18 17:47:36 +08:00
    ping 25ms 是不是到香港的 Google 服务器?
    ScotGu
        2
    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
        3
    Strikeactor  
       2015-09-18 18:10:46 +08:00
    traceroute 看看呢
    yexm0
        4
    yexm0  
       2015-09-18 18:24:16 +08:00
    用延迟来判断毫无用处.
    fengxiang
        5
    fengxiang  
       2015-09-18 18:29:41 +08:00
    低于 220 不用看了,肯定假的。
    halczy
        6
    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
        7
    halczy  
       2015-09-18 18:40:48 +08:00
    @fengxiang 看情况. 广州电信连 Google DNS 有时是走香港的, 有时走台湾. 香港是 10ms 左右, 台湾 30ms 左右.

    yicun
        8
    yicun  
       2015-09-18 19:18:52 +08:00
    @halczy windows 下有什么 traceroute 的工具?
    meelo
        9
    meelo  
       2015-09-18 19:27:55 +08:00
    @yicun windows 下是 tracert
    xiaoc19
        10
    xiaoc19  
    OP
       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
        11
    yicun  
       2015-09-18 19:30:46 +08:00
    @meelo 谢谢指正,那 windows 下有什么 tracert 的工具,有下载吗?
    xiaoc19
        12
    xiaoc19  
    OP
       2015-09-18 19:34:11 +08:00
    @yicun win 下直接使用 cmd
    xiaoc19
        13
    xiaoc19  
    OP
       2015-09-18 19:35:30 +08:00
    @halczy 183.235.224.242 来自广东省阳江市 移动,看起来悲剧
    lenran
        14
    lenran  
       2015-09-18 19:42:34 +08:00
    @yicun 系统自带,请在命令行下使用
    meelo
        15
    meelo  
       2015-09-18 19:43:00 +08:00
    @yicun 我的意思是, windows 下自带的 tracert 命令,就相当于 Linux 中的 traceroute
    yicun
        16
    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
        17
    shizzmk  
       2015-09-18 20:04:32 +08:00
    @yicun 不需要, Win 自帶有的
    miyuki
        18
    miyuki  
       2015-09-18 20:08:03 +08:00 via Android
    @yicun cmd 下 reacert

    win 下还有一个 gui 的工具 winmtr
    fengxing
        19
    fengxing  
       2015-09-18 20:56:23 +08:00
    @yicun ipip.net 的 ITRACERT for WINDOWS ,不过是命令行工具
    win 下还有 WinMTR , gui 工具
    TracertGUI , gui 工具,不过经常出错误
    pmpio
        20
    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
        21
    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
        22
    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
        23
    yicun  
       2015-09-18 21:44:19 +08:00
    @miyuki @fengxing thank you
    用了这个 WinMTR
    https://github.com/oott123/WinMTR
    gdtv
        24
    gdtv  
       2015-09-18 21:48:25 +08:00
    怎么解决这种劫持呢?
    gdtv
        25
    gdtv  
       2015-09-18 23:22:12 +08:00
    @gdtv 我自问自答吧,最简单的解决方法是在 OpenWrt 里设置 DNS 转发为 /#/208.67.222.222#5353
    zro
        26
    zro  
       2015-09-18 23:58:34 +08:00
    @gdtv 移动网络无法连接 208.67.222.222 ,肿么破?
    youling
        27
    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
        28
    vpslover  
       2015-09-19 01:27:37 +08:00 via iPhone
    我这里 8.8.8.8 延迟 2-3ms 不用说肯定假的
    wheat
        29
    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
        30
    xiaoc19  
    OP
       2015-09-19 10:13:37 +08:00
    @wheat 我这种情况是 ISP 直接把 8.8.8.8 劫持为自己的 DNS
    gdtv
        31
    gdtv  
       2015-09-19 10:55:44 +08:00
    @zro 我这里移动光纤可以连接 208.67.222.222#5353
    xiaoc19
        32
    xiaoc19  
    OP
       2015-09-19 11:00:56 +08:00
    @gdtv 我这边也是, 20ms 左右,到香港服务器,不过感觉慢
    pmpio
        33
    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
        34
    wclebb  
       2015-09-19 15:41:51 +08:00
    其实 DNS 貌似的确会被劫持
    我也无法解释,不管用 DNS 是什么,打开的时候是运营商我就「惊喜」。
    lanlanlan
        35
    lanlanlan  
       2015-09-19 16:17:00 +08:00
    记得前些天 移动劫持了 223.5.5.5/32 223.6.6.6/32 8888 8844 到他们自己的递归 DNS 服务器上 数小时后恢复正常
    wql
        36
    wql  
       2015-09-20 20:18:34 +08:00
    其实由于是 Anycast ,运营商只要建立一台服务器,规定他是 8.8.8.8 ,然后发布恶意的 BGP 黑路由。这样就能劫持了。
    看来不 FQ 不行。
    zro
        37
    zro  
       2015-10-02 17:11:30 +08:00
    @gdtv 我这从网关出来,接下来的第二跳就开始* * *状态了,一直跳到 30 跳都是 * * *

    @lanlanlan 移动现在还直接劫持 12306 到自己的镜像服务器,账号密码估计都能随时看
    gdtv
        38
    gdtv  
       2015-10-02 17:49:21 +08:00
    @zro

    "移动现在还直接劫持 12306 到自己的镜像服务器"? 吓死我了
    zro
        39
    zro  
       2015-10-02 19:54:26 +08:00
    @gdtv 貌似是个很高级的代理,具体原理不太懂,访问的 IP 不是 12306 自己的,是本省移动的, PING 时 13ms 左右(用来抢票是不是会很快?),路由器 Traceroute 到 kyfw.12306.cn 只有 6 跳,没有一跳是出省的。。。
    lanlanlan
        40
    lanlanlan  
       2015-10-05 11:45:33 +08:00   ❤️ 1
    @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
        41
    xrjr2015  
       2015-10-23 13:58:43 +08:00
    本人这里经过长期多次的监测, 8.8.4.4 好很多,速度也很快 30ms+,估计是香港的服务器!
    xiaoc19
        42
    xiaoc19  
    OP
       2015-10-27 09:55:16 +08:00
    @xrjr2015 我这边 8.8.4.4 也被劫持
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2617 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 05:33 · PVG 13:33 · LAX 21:33 · JFK 00:33
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.