2014年1月24日星期五

关于中国境内用户访问.com 和.net 域名被解析到 65.49.2.178 一事我又有新发现

关于中国境内用户访问.com 和.net 域名被解析到65.49.2.178 一事我又有新发现,我发现了为什么.cn 和.org 的域名没有受到影响指向65.49.2.178的原因,证明此事事故与根域名服务器无关。

上一篇文章中,我查到了65.49.2.178这个IP的背景,验证了根域名服务器在中国有镜像,驳斥了各大媒体和维基百科上说“根域名服务器只有13台,亚洲唯一的一台在日本”的说法,猜测这事件是一次来自国内机房的DNS污染事故。

我注意到  国家互联网应急中心 的通告提到仅有“.com”、“.net”等结尾的网站受到影响,而.cn结尾的网站没有受到影响,.org 结尾的网站没有被提到,也应该是没有受到影响:
关于1月21日我国境内互联网访问异常情况的通报
来源:CNCERT 时间:2014-01-22
2014年1月21日15:20,中国境内大量互联网用户无法正常访问域名以“.com”、“.net”等结尾的网站。事件发生后,国家互联网应急中心第一时间启动应急响应机制,协调组织部分技术支撑单位进行调查和应急处置,16:50左右,用户访问基本恢复正常。
经对已掌握的数据进行分析,初步判断此次事件是由于网络攻击导致我国境内互联网用户通过国际顶级域名服务解析时出现异常,攻击来源正在进一步调查中。
为什么.cn 和 .org  结尾的网站没有受到影响?
我们先来看正常的域名解析过程:
  1. 第一步,DNS会返回“根域名服务器”地址和IP, 上图中是root-servers.net结尾的地址; 
  2. 第二步,根域名服务器192.33.4.12返回通用顶级域名(gTLD)的服务器地址和IP; 
  3. 第三步,gTLD服务器返回NS(name server)地址和IP,上图中是ns1.dreamhost.com; 
  4. 第四步,NS返回域名对应的真正的IP地址, 上图中是69.163.141.215。
下面是dig +trace zuola.com 和 dig +trace dbanotes.net 的结果,显示以“.com”、“.net”等结尾的域名在第二步返回的都是 gtld-server.net结尾的服务器地址; 而以“.org”的域名用的是另一种域名的服务器。


下面是dig +trace 1kg.org 这个域名的结果,同样需要向DNS发起第一步查询,返回的结果是相同的根域名服务器地址,第二步返回的却不是以 gtld-server.net结尾的服务器地址,是org.afilias-nst.org 和 org.afilias-nst.info 结尾的地址


下面是dig +trace hightechlowlife.cn 这个域名的结果,.cn 和 .org 的域名同样需要向DNS发起第一步查询,得到了正确的根域名服务器地址; 第二步返回的却不是 以gtld-server.net结尾的服务器地址,也不是以org.afilias-nst.org 和 org.afilias-nst.info 结尾的地址,是以dns.cn结尾的地址:


好了,.cn 和 .org 的域名同样需要向DNS发起第一步查询,也都得到与.com 跟.net 域名相同的“根域名服务器”查询结果了,仅有第二步返回的结果不同。这证明此次事件与“根域名服务器”完全没有关系。这样一区分,也许能解释为什么.cn 和.org 的域名没有受到影响了。

下图来自DNSPod的BLOG,证实2014年1月21日访问.com 域名会得到65.49.2.178这个IP:

没有返回返回通用顶级域名(gTLD)的服务器地址和IP,也没有返回name server 地址。

没有返回返回通用顶级域名(gTLD)的服务器地址和IP,也没有返回name server 地址。

我再贴一张2014年1月22日在中国境内用dig追踪twitter.com 域名解析过程的图片:

图片由陈少举提供

Twitter.com的域名被劫持到203.98.7.65这个IP了,从 http://whois.webhosting.info/203.98.7.65 来看,这个IP不是twitter的IP,表现和2014年1月21日的劫持域名到65.49.2.178完全一样:没有返回返回通用顶级域名(gTLD)的服务器地址和IP,也没有返回name server 地址。

完整无误的解析应该是如下图一样分四次返回数据:

图片由陈少举提供

结论:
我国境内互联网用户通过国际顶级域名服务解析时出现异常,“.com”、“.net”域名被解析到 65.49.2.178是一次DNS污染行为,和GFW污染Twitter.com 、Facebook.com Youtube.com 、 Zuola.com 等域名的表现是一致的,与根域名服务器完全无关。.cn 和 .org  结尾的网站没有受到影响则证明,可能是此次GFW不小心把gtld-servers.net 加入污染域名的列表了,下次遇到同样的部分域名受影响的话用用dig +trace gtld-servers.net来排查吧。

以上观点不一定绝对正确,欢迎补充可能性和证据。

写篇文章不容易,既然来都来了,请留言一下吧

现在已经有 7 条评论 :

  1. 实测国内网络+8888解析cn一样到那个ip了。。。同时外面网络用8888没有出现解析问题

    回复删除
    回复
    1. 你用GOOGLE DNS解析哪个CN域名出现同样IP?

      删除
    2. 陈皓说他的coolshell那天不能访问 http://weibo.com/1401880315/At5gX1tLS

      删除
  2. 博主的论证过程很正确,但是我觉得结论略有不对。这次的DNS解析问题跟封锁twitter, facebook表现一样,说明最有可能的就是GFW的问题。但是也不能完全排除在中国的那几个根域名服务器没有问题,所以我觉得两个都有可能。

    但是DNS根域名服务器的作用是,你给我一个.cn, .org, .com的域名,我告诉你这个gTLD的NS记录。具体点说(下面这句可能不对),就是根据这个文件返回结果 http://www.internic.net/domain/root.zone 。 (下面这句也有可能不对)而所有的DNS根服务器都是外国人或者外国公司负责管理,中国只负责提供机房,电源等。

    也就是说根服务器做的事情简单,且不由中国操作,再加上其他国家的根服务器都没出问题,只有中国出问题。那么是根服务器出错的可能性很小。

    回复删除
    回复
    1. 原来的理解是GFW只在中国与外国的连接中起过滤作用,现在看来GFW也在机房与机房之间过进行DNS干扰了,墙离网民更近了。

      删除
  3. 我.im的域名,当天下午dns污染后,想ssh出墙看看,结果ssh死活连不上,后来nslookup 114跟8888,返回的也是65这个。

    回复删除
  4. 自动的防污染DNS:bcs.duapp.com/raspberrypi/index.html

    回复删除