中国的域名解析到65.49.2.178 是一个什么失误？

AuthorZola / Posted on14 Comments

中国的域名解析到65.49.2.178 是一个什么失误？让我们来查一查。


第一部分 事故描述


中国的一家DNS服务商DNSPOD于 2014 年 1 月 21 日 16:18 说：

2014年1月21日下午15：10左右，DNSPod发现国内所有通用顶级域的根出现异常，技术人员已联系相关机构协调处理。目前根已恢复正常，但是后续还会存在以下问题：
根虽已恢复，但还有返回错误IP地址，因为各地有缓存，所以部分地区可能会持续12小时。

以下是一些网友在网上提供的事故截图：

图片来自 http://www.v2ex.com/t/97867 上的，点击可看大图


第二部分 从IP资料方面找原因


国内所有通用的顶级域名，被解析到65.49.2.178。
全国大规模网站故障 许多域名被解析到65.49.2.178，这是一个什么IP？
http://www.ip.cn/index.php?ip=65.49.2.178 有下面四种答案：

  • GeoIP: Fremont, California, United States Hurricane Electric
  • 65.49.2.178=美国 北卡罗莱纳州卡里镇
  • Dynamic Internet Technology 动态互联网技术公司
  • Anonymous Proxy

新浪科技的《中国顶级域名根服务器故障 大部分网站受影响》 在 2014年01月21日 16:16发文说：

新浪科技讯 1月21日下午消息，据多家DNS服务商透露，今日下午3点，全国所有通用顶级域的根服务器出现异常，导致国内大部分用户无法正确解析域名，对全国互联网链接造成系统性影响。
根服务器主要用来管理互联网的主目录。全世界只有13台，这13台根域名服务器中名字分别为“A”至“M”，其中10台设置在美国，另外各有一台设置于英国、瑞典和日本。
“简单的说，如果我们要访问baidu.com这个网站，先要指向根服务器，根服务再将用户指向.com服务器，.com的解析服务器再把用户指向baidu.com。”一位DNS技术专家解释说，这次的问题仅出现在中国，说明全球根服务器并未出现问题，问题很可能是国内网络运营商。
“这次访问故障出现在下午3点20分左右，当用户请求根服务器时，被指向一个IP地址(A记录)，这是完全错误的引导。”上述专家表示。

这是不是中国政府利用位于中国的域名根服务做DNS污染时不小心弄出来的一个失误呢？

前些年我的域名zuola.com被GFW污染，所已知GFW对域名污染的给的假IP有：

  • 64.33.88.161 Trumbull, Connecticut, United States OLM, LLC
  • 202.106.1.2 Beijing, China China Unicom Beijing
  • 216.234.179.13 Edmonton, Alberta, Canada Tera-byte Dot Com
  • 4.36.66.178 United State Level 3 Communications
  • 211.94.66.147 Beijing, China
  • 202.181.7.85 澳大利亚
  • 209.145.54.50 San Marcos, California, United States

这个IP在2012年04月19日 出现在这个网页上
http://ffman.exteen.com/20110817/welfare-storm-ch2

也出现在一些伊朗语言和泰国语言的网站上，显然这个IP曾被当成代理，可能确实是一个匿名代理(Anonymous Proxy)用过的IP .
想尝试对65.49.2.178 做反向解析，解析失败。

在GOOGLE搜索 178.2.49.65.in-addr.arpa. 只有一条搜索结果 http://dns.l4x.org/65.49.2.178 ，没看懂是什么，从IP信息里看来找不到“国家支持的DNS污染”的证据。

http://whois.domaintools.com/65.49.2.178
和
http://whois.arin.net/rest/nets;q=65.49.2.178?showDetails=true&showARIN=false&ext=netref2
显示这个IP在美国 夏延市 Sophidea Inc.
United States Cheyenne Sophidea Inc.

蜜罐项目发现这个IP段的其他IP常被人拿来灌水发广告：
在 http://www.projecthoneypot.org/ip_65.49.2.178 显示有这个IP居然12个user-agent 字符串
这里显示这个IP是Dynamic Internet Technology公司的 http://www.myip.cn/65.49.2.178 
Dynamic Internet Technology公司是个什么公司？用过自由门、无界的翻墙工具的人都知道，这是对抗中国政府长期封锁法轮功网站的一家技术公司，在动态网上发布各种翻墙工具。
在 http://bgp.he.net/net/65.49.2.0/24#_dns 这个网站上，提供了IP的反向解析结果，可以看到动态网公司的网站都在这个65.49.2.0/24 的IP段上：
IP PTR A
65.49.2.9 ultrasurf.us, ultrasurfing.com, wujieliulan.com
65.49.2.10 blogwujie.com, wujieblog.com
65.49.2.13 cbzs.info, jqzx.info
65.49.2.28 feitian-california.org
65.49.2.29 symail.org, synewsletter.com
65.49.2.41 epochdaily.com
65.49.2.101 bet888win.com, clgtchat.com, crystalprofit.net,
eachother.biz, eva-funds.biz,freeantiddos.com,
kaplan-properties.com, lizafund.com,
 profit-finance.com,proxy1.idealhosting.org,
proxy2.idealhosting.org, rekario.com,
texinkarbotu.com,torrenubosa.com
65.49.2.112 ns1.freeantiddos.com
65.49.2.114 ns2.freeantiddos.com
65.49.2.153 dns.chinese1.org
65.49.2.208 fgmtv.org
65.49.2.216 fgmtv.net, hotdownload.org
65.49.2.247 pudumail.com, shenyunmail.org, sycircle.com
65.49.2.253 weiboleak.com
Updated 21 Jan 2014 06:59 PST © 2014 Hurricane Electric
可见这个IP确实是自由门等翻墙工具用过的IP。也就是说，可以把这个事故和中国政府的网络封锁操作联系起来。

我查过 65.49.2.178  这个IP和所在的IP段，是动态网用于匿名代理，被蜜罐项目侦测到过，但这个IP没有绑定任何域名，未提供过web服务，无法反向解析，不存在被GFW引导过去产生DDoS攻击效果的说法。 http://whois.webhosting.info/65.49.2.178


第三部分 从根域名服务器找原因


我尝试从根域名服务器方面来找。

我印象中，至少有一台根服务器在中国，但腾讯网在报道此次事件时说：

根服务器主要用来管理互联网的主目录，全世界只有13台。1个为主根服务器，放置在美国。其余12个均为辅根服务器，其中9个放置在美国，欧洲2个，位于英国和瑞典，亚洲1个，位于日本。所有根服务器均由美国政府授权的互联网域名与号码分配机构ICANN统一管理，负责全球互联网域名根服务器、域名体系和IP地址等的管理。

维基百科上也说“中国根服务器被关闭”。这样给人印象是国外根域名服务器有错。我觉得不对，中国大陆有F、I这2个根域DNS服务器镜像。

2003年十月就在北京安装了一个F-root服务器，October: F-Root installed in Beijing, People’s Republic of China; 
2006年，中国境内引进根域名服务器J-ROOT和顶级域名服务器B-gTLD顶级域名服务器镜像;
ICANN的根域名服务器在78个城市有120多个节点为，在北京有三个节点，也就是根域名服务器镜像：
  1. F-ROOT（电信，交换中心）由互联网软件联盟(ISC＝Internet Systems Consortium)和中国电信共同建立。
  2. J-ROOT（网通） 由Verisign和网通共同设立。
  3. I-ROOT（CNNIC）  由瑞典国家互联网交换中心(Autonomatic，后来叫Netnod公司)在CNNIC设立。
在亚太地区的F-root就有14个镜像，下面这张图来自亚太互联网络信息中心：

由于在中国有根域名服务器节点，所以“域名解析往返周期（或叫环程时间Round Trip Time）”的RTT算法会保证经过一段DNS轮询时间“学习”后会选择响应最快的境内根域名服务器。并且此次仅有中国大陆出现网站故障，可见此次大规模网站故障的罪魁祸首是中国的根域名服务器镜像。
接下来，就是要找出中国的这几台根域名服务器的真实IP地址，然后测试一下这几台服务器是否正常工作。
不过维基百科上说：

“中国大陆有F、I这2个根域DNS镜像[9]，但因为多次发生DNS污染而影响外国网络，威胁互联网安全和自由而被断开与国际互联网的连接。”

我根据维基百科找到这篇英文报道：《After DNS problem, Chinese root server is shut down》， 这个链接里的说“‘withdrawn route announcements’ made by the server“，听上去中国根镜像还在中国，只是瑞典公司Netnod用服务器撤销路由通告，不算取消镜像吧？
下面的图片截取自 http://www.root-servers.org ， 
我想跟踪 192.5.5.241 这个IP在北京哪里，第一次居然是在美国：

traceroute to 192.5.5.241 (192.5.5.241), 64 hops max, 72 byte packets
 1  192.168.10.1 (192.168.10.1)  1.247 ms  1.114 ms  1.078 ms
 2  192.168.1.1 (192.168.1.1)  1.481 ms  1.354 ms  1.313 ms
 3  h×××.s98.ts.hinet.net (168.95.98.×××)  7.286 ms  7.455 ms  7.190 ms
 4  * h242.s25.ts.hinet.net (168.95.25.242)  7.473 ms  7.358 ms
 5  tpdt-3012.hinet.net (220.128.4.30)  21.033 ms *  13.669 ms
 6  * * *
 7  * * r4001-s2.tp.hinet.net (220.128.11.133)  10.042 ms
 8  * 211-72-108-153.hinet-ip.hinet.net (211.72.108.153)  144.699 ms  144.337 ms
 9  paix.r1.pao1.isc.org (198.32.176.3)  145.071 ms *  145.100 ms
10  f.root-servers.net (192.5.5.241)  144.551 ms  144.491 ms  144.794 ms

最近的这个IP 198.32.176.3是美国IP。
第二次用VPN连到江苏再traceroute

traceroute to 192.5.5.241 (192.5.5.241), 64 hops max, 72 byte packets
 1  1.1.1.1 (1.1.1.1)  112.112 ms  108.556 ms  108.587 ms
 2  221.6.170.1 (221.6.170.1)  119.476 ms  118.213 ms  113.267 ms
 3  221.6.161.153 (221.6.161.153)  112.413 ms  118.053 ms  122.491 ms
 4  221.6.161.201 (221.6.161.201)  119.346 ms  121.014 ms  114.563 ms
 5  219.158.96.149 (219.158.96.149)  150.785 ms  150.258 ms  154.764 ms
 6  219.158.4.10 (219.158.4.10)  147.241 ms  147.273 ms  147.740 ms
 7  * 219.158.97.254 (219.158.97.254)  213.981 ms  205.347 ms
 8  219.158.102.154 (219.158.102.154)  334.414 ms  330.767 ms *
 9  las-bb1-link.telia.net (213.248.94.125)  505.146 ms  326.467 ms  316.009 ms
10  dls-bb1-link.telia.net (213.248.80.14)  361.110 ms  490.916 ms  360.979 ms
11  chi-bb1-link.telia.net (80.91.248.208)  404.532 ms  416.520 ms  454.820 ms
12  isc-117366-chi-bb1.telia.net (213.248.85.18)  456.797 ms  465.479 ms  468.200 ms
13  f.root-servers.net (192.5.5.241)  532.196 ms  494.677 ms  423.665 ms

结果显示先跑到江苏，然后到辽宁联通，然后离f.root-servers.net最近的80.91.248.208和213.248.85.18居然是欧洲IP。看来任播技术(anycast)是IP路由协议上的镜像行为，一个IP地址对应多个服务器，所以这个服务器在欧洲和美国都有。

然后我拜托陈少举帮我在中国境内tracert一下这个F-ROOT根域名服务器

C:Userschenshaoju>tracert 192.5.5.241
通过最多 30 个跃点跟踪到 f.root-servers.net [192.5.5.241] 的路由:
 1     4 ms    17 ms     4 ms  10.20.0.1 2     6 ms     4 ms     4 ms  10.20.0.1 3    23 ms     4 ms     5 ms  58.215.135.21 4    10 ms    11 ms    11 ms  61.177.102.13 5    31 ms    31 ms    32 ms  202.97.65.201 6     *        *        *     请求超时。 7    32 ms    32 ms    33 ms  18.254.120.106.static.bjtelecom.net [106.120.254.18] 8    42 ms    34 ms    32 ms  219.142.18.54 9    31 ms    32 ms    33 ms  218.241.102.10110    30 ms    39 ms    33 ms  218.241.107.9011    30 ms    72 ms    32 ms  f.root-servers.net[192.5.5.241]
跟踪完成。

好，这回离192.5.5.241最近的IP218.241.107.90是一个CNNIC的IP，可以证明F-ROOT还在中国，维基百科上说写的“中国根服务器被关闭”是错的。这里只查到CNNIC的F-ROOT，按照前文的说法，应该还有一个中国电信的F-ROOT，也许需要中国电信的IP才能查得到这个F－ROOT的位置。
J-ROOT也在北京：

C:Userschenshaoju>tracert 192.58.128.30
通过最多 30 个跃点跟踪到 j.root-servers.net [192.58.128.30] 的路由:
 1     5 ms     3 ms     3 ms  10.20.0.1 2     4 ms     4 ms     3 ms  10.20.0.1 3    24 ms     5 ms     9 ms  58.215.156.185 4     7 ms     5 ms     6 ms  58.215.156.185 5    10 ms     9 ms     7 ms  202.97.39.113 6     8 ms    11 ms    11 ms  202.97.48.30 7    27 ms    26 ms    26 ms  219.158.32.93 8    33 ms    32 ms    31 ms  219.158.13.21 9    30 ms    40 ms    30 ms  123.126.0.6610     *       30 ms     *     61.51.112.4211   138 ms   134 ms   136 ms  61.148.156.20212    37 ms    33 ms    33 ms  bt-235-194.bta.net.cn[202.106.235.194]13    25 ms    36 ms    32 ms  j.root-servers.net[192.58.128.30]跟踪完成。

tracert  I-ROOT的IP居然跑日本去了：

C:Userschenshaoju>tracert 192.36.148.17
通过最多 30 个跃点跟踪到 i.root-servers.net [192.36.148.17] 的路由:
 1     5 ms     4 ms     3 ms  10.20.0.1 2    10 ms     3 ms     4 ms  10.20.0.1 3     9 ms     4 ms     3 ms  58.215.135.21 4     7 ms    15 ms    14 ms  58.215.135.41 5     7 ms    15 ms    71 ms  202.97.27.6 6    25 ms    15 ms    11 ms  202.97.82.53 7    24 ms     8 ms    10 ms  202.97.50.250 8    41 ms    39 ms    39 ms  202.97.35.22 9    15 ms    13 ms    13 ms  202.97.60.9710   269 ms   266 ms   266 ms  202.232.8.12911   202 ms     *        *     osk004bb11.IIJ.Net[58.138.106.201]12    97 ms     *      128 ms  osk004bf01.IIJ.Net[58.138.82.189]13     *        *        *     请求超时。14   273 ms     *        *     tky001bb10.IIJ.Net[58.138.80.14]15   177 ms     *        *     tky001ix04.IIJ.Net[58.138.100.26]16     *        *      185 ms  as8674.dix-ie.jp [202.249.2.180]17   117 ms     *      125 ms  i.root-servers.net[192.36.148.17]
跟踪完成。

换个服务器

C:Documents and SettingsAdministrator>tracert 192.36.148.17
Tracing route to i.root-servers.net [192.36.148.17]over a maximum of 30 hops:
 1     5 ms     3 ms     2 ms  htuidc.bgp [42.51.7.65] 2     3 ms     2 ms     2 ms  htuidc.bgp.ip [103.22.188.65] 3     3 ms     2 ms     2 ms  route53.htu.cc [103.22.188.53] 4    12 ms     4 ms     1 ms  hn.kd.ny.adsl [182.118.124.17] 5     4 ms     1 ms     1 ms  pc177.zz.ha.cn [61.168.124.177] 6    58 ms    55 ms    56 ms  pc137.zz.ha.cn [61.168.255.137] 7    53 ms    53 ms    53 ms  219.158.99.153 8   114 ms   122 ms     *     219.158.3.222 9   163 ms     *      148 ms  219.158.97.5410   270 ms     *      205 ms  219.158.38.9811     *      244 ms   237 ms  ae-1.r01.tokyjp01.jp.bb.gin.ntt.net [129.250.3.241]12    93 ms    95 ms    97 ms  peering.r1.jpp.dnsnode.net [210.173.176.43]13   299 ms    69 ms   297 ms  i.root-servers.net [192.36.148.17]
Trace complete.

还是去日本了，看来用无锡电信、北京互联通和河南的网络接入均无法证明i-root在不在中国。据宫一鸣说：

其中I节点在2010年的GFW故障中因为给海外返回被污染的dns记录曾被人骂得狗血喷头，管理员满世界哭诉和他们无关, 有兴趣的可以翻翻这个陈年旧事  https://lists.dns-oarc.net/pipermail/dns-operations/2010-March/005260.html

看来I-Root节点自从2010年在国际上闯祸后就关闭路由通告了，一直没广播，难怪在国内也用tracert追踪不到i-root节点。

第一次tracert L-ROOT的IP也跑日本去了，估计是陈少举住的无锡访问日本更快。第二次换河南服务器：

C:Documents and SettingsAdministrator>tracert 199.7.83.42
Tracing route to l.root-servers.net [199.7.83.42]over a maximum of 30 hops:
 1    13 ms     3 ms     2 ms  htuidc.bgp [42.51.7.65] 2     3 ms     3 ms     2 ms  htuidc.bgp.ip [103.22.188.65] 3     3 ms     3 ms     2 ms  route53.htu.cc [103.22.188.53] 4     2 ms     9 ms     2 ms  hn.kd.ny.adsl [182.118.124.17] 5     2 ms     1 ms     2 ms  hn.kd.ny.adsl [125.45.253.25] 6    62 ms    63 ms    63 ms  pc233.zz.ha.cn [61.168.194.233] 7    22 ms    19 ms    19 ms  219.158.98.217 8    18 ms    15 ms    15 ms  202.96.12.190 9     *        *        *     Request timed out.10    18 ms    33 ms    19 ms  202.106.37.15411    16 ms    35 ms    16 ms  61.49.41.7412    16 ms    15 ms    16 ms  l.root-servers.net [199.7.83.42]
Trace complete.

这次得了一个中国的的L-ROOT了，离L-ROOT最近的61.49.41.74 是一个北京联通IP http://www.ip.cn/index.php?ip=61.49.41.74
目前证明F-ROOT、J-ROOT、L-ROOT都有镜像在中国北京。而在 http://www.root-servers.org 这个页面上搜索Beijing，则显示F、I、J、L四个服务器都有镜像在中国北京。

目前，全球共有13台套根域名服务器，其中美国10个，欧洲2个（位于英国和瑞典）、亚洲1个（位于日本），并在全球部署有三百多个根镜像服务节点，在中国大陆地区有5个，覆盖了F、I、J、L 根。其中，F 根由ISC（Internet Systems Consortium）机构与CNNIC合作，在北京建设了两个F根镜像服务节点，由中国电信和CNNIC分别提供网络接入；Verisign与中国联通合作，在北京建设了J根镜像服务器，中国联通提供接入。另外两个由CNNIC提供网络机房环境分别与Netnod、ICANN合作，在北京建设了I、L根镜像服务节点。目前中国还有相关机构继续与国际合作实施更多的根镜像节点。

这样说就对了，F-ROOT有两个，I-ROOT、J-ROOT和L-ROOT各一个，CNNIC的F-ROOT找到了，但中国电信的F-ROOT没在中国找到，I-ROOT我也没有办法证明在中国。也许哪位读者可以tracert一下找到，若能找到，麻烦贴下tracert结果吧。

我发现 gtld-servers也是13个，我以为跟F-ROOT这些有什么关系呢，这个 b.gtld-servers.net 好像也在北京有一份：

C:Userschenshaoju>tracert 192.33.14.30
通过最多 30 个跃点跟踪到 b.gtld-servers.net [192.33.14.30] 的路由:
 1     8 ms     5 ms     7 ms  10.20.0.1 2     3 ms     3 ms     5 ms  10.20.0.1 3     7 ms     7 ms     6 ms  61.177.102.105 4     5 ms     4 ms     6 ms  61.177.102.105 5     8 ms     7 ms     7 ms  202.97.39.233 6    15 ms    11 ms    11 ms  202.97.48.42 7    94 ms    98 ms    96 ms  219.158.35.89 8   134 ms   134 ms   214 ms  219.158.5.217 9    70 ms    34 ms    32 ms  123.126.0.7010     *       38 ms     *     124.65.56.1811    37 ms    29 ms    30 ms  61.148.6.4212    40 ms    37 ms    36 ms  bt-235-194.bta.net.cn [202.106.235.194]13    36 ms    51 ms    45 ms  b.gtld-servers.net [192.33.14.30]
跟踪完成。

离 b.gtld-servers.net 最近的IP 202.106.235.194 是联通的。

现在的问题是，不知道 在中国境内的F、I、J、L这五个根域名服务器，还有类似 b.gtld-servers.net 这样的顶级域名服务器在污染DNS方面做了些什么，不过可以合理怀疑中国的DNS根服务器不诚实，证据在下面两个链接中，这个事件发生在2010年：

2010年 ，有荷兰在线报道说《中国网络审查一不小心审出了国境》

3月24日，智利的一名域名解析系统（DNS）管理人员发现互联网信息流通出现异常，向Youtube、Twitter、Facebook发出的访问要求均被劫持到中国的假网站和IP地址。

这个链接也说外国网络用户得到了来自这个中国根域名服务器污染后的Twitter、Facebook、YouTube的IP地址。


第四部分 结论


DNS查询过程介绍

下次遇到类似今天的根域名服务返回假IP地址时如何查证呢？我建议步骤如下：
  1. 先确定F-ROOT、I-ROOT、J-ROOT、L-ROOT的IP存活于中国境内，方法就是tracert这几个镜像的IP，他们的IP是全球统一的，但映射多个主机，你要确认离你网络最近的根域名主机是在线的。根域名主机的IP到这找 http://www.internic.net/domain/named.root 
  2. 打开命令行，输入nslookup
  3. 然后输入set q=PTR
  4. 输入server 192.5.5.241
  5. 随便输入一个.com的域名，如 zuola.com
  6. 此时会返回 一串结果告诉你权威回答应该会在哪里：Authoritative answers can be found from:
    com nameserver = h.gtld-servers.net.
    com nameserver = j.gtld-servers.net.
    com nameserver = k.gtld-servers.net.
    com nameserver = g.gtld-servers.net.
    com nameserver = m.gtld-servers.net.
    com nameserver = i.gtld-servers.net.
    com nameserver = c.gtld-servers.net.
    com nameserver = f.gtld-servers.net.
    com nameserver = a.gtld-servers.net.
    com nameserver = d.gtld-servers.net.
    com nameserver = e.gtld-servers.net.
    com nameserver = b.gtld-servers.net.
    com nameserver = l.gtld-servers.net.
    a.gtld-servers.net internet address = 192.5.6.30
    b.gtld-servers.net internet address = 192.33.14.30
    c.gtld-servers.net internet address = 192.26.92.30
    d.gtld-servers.net internet address = 192.31.80.30
    e.gtld-servers.net internet address = 192.12.94.30
    f.gtld-servers.net internet address = 192.35.51.30
    g.gtld-servers.net internet address = 192.42.93.30
    h.gtld-servers.net internet address = 192.54.112.30
    i.gtld-servers.net internet address = 192.43.172.30
    j.gtld-servers.net internet address = 192.48.79.30
    k.gtld-servers.net internet address = 192.52.178.30
    l.gtld-servers.net internet address = 192.41.162.30
    m.gtld-servers.net internet address = 192.55.83.30
    a.gtld-servers.net has AAAA address 2001:503:a83e::2:30
  7. 输入 server 192.5.6.30
  8. 输入zuola.com
  9. 此时返回 Server: 192.5.6.30
    Address: 192.5.6.30#53
    Non-authoritative answer:
    *** Can’t find zuola.com: No answer
    Authoritative answers can be found from:
    zuola.com nameserver = ns1.dreamhost.com.
    zuola.com nameserver = ns2.dreamhost.com.
    ns1.dreamhost.com internet address = 66.33.206.206
    ns2.dreamhost.com internet address = 208.96.10.221
  10. 上面返回的结果里包含了真正的nameserver的域名和IP，输入 server 66.33.206.206
  11. 会返回> server 66.33.206.206
    Default server: 66.33.206.206
    Address: 66.33.206.206#53
  12. 输入set q=a
  13. 输入zuola.com 
  14. 返回> zuola.com
    Server: 66.33.206.206
    Address: 66.33.206.206#53
    Name: zuola.com
    Address: 69.163.141.215
  15. 这样，就查到域名zuola.com 的真实IP为 69.163.141.215 了
第一步先是找到最近的根域名，第二步根域名返回gTLD地址，第三步gTLD返回name server地址和IP，第四步name server返回域名的真实IP。

ROOT Server返回域名应该去哪个gTLD找，gTLD提供一个最近的服务器告诉你哪个域名解析服务器(name server)上记录了你的域名对应的IP，gTLD的服务器上亦登记了域名解析服务器(name server)的域名和真实IP,在我的例子中，ns1.dreamhost.com和66.33.206.206的信息就记录在gtld-servers.net的A到M的13台服务器上。

下面这张图更清晰的描述的DNS解析过程：

2014年1月21日下午3点左右的dig操作却没有上图的第二步和第三步返回gTLD server和name server过程，直接跳过name server这个环节返回了一个65.49.2.178的地址，下面两张图都没有gTLD服务器出现，也没有name server，所用延时极短就返回65.49.2.178这个假IP。第一张图显示只用了27毫秒，第二张图显示只用了36毫秒。


我的理解是，机房的边界路由器上有一个GFW，把正常查询DNS的UDP结果污染了，由于要路过GFW，所以返回了一个假的IP。前些年GFW只在中国出境流量上污染DNS查询结果，现在机房流量也要被GFW审查了。

我的结论是，这是一次中国境内的DNS污染事故，是尝试在机房的GFW审查设备做网络封锁时做出的honest mistake（无意犯下的过错），可能是封锁自由门的IP时操作成封锁所有域名了。

来自周曙光的BLOGSPOT空间

14 thoughts on “中国的域名解析到65.49.2.178 是一个什么失误？”

  2. tracert 192.5.5.241

    Tracing route to f.root-servers.net [192.5.5.241]
    over a maximum of 30 hops:

    1 4 ms 3 ms 3 ms e6500 [10.97.37.142]
    2 93 ms 81 ms 92 ms 14.147.44.1
    3 44 ms 36 ms 38 ms 137.32.63.58.broad.gz.gd.dynamic.163data.com.cn [58.63.32.137]
    4 36 ms 30 ms 53 ms 113.98.103.117
    5 28 ms 65 ms 29 ms 61.144.3.22
    6 72 ms 69 ms 67 ms 202.97.34.121
    7 * * 143 ms bj141-158-118.bjtelecom.net [219.141.158.118]
    8 72 ms 100 ms 82 ms 18.254.120.106.static.bjtelecom.net [106.120.254.18]
    9 69 ms 66 ms 70 ms 219.142.18.54
    10 121 ms 202 ms 202 ms 218.241.102.101
    11 63 ms 70 ms 61 ms 218.241.107.90
    12 140 ms 144 ms 133 ms f.root-servers.net [192.5.5.241]

    回复

  4. 我觉得这次.com 域名网站瘫痪似乎跟这些“通用顶级域名根”没有关系，要让这些“任播”地址出现错误回答的提前是要把这13个gtld-server都在国内建个镜像。目前只发现b.gtld-server.net (192.33.14.30)在中国有镜像。

    回复

  7. 没有办法确认 I.

    $ traceroute 192.36.148.17
    traceroute to 192.36.148.17 (192.36.148.17), 30 hops max, 60 byte packets
    1 192.168.0.1 (192.168.0.1) 2.927 ms 3.643 ms 4.884 ms
    2 123.119.184.1 (123.119.184.1) 40.759 ms 44.242 ms 45.985 ms
    3 123.126.27.41 (123.126.27.41) 46.603 ms 47.843 ms 54.461 ms
    4 124.65.56.21 (124.65.56.21) 56.452 ms 57.075 ms 58.938 ms
    5 202.96.12.21 (202.96.12.21) 64.555 ms 65.297 ms 66.033 ms
    6 219.158.101.178 (219.158.101.178) 98.644 ms 75.500 ms 140.181 ms
    7 219.158.4.226 (219.158.4.226) 150.392 ms 153.130 ms 154.740 ms
    8 219.158.97.78 (219.158.97.78) 199.112 ms 200.466 ms 204.579 ms
    9 * * *
    10 * * *
    11 * * peering.r1.jpp.dnsnode.net (210.173.176.43) 183.454 ms
    12 i.root-servers.net (192.36.148.17) 162.787 ms 171.917 ms 207.917 ms

    回复

  8. "我们可以公开查到，65.49.2.178 属于美国 HE 公司。根据 HE 公司的记录，它把 65.49.2.1-65.49.2.255 这些 IP 租给了一家叫做 Sophidea, Inc. 的公司。再查一下这些 IP 下的具体域名，赫然发现，有一个叫 ultrasurf.us 的网站，就是著名的翻墙软件，“无界浏览器”。

    既然是这样，我们就可以推测，是 GFW 的操作员原本想封锁此 IP 或污染此域名，但却填错地方了。

    回复

  9. GFW干扰ROOT Server的意义并不大。
    楼主说的很对，负责COM和NET解析的13台GTLDs Server中，有 b.gtld-servers.net 在北京有镜像，访问这台原本是无需经过GFW的。而其余12台GTLDs在国外，都是经过GFW的，因此污染一直存在。所以有理由怀疑，此次GFW应该是针对 b.gtld-servers.net 北京镜像机房进行的污染，但配置失误造成影响，因此这也解释了为什么国内有些地区影响重，有些地区影响轻。

    Windows CMD下 nslookup -type=a http://www.520yx.com a.gtld-servers.net 看到的是污染后的返回结果。
    nslookup -type=a http://www.520yx.com b.gtld-servers.net 看到的是没有污染的结果。

    520yx.com 在GFW黑名单上。

    回复

  13. 之前只在国际出口进行污染。

    而国内有几个Root server镜像。

    国内有一个gTLD server镜像。

    假设国际出口的GFW污染了abc.com。

    而通过国内的f root server，可以获取到正确的gtld服务器。

    接着通过b gtld server，于是可以获取到正确的Name Server

    假设Name server在国内，于是向Name server请求A记录，也就可以获得。

    这就是GFW的一个洞啊，校长哪里会睡得着觉啊。

    回复

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据。