(本人不是专业人士,如有错误请指正 , 2014年)
在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的污染估计是全国性的,发生在国际出口处。
另:关于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:xxx::xx 服务器: 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问题,仍然需要挂代理解决
引用: 解决DNS污染 – Just another WordPress site