因为一个DNS服务器是不可能知道所有域名的地址的，因为这需要耗费极大地代价，所以这时候就出现了递归DNS和根DNS。（由于篇幅原因，就简单的说一下，其实还是有问题的。详细阐述下DNS的工作原理，或者看http://en.wikipedia.org/wiki/Domain_Name_System
根DNS是什么呢？大家想想，每个域名都有一个后缀,比如说[.info]后缀的域名，那么就有一个专门记录[.info]后缀的dns服务器，其他后缀也一样。这个DNS就是该域名的根DNS。
那么递归DNS呢？其实递归DNS就是一个代理人，是用来缓解[根DNS]压力的，如果大家都去问[根DNS]，那[根DNS]不早就跪了。毕竟一个人(网站)的地址不是经常变的，所以就有了TTL这一说法，根据DNS的规定，在一个TTL时间呢，大家就认为你家里(域名所指向的IP)的地址是不会变的，所以代理人[递归DNS]在这个时间内，是只会问一次[根DNS]的，如果你第二次问他，他就会直接告诉你域名所指向的IP地址。这样就可以解决[根DNS]负载过大的问题啦。
1.
说了这么久，口水都干了，那么DNS到底跟这次事件有什么关系呢~
首先来看张图：
2
这么多域名都指向同一个IP了，这是什么情况0 0。其实这就是典型的[DNS污染]了。
我们知道互联网有两种协议，一种是TCP，一种则是UDP了（知道泥煤啊(╯‵□′)╯︵┻━┻都说我不是学计算机的了）。
TCP和UDP的主要差别就是：能不能保证传递信息的可靠性。UDP是不管消息是否到达了目标，通过什么途径的，他只管我发出去了就好，所以UDP比TCP快得多，但是可靠性没有TCP好。
3
而DNS查询默认就是用的是UDP，那么就很好劫持啦。在UDP包任何传输的路途上，直接拦截，然后返回给接收端就行了。
啧啧，说道这大家也隐隐约约知道这次事件的问题了吧，范围如此之广的劫持，必须要在各个省市的主干网上进行，而能处理这么大数据，同时能控制这么多主干网的。。啧啧啧。。。没错！就是GFW了
说道这里，准备手动查一下，到底是不是所推测的GFW呢？于是拿到了这个图（From XiaoXin）
4
与此同时运维也在各地的服务器上开始了跟踪查询，发现全国各地解析时间均为25ms左右。这时候结论就出来了。
这样就明显了，肯定是GFW做的了~~于是又好奇的查了下，这个IP是什么来头，为什么都要指向到这里去，于是发现了一些好玩的东西~（http://bgp.he.net/net/65.49.2.0/24#_dns）
5
从侧面点出了此次事件的始作俑者。
那么某FW为什么要这么做呢？在这里做一个无责任的推测，最有可能的就是：某FW的员工本来是想屏蔽这个IP段的，但是呢一不小心点进去了DNS污染这个选项，然后又没写污染目标，于是就全局污染了啧啧啧~
但是有些童鞋会问了(╯‵□′)╯︵┻━┻为什么他们都说用8.8.8.8就没事了~
其实这样子说是不正确的，因为之前用的就是8.8.8.8，上面也说了DNS查询默认使用的UDP查询，所以不管你用什么，照样劫持不误。其实8.8.8.8没问题是因为污染事件已经基本结束导致的，那么为什么污染结束后其他国内DNS都不能用，而Goole的DNS确可以正常的使用~于是就找到了张有趣的图片~
6
我先来解释下上面命令的用途吧~这个命令是用来直接向DNS服务器查询域名的~
其中的[-vc]参数是强制使用TCP来查询DNS服务器，这样就可以避免UDP污染。
那么为什么污染结束后，DNS还会受到污染呢？其实原因很简单。之前说了，[递归DNS]是需要询问[根DNS]的，而默认的询问方式是采用的UDP，所以在国内的DNS服务器，自然就受到污染了。而之前也提到过TTL这件事~
在TTL周期内，根据协议[递归DNS]是直接吧结果缓存在自己那，是不会再去查询[根DNS]的，所以国内的DNS就把错误的结果缓存起来了~
而Google的DNS服务器基本都是在国外，所以查询的时候影响并不大，但是国内挺多域名使用DNSPOD啦，DNSLA的DNS，所以Google进国内查，还是会受到一定影响的。
因此，如果要完全避免这次的影响，有两个条件
1、你的域名的DNS必须是在国外
2、你查询的DNS必须在国外，而且如果在污染期需要通过TCP查询。
这样就可以避免这个问题了。
在这里奉劝一句媒体，不要听风就是风，听雨就是雨。不要一味的把责任推给无关的DNSPOD等厂商。自己要有判断力。
根DNS是什么呢？大家想想，每个域名都有一个后缀,比如说[.info]后缀的域名，那么就有一个专门记录[.info]后缀的dns服务器，其他后缀也一样。这个DNS就是该域名的根DNS。
那么递归DNS呢？其实递归DNS就是一个代理人，是用来缓解[根DNS]压力的，如果大家都去问[根DNS]，那[根DNS]不早就跪了。毕竟一个人(网站)的地址不是经常变的，所以就有了TTL这一说法，根据DNS的规定，在一个TTL时间呢，大家就认为你家里(域名所指向的IP)的地址是不会变的，所以代理人[递归DNS]在这个时间内，是只会问一次[根DNS]的，如果你第二次问他，他就会直接告诉你域名所指向的IP地址。这样就可以解决[根DNS]负载过大的问题啦。
1.
说了这么久，口水都干了，那么DNS到底跟这次事件有什么关系呢~
首先来看张图：
2
这么多域名都指向同一个IP了，这是什么情况0 0。其实这就是典型的[DNS污染]了。
我们知道互联网有两种协议，一种是TCP，一种则是UDP了（知道泥煤啊(╯‵□′)╯︵┻━┻都说我不是学计算机的了）。
TCP和UDP的主要差别就是：能不能保证传递信息的可靠性。UDP是不管消息是否到达了目标，通过什么途径的，他只管我发出去了就好，所以UDP比TCP快得多，但是可靠性没有TCP好。
3
而DNS查询默认就是用的是UDP，那么就很好劫持啦。在UDP包任何传输的路途上，直接拦截，然后返回给接收端就行了。
啧啧，说道这大家也隐隐约约知道这次事件的问题了吧，范围如此之广的劫持，必须要在各个省市的主干网上进行，而能处理这么大数据，同时能控制这么多主干网的。。啧啧啧。。。没错！就是GFW了
说道这里，准备手动查一下，到底是不是所推测的GFW呢？于是拿到了这个图（From XiaoXin）
4
与此同时运维也在各地的服务器上开始了跟踪查询，发现全国各地解析时间均为25ms左右。这时候结论就出来了。
这样就明显了，肯定是GFW做的了~~于是又好奇的查了下，这个IP是什么来头，为什么都要指向到这里去，于是发现了一些好玩的东西~（http://bgp.he.net/net/65.49.2.0/24#_dns）
5
从侧面点出了此次事件的始作俑者。
那么某FW为什么要这么做呢？在这里做一个无责任的推测，最有可能的就是：某FW的员工本来是想屏蔽这个IP段的，但是呢一不小心点进去了DNS污染这个选项，然后又没写污染目标，于是就全局污染了啧啧啧~
但是有些童鞋会问了(╯‵□′)╯︵┻━┻为什么他们都说用8.8.8.8就没事了~
其实这样子说是不正确的，因为之前用的就是8.8.8.8，上面也说了DNS查询默认使用的UDP查询，所以不管你用什么，照样劫持不误。其实8.8.8.8没问题是因为污染事件已经基本结束导致的，那么为什么污染结束后其他国内DNS都不能用，而Goole的DNS确可以正常的使用~于是就找到了张有趣的图片~
6
我先来解释下上面命令的用途吧~这个命令是用来直接向DNS服务器查询域名的~
其中的[-vc]参数是强制使用TCP来查询DNS服务器，这样就可以避免UDP污染。
那么为什么污染结束后，DNS还会受到污染呢？其实原因很简单。之前说了，[递归DNS]是需要询问[根DNS]的，而默认的询问方式是采用的UDP，所以在国内的DNS服务器，自然就受到污染了。而之前也提到过TTL这件事~
在TTL周期内，根据协议[递归DNS]是直接吧结果缓存在自己那，是不会再去查询[根DNS]的，所以国内的DNS就把错误的结果缓存起来了~
而Google的DNS服务器基本都是在国外，所以查询的时候影响并不大，但是国内挺多域名使用DNSPOD啦，DNSLA的DNS，所以Google进国内查，还是会受到一定影响的。
因此，如果要完全避免这次的影响，有两个条件
1、你的域名的DNS必须是在国外
2、你查询的DNS必须在国外，而且如果在污染期需要通过TCP查询。
这样就可以避免这个问题了。
在这里奉劝一句媒体，不要听风就是风，听雨就是雨。不要一味的把责任推给无关的DNSPOD等厂商。自己要有判断力。