国内DNS劫持与污染状况分析

在G+上碰到了出现DNS相关问题的网友，于是今天又测试了一下DNS的现状。整个过程很简单，只需一个命令即可：nslookup

在Windows的命令提示符下测试，基本的格式为：

1	nslookup DOMAIN DNS _IP

而国内的DNS问题基本分两种：

一、DNS记录劫持

DNS记录劫持是指DNS服务器上的DNS记录被恶意设定为不正确的内容。DNS劫持是长期的，不经手动更改不会修复。

一类是政策问题导致国内DNS会劫持某些站点，GFW你懂的。而另一类：

ISP为了其自身利益（妨碍访问竞争对手网站、植入广告等等）进行的DNS劫持，这个在国内ISP中普遍存在，都有劫持DNS的能力。特点是，域名解析结果会一股脑的指向同一个IP，下面我们拿我所在的青岛联通的默认DNS（202.102.128.68）试试，得到以下两类结果：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

C :Userscokebar >nslookup baidu .com 202 .102 .128 .68 服务器 :   ns .sdjnptt .net .cn Address :   202 .102 .128 .68   非权威应答 : 名称 :     baidu .com .lan Address :   220 .250 .64 .228   C :Userscokebar >nslookup facebook .com 202 .102 .128 .68 服务器 :   ns .sdjnptt .net .cn Address :   202 .102 .128 .68   非权威应答 : 名称 :     facebook .com .lan Address :   220 .250 .64 .228   C :Userscokebar >nslookup duowan .com 202 .102 .128 .68 服务器 :   ns .sdjnptt .net .cn Address :   202 .102 .128 .68   非权威应答 : 名称 :     duowan .com .lan Address :   220 .250 .64 .228   C :Userscokebar >nslookup taobao .com 202 .102 .128 .68 服务器 :   ns .sdjnptt .net .cn Address :   202 .102 .128 .68   非权威应答 : 名称 :     taobao .com .lan Address :   123 .129 .254 .19

一种是全劫持到123.129.254.18/123.129.254.19这两个地址，经查属于山东省济南市联通

另一种是劫持到220.250.64.228这个地址，经查是北京市联通

同时域名名称也在末尾多出了一个”.lan”

至此得出结论，202.102.128.68这个DNS并不是其实际的DNS服务器，他只是完成DNS劫持的使命的。下面分析一下整个的过程：

假如你通过浏览器访问google.com，那么202.102.128.68向你返回了123.129.254.18，于是你向这个IP发出了相应的打开google.com主页的请求，而这个请求被123.129.254.18这个服务器收到后，他会根据事先设定的规则判断，如果规则里说不对这个域名进行干扰，那么你的访问请求就会被forward到真正的google.com的服务器上去，可能对于大部分网站都属于这个情况，整个过程比直接返回真实IP慢不了多少，从延迟上肯定分辨不出。

而如果你要访问的域名在黑名单上，或者你输入了一个错误的不存在的域名，那么服务器处理的方式就多种多样了：

1、对于不存在的域名，直接返回一个联通预定义的提示你“输入的域名不存在”的网页，在提示用户的同时还能植入点广告可谓是一举两得，这个还属于良性的，比如说我将DNS改为联通的DNS，随便敲了个域名，得到下面的页面：http://nfdnserror17.wo.com.cn:8080/sdjc/self0.jsp?UserUrl=

我们可以ping以下这个不存在的域名来看看到底被指向到哪里了：

1 2 3 4

C :Userscokebar >ping dfslaw343412 .com   正在 Ping dfslaw343412 .com [220 .250 .64 .228 ] 具有 32 字节的数据 : 来自 220 .250 .64 .228 的回复 : 字节 =32 时间 =21ms TTL =247

再ping一下nfdnserror17.wo.com.cn

1 2 3 4

C :Userscokebar >ping nfdnserror17 .wo .com .cn   正在 Ping nfdnserror17 .wo .com .cn [220 .250 .64 .228 ] 具有 32 字节的数据 : 来自 220 .250 .64 .228 的回复 : 字节 =32 时间 =20ms TTL =247

可以看到得到的结果正是220.250.64.228这个IP，上面提到了，部分域名被劫持到这个IP。

2、forward到一个不正确的IP地址，导致无法连接服务器或者其他奇怪的现象，通常只针对被特殊照顾的极少数国外站点，比如说twitter可是说是重点照顾，facebook、youtube都没像twitter那样有DNS劫持+污染、封IP、TCP_RESET等那么全面的封锁形式。

我们可以试着ping以下twitter看看最终连接到哪里了：

1 2 3 4

C : Userscokebar > ping twitter . com   正在 Ping twitter . com [ 59.24.3.173 ] 具有 32 字节的数据 : 请求超时。

可以看到被指向了59.24.3.173这一无法访问的IP。我们通过nslookup的-v参数来通过TCP方式查询google DNS看到真正的地址是199.59.X.X的三个地址：

1 2 3 4 5 6 7 8 9

C :Userscokebar >nslookup -v twitter .com 8 .8 .8 .8 服务器 :   google -public -dns -a .google .com Address :   8 .8 .8 .8   非权威应答 : 名称 :     twitter .com Addresses :   199 .59 .148 .82           199 .59 .150 .7           199 .59 .149 .198

杯具的是G+同样遭受联通的劫持，IPv4被解析到google其他服务器的IP上去了，导致G+无法打开，而在家里的铁通网实测是没有劫持的：

1 2 3 4 5

C :Userscokebar >ping plus .google .com   正在 Ping plus .google .com [74 .125 .39 .102 ] 具有 32 字节的数据 : 请求超时。 请求超时。

不过IPv6幸免于难可以连接并正常打开G+：

1 2 3 4 5 6

C :Userscokebar >ping plus .google .com   正在 Ping plus -china .l .google .com [2404 :6800 :4005 :806 ::1009 ] 具有 32 字节的数据 :   来自 2404 :6800 :4005 :806 ::1009 的回复 : 时间 =288ms 来自 2404 :6800 :4005 :806 ::1009 的回复 : 时间 =288ms

3、植入广告。返回一个带有广告的网页并将原网页嵌套进去，看起来就像你访问的站点放的广告一样，这个其实算违法了，以前这情况挺多，现在还这样搞的ISP没那么多了。

 

综上,DNS中间过了这么一道关后，实际劫不劫持全看ISP自己，虽然多数情况不会发生（被特殊照顾的某些国外网站除外 这些是必劫持），不过还是存在部分域名在部分省市存在劫持现象，影响正常访问某些站点或者被植入广告。

解决办法自不用说，对于多数ISP，如联通电信，使用114DNS通常没有问题，将DNS改为114.114.114.114/114.114.115.115，114DNS为各大运营商做DNS记录备份，号称无劫持，不过其实某些站点还是有劫持的比如说twitter，不过还好G+是完好的。

[2014.2.27]今天又使用了校园网测试，发现114DNS对于教育网政策不同，存在不解析Google的部分域名，劫持facebook等站点的现象，114DNS也不是最佳方案，对于这些站点还是老老实实挂上代理比较好。

 

二、DNS记录污染

DNS记录污染，指的是有人通过恶意伪造身份、利用漏洞等方式，向用户或者其他DNS服务器提供虚假的DNS记录。由于DNS记录存在一个生存期（TTL），在生存期内，DNS保存在缓存中，除非经过了大于一个TTL的时间，或者经手工刷新DNS缓存，虚假的记录会一直存在下去，并且如果污染了DNS服务器，这种污染还具有传染性。

DNS污染具有暂时性，过了TTL周期，如果不进行再污染，污染就会消失。

DNS记录污染同劫持的不同之处，在于污染是对本来正确的DNS查询结果进行篡改，而劫持是DNS服务器自己把记录改成错误的内容。对于GFW来说，DNS劫持用于国内服务器，而对于国外服务器GFW无法更改其内容，故采用DNS污染方式篡改用户收到的信息。

GFW的DNS污染过程，是当你向国外DNS服务器查询DNS记录时候，这些流量走到国外出口处即会遭到GFW的关键字审查，如果上了黑名单，GFW会立即向你返回一个虚假的DNS记录。由于默认的DNS查询方式是UDP，加上DNS查询结果只认最快返回的结果，所以你一定是先收到了GFW给你返回的虚假DNS记录；就算100ms后你收到了真正的来自国外DNS的回复，那也会被你的系统无视掉。如果GFW想彻底污染一个域名，那么不只是普通用户，连国内所有的DNS服务器也会收到虚假的DNS纪录导致全国性的DNS污染。

前一段，不明原因的发生了国内大规模的DNS污染事件，国内大部分站点和部分地区均受到影响无法通过域名访问。这必定与GFW强大的DNS污染能力有关。

不过不仅仅是国外出口处DNS记录可能污染，各省市的ISP也可能利用现有GFW的技术进行自己的DNS污染，这种污染范围小一些，也是GFW的一环。

防止DNS污染的方法目前来说就是使用TCP协议代替UDP来进行DNS查询，因为TCP协议是有连接的协议需要双方握手成功才能通讯，从而避免GFW这种简单的DNS污染方式。目前GFW对于TCP方式的DNS查询其实已有阻断能力，但未大规模部署，目前貌似只有dl.dropbox.com会遭遇TCP阻断：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

C :Userscokebar >nslookup -v -d dl .dropbox .com 8 .8 .8 .8 -- -- -- -- -- -- Got answer :     HEADER :         opcode = QUERY , id = 1 , rcode = NOERROR         header flags :   response , want recursion , recursion avail .         questions = 1 ,   answers = 1 ,   authority records = 0 ,   additional =       QUESTIONS :         8 .8 .8 .8 . in -addr .arpa , type = PTR , class = IN     ANSWERS :      ->   8 .8 .8 .8 . in -addr .arpa         name = google -public -dns -a .google .com         ttl = 15619 (4 hours 20 mins 19 secs )   -- -- -- -- -- -- 服务器 :   google -public -dns -a .google .com Address :   8 .8 .8 .8   read failed : Result too large read failed : Result too large read failed : Result too large read failed : Result too large * * * google -public -dns -a .google .com 找不到 dl .dropbox .com : Unspecified error

然而遗憾的是，目前主流的操作系统，如果不借助第三方软件是无法将系统的DNS查询方式从默认的UDP改成TCP的，实现起来颇为不便。

下面我们测试一下通过google dns：8.8.8.8来查询twitter.com的情况：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

C :Userscokebar >nslookup -v twitter .com 8 .8 .8 .8 服务器 :   google -public -dns -a .google .com Address :   8 .8 .8 .8   非权威应答 : 名称 :     twitter .com Addresses :   199 .59 .148 .82           199 .59 .150 .7           199 .59 .149 .198   C :Userscokebar >nslookup twitter .com 8 .8 .8 .8 服务器 :   google -public -dns -a .google .com Address :   8 .8 .8 .8   非权威应答 : 名称 :     twitter .com Addresses :   59 .24 .3 .173           243 .185 .187 .39

加了-v 参数的nslookup命令是通过TCP查询的，下面没有加 -v 的是通过默认UDP查询的结果，可以看到出现了不同的结果，证明GFW会对twitter.com进行DNS污染，twitter的污染估计是全国性的，发生在国际出口处。

同样，在这里通过8.8.8.8查询plus.google.com也出现了DNS污染，解析出的IP同样是谷歌的服务器然而并不是提供G+服务的服务器，这样最直接的现象是无法连接服务器，同时也可能出现下图这种诡异的现象，而这样，就伪造出一种是谷歌服务器自己出问题的假象。

另：关于IPv6下状况的讨论

去年下半年，我在青岛这边测试，曾出现针对IPv6的非常严格的DNS劫持，并在不久后加入了DNS污染，后来甚至加入了极为严格的关键字审查策略，导致google许多页面遭遇tcp_reset，不过目前又逐步和IPv4的策略保持一致了。我当时测试的一个图，分别用IPv4和IPv6来ping G+：

IPv6时候返回了一个非常奇葩的[10::2222]的IPv6地址，假到离谱… 实测IPv6下也存在针对DNS的污染，而且会污染到比较奇葩的IP上：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

C :Userscokebar >nslookup plus .google .com 2001 :4860 :4860 ::8888 服务器 :   google -public -dns -a .google .com Address :   2001 :4860 :4860 ::8888   名称 :     plus .google .com .lan Addresses :   2001 :da8 :112 ::21ae           1 .1 .1 .1   C :Userscokebar >nslookup -v plus .google .com 2001 :4860 :4860 ::8888 服务器 :   google -public -dns -a .google .com Address :   2001 :4860 :4860 ::8888   非权威应答 : 名称 :     plus -china .l .google .com Addresses :   2404 :6800 :4005 :804 ::1006           74 .125 .31 .102           74 .125 .31 .139           74 .125 .31 .100           74 .125 .31 .113           74 .125 .31 .138           74 .125 .31 .101 Aliases :   plus .google .com

而联通DNS和学校的DNS的状况都是只对IPv4做了劫持，IPv6无事：

1 2 3 4 5 6 7 8 9

C :Userscokebar >nslookup plus .google .com 2001 :da8 :7007 :107 ::77 服务器 :   ns2 .dnscache .upc .edu .cn Address :   2001 :da8 :7007 :107 ::77   非权威应答 : 名称 :     plus -china .l .google .com Addresses :   2404 :6800 :4005 :c00 ::66           74 .125 .39 .102 Aliases :   plus .google .com

不过目前GFW对IPv6的研究不足还无法做到像IPv4上那样的方式屏蔽youtube和facebook，开了https，规避了关键字审查后就能通过IPv6正常浏览了，而IPv4下就算你开了https你也上不了。

 

总结

 

DNS这种方式在设计出来后就遗留给了我们这样那样的安全问题，要伪造DNS记录太简单了，让其成为了GFW前期封杀网站的得力手段。不过通过DNS封杀风险也不小，出国前不久的全国性DNS污染事件，还有更早些时候GFW污染了国外DNS服务器导致某些国外国家无法正常上网的事件。同样DNS也是ISP植入广告、屏蔽竞争对手网站的给力方式。

 

就目前来说，对于联通、电信、移动之类的多数ISP，使用114DNS是较好的解决方案，在规避ISP恶意劫持DNS的同时，保证了像G+这样的能直连的google服务器的访问，而google DNS建议弃用吧，不像前几年好用了，现在一来可能会遭遇DNS污染，二来google dns对国内某些CDN的支持可能不是太好，三来ping比较高。

如果是教育网等一些用114DNS仍然会有劫持的用户，可以考虑使用dns代理，这样可以保证谷歌站点的直连，而其他被墙站点多数不仅仅是dns问题，仍然需要挂代理解决