标签：tcp question 运营商 target 基本 lag 黑名单 服务 全面
网站被劫持了怎么办？
域名是否被墙。
DNS污染如何检测。 网站劫持检测
网站打开速度检测。
检测网站是否被黑、被入侵、被改标题、被挂黑链。
在G+上碰到了出现DNS相关问题的网友，于是今天又测试了一下DNS的现状。整个过程很简单，只需一个命令即可：nslookup
在Windows的命令提示符下测试，基本的格式为：
nslookup DOMAIN DNS_IP
而国内的DNS问题基本分两种：
DNS记录劫持是指DNS服务器上的DNS记录被恶意设定为不正确的内容。DNS劫持是长期的，不经手动更改不会修复。
一类是政策问题导致国内DNS会劫持某些站点，GFW你懂的。而另一类：
ISP为了其自身利益（妨碍访问竞争对手WZ、植入广告等等）进行的DNS劫持，这个在国内ISP中普遍存在，都有劫持DNS的能力。特点是，域名解析结果会一股脑的指向同一个IP，下面我们拿我所在的青岛联通的默认DNS（202.102.128.68）试试，得到以下两类结果：
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以下这个不存在的域名来看看到底被指向到哪里了：
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
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看看最终连接到哪里了：
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的三个地址：
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+无法打开，而在家里的铁通网实测是没有劫持的：
C:Userscokebar>ping plus.google.com
正在 Ping plus.google.com [74.125.39.102] 具有 32 字节的数据:
请求超时。
请求超时。
不过IPv6幸免于难可以连接并正常打开G+：
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记录存在一个生存期（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阻断：
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的情况：
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上：
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无事：
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问题，仍然需要挂代理解决
标签：tcp question 运营商 target 基本 lag 黑名单 服务 全面
原文地址：https://www.cnblogs.com/asd667/p/9896206.html
