构造自己的微博客同步功能(四)DNS状态

作者:麦圆 来源:一五一十部落

上编说到如何简易连接上那些无法连接的网站。

然而,那些无法连接不的网站不是总是无法连接的。因为这些无法连接的网站中间加了一个过滤器,这个过滤器也是机器,机器也有失灵的时候。

万恶的资本主义阻止我们盗窃他们的科技机密,靠的就是这个过滤器。

经过观察,这个过滤器有两种工作方式。

方式1:通过把我国地区的DNS解析进行干扰破坏,或者制造通信“谎言”来导致我们的通信不正常。

方式2:通过禁止来自国内的ip连接,又或者检测连接里面某些属于资本主义机密的东西就进行切断。

当然,资本主义的封锁做法是万恶的,但是社会主义人民都是勤劳的、勇敢的、有智慧的,因此也能想出些来进行探测和绕过。

这编先说说,如何探测出DNS解析被破坏了。如何寻找出这个过滤器什么时候对DNS干扰失灵,从达到可以直接通信,不用绕路。

介绍一个Linux下的常用工具,名字叫“dig”。它是一个DNS的查询工具。无论是什么域名,只要你dig一下,就能查出这个域名的各项解析条目。

好比如,要了解Twitter的情况,只要输入 dig twitter.com 即可。在正常的情况下,它会出现包含形如如下部分的结果:

;; QUESTION SECTION:

;twitter.com. IN A


;; ANSWER SECTION:

twitter.com. 29 IN A 168.143.162.68


;; AUTHORITY SECTION:

twitter.com. 60163 IN NS ns4.p26.dynect.net.

twitter.com. 60163 IN NS ns1.p26.dynect.net.

twitter.com. 60163 IN NS ns2.p26.dynect.net.

twitter.com. 60163 IN NS ns3.p26.dynect.net.

;; ADDITIONAL SECTION:

ns1.p26.dynect.net. 146563 IN A 208.78.70.26

ns2.p26.dynect.net. 146563 IN A 204.13.250.26

ns3.p26.dynect.net. 146563 IN A 208.78.71.26

ns4.p26.dynect.net. 146563 IN A 204.13.251.26

;; Query time: 1 msec

;; SERVER: 66.147.243.13#53(66.147.243.13)

但是一旦遭遇过滤器,便出现另外一个结果:

;; QUESTION SECTION:

;twitter.com. IN A

;; ANSWER SECTION:

twitter.com. 86400 IN A 216.234.179.13

;; Query time: 38 msec

;; SERVER: 208.67.222.222#53(208.67.222.222)

看,"IN A"表示A记录的IP不同了,后面的AUTHORITY SECTION和ADDITIONAL SECTION也没有了。所以,只要dig对比不同,就知道是否过滤起作用了。

然而,如果不能有另外一个地方的结果作对比,那又如何呢?其实,是可以拿自己的结果做对比的。只要加上参数"+trace"就行了。

又继续以Twitter做例子,执行dig +trace twitter.com就行了,如果使用内地DNS(广东DNS 202.96.134.133)大概会出现如下结果:

; <<>> DiG 9.2.4 <<>> +trace twitter.com

;; global options: printcmd

. 57088 IN NS K.ROOT-SERVERS.NET.

. 57088 IN NS L.ROOT-SERVERS.NET.

. 57088 IN NS M.ROOT-SERVERS.NET.

. 57088 IN NS A.ROOT-SERVERS.NET.

. 57088 IN NS B.ROOT-SERVERS.NET.

. 57088 IN NS C.ROOT-SERVERS.NET.

. 57088 IN NS D.ROOT-SERVERS.NET.

. 57088 IN NS E.ROOT-SERVERS.NET.

. 57088 IN NS F.ROOT-SERVERS.NET.

. 57088 IN NS G.ROOT-SERVERS.NET.

. 57088 IN NS H.ROOT-SERVERS.NET.

. 57088 IN NS I.ROOT-SERVERS.NET.

. 57088 IN NS J.ROOT-SERVERS.NET.

;; Received 500 bytes from 202.96.134.133#53(202.96.134.133) in 83 ms

twitter.com. 86400 IN A 216.234.179.13

;; Received 56 bytes from 193.0.14.129#53(K.ROOT-SERVERS.NET) in 121 ms

要注意的是,如果使用OpenDNS是无法得到上面的结果,而只会出现下面的情况:

;; global options: printcmd

;; Received 17 bytes from 208.67.222.222#53(208.67.222.222) in 344 ms

这确实是资本主义的封锁,因此,如果你想能使用trace功能,应该使用内地的DNS,在查询命令加上一个参数@202.96.134.133即可,即执行:dig @202.96.134.133 +trace twitter.com

这有什么特别呢?换一个正常的域名吧,例如google.com,则会出现:

;; global options: printcmd

. 56758 IN NS L.ROOT-SERVERS.NET.

. 56758 IN NS M.ROOT-SERVERS.NET.

. 56758 IN NS A.ROOT-SERVERS.NET.

. 56758 IN NS B.ROOT-SERVERS.NET.

. 56758 IN NS C.ROOT-SERVERS.NET.

. 56758 IN NS D.ROOT-SERVERS.NET.

. 56758 IN NS E.ROOT-SERVERS.NET.

. 56758 IN NS F.ROOT-SERVERS.NET.

. 56758 IN NS G.ROOT-SERVERS.NET.

. 56758 IN NS H.ROOT-SERVERS.NET.

. 56758 IN NS I.ROOT-SERVERS.NET.

. 56758 IN NS J.ROOT-SERVERS.NET.

. 56758 IN NS K.ROOT-SERVERS.NET.

;; Received 500 bytes from 202.96.134.133#53(202.96.134.133) in 24 ms

com. 172800 IN NS a.gtld-servers.net.

com. 172800 IN NS b.gtld-servers.net.

com. 172800 IN NS c.gtld-servers.net.

com. 172800 IN NS d.gtld-servers.net.

com. 172800 IN NS e.gtld-servers.net.

com. 172800 IN NS f.gtld-servers.net.

com. 172800 IN NS g.gtld-servers.net.

com. 172800 IN NS h.gtld-servers.net.

com. 172800 IN NS i.gtld-servers.net.

com. 172800 IN NS j.gtld-servers.net.

com. 172800 IN NS k.gtld-servers.net.

com. 172800 IN NS l.gtld-servers.net.

com. 172800 IN NS m.gtld-servers.net.

;; Received 488 bytes from 199.7.83.42#53(L.ROOT-SERVERS.NET) in 300 ms

google.com. 172800 IN NS ns1.google.com.

google.com. 172800 IN NS ns2.google.com.

google.com. 172800 IN NS ns3.google.com.

google.com. 172800 IN NS ns4.google.com.

;; Received 164 bytes from 192.5.6.30#53(a.gtld-servers.net) in 509 ms

google.com. 300 IN A 74.125.127.100

google.com. 300 IN A 74.125.67.100

google.com. 300 IN A 74.125.45.100

;; Received 76 bytes from 216.239.32.10#53(ns1.google.com) in 339 ms

显然地,你会发现出了出现“. 56758 IN NS H.ROOT-SERVERS.NET.”包含在结果里面之外,还会有“com. 172800 IN NS k.gtld-servers.net.”这的部分。

根 据这里面的不同,针对.com域名(其他域名自己修改一下就行了),可以用命令来对结果进行简单处理,根据统计出“com. 172800 IN NS k.gtld-servers.net.”这些部分的行数,便能得知该域名是否被过滤了,例如检查twitter.com:

N=twitter.com ;dig +trace $N | grep 'com.' | grep -v $N | wc -l

执行后,在境内的网络用户,只要dig、grep、wc命令都能用,答案自然是输出0。

如果把twitter.com换成youtube.com(微博客都持续被过滤,因此改用著名视频网站做例子):

N=youtube.com ;dig +trace $N | grep 'com.' | grep -v $N | wc -l

由于针对youtube的过滤器不稳定,因此答案有时候是0,有时候是14,有的更少的可能是解乎于0到14之间的数字。

对于twitter.com这样一个总是出现0的域名,证明了封锁密度大,很少出现空隙,可以写一个脚本每10探测一次,看看它什么时候正常:

while [ 1 ]

do

P=`N=twitter.com ;dig +trace $N | grep 'com.' | grep -v $N | wc -l`

if [ "$P" != "0" ]

then

#这里正常,则显示当前时间

date

fi

sleep 10

done

当然,对于youtube.com这样的地址,虽然是题外话,但是因为它的不稳定性极高,可以把sleep 10改成sleep 1或者干脆去掉。

经过我的实验,如果长时间dig一个被过滤器处理的DNS地址后,过滤器会变得更多空隙,或者说过滤器不起作用的空隙频率更高。

一直下去的话,只要时间足够长,按照其趋势,过滤器就会不起作用,然后,我们去窃取资本主义高科技机密的阻碍就少了一个了。

那时候可以不再对这个域名用通过修改hosts文件的方法来绕行了。

下编把第二个探测方法也简单说说。

没有评论: