dns查询用的是udp协议，对这种无连接的协议gfw想用reset包来阻断连接是不可能的。对此gfw采用的是dns投毒，就是返回一个虚假的dns
查询，对于udp协议来说只会采纳最先到达的数据包内容而把后面到达的包丢弃。如果查询不到正确结果，则是gfw发出的假包先到达，正确的查询结果被丢弃
了而已。
如果墙外的dns的反应够快呢？这回被丢弃的则是gfw伪造的数据包了。为此我做了一个小小的测试。 测试的域名是www.youtube.com，dns是google公共dns 8.8.8.8 和 8.8.4.4。
在 我这里ping 8.8.8.8 的延迟平均是142ms，ping 8.8.4.4 的延迟平均是 266ms 。在8.8.8.8查询dns会得到正确的查询结果；在8.8.4.4查询得到的是gfw伪造的结果。打开wireshark抓包分析一下，过滤一下抓包 的结果，只显示dns查询。其实用8.8.4.4查询也能收到正确结果的数据包，只是gfw伪造的结果先到而已；如果换用8.8.8.8查询，查询的结果 是正确的，但是也收到了gfw发出伪造结果，只是这次被抛弃的是gfw伪造的结果而已。
知道了这些，我们可以利用gfw对dns投毒反应 时间有延迟来选择反应比gfw快的海外dns服务器来解析域名，这样可以在很大程度上解决dns投毒的问题。根据上面的测试结果，我们可以肯定在我所处的 环境如果海外dns服务器的反应时间低于140ms则不会受到gfw的dns投毒影响。
在我所处的网络环境下。根据抓包分 析，8.8.8.8的dns查询结果一般会在140ms左右后到达，8.8.4.4的dns查询结果会在250ms左右后到达，而gfw的伪造结果会在 160ms-240ms之间到达。如果把dns设置为8.8.8.8，利用时间差，可以很大程度上避免gfw的dns投毒。顺便说一句，对于 OpenDNS之类的号称没有dns劫持的服务器，如果查询速度不够快，在天朝所处的网络环境下也是无法发挥作用的.
如果墙外的dns的反应够快呢？这回被丢弃的则是gfw伪造的数据包了。为此我做了一个小小的测试。 测试的域名是www.youtube.com，dns是google公共dns 8.8.8.8 和 8.8.4.4。
在 我这里ping 8.8.8.8 的延迟平均是142ms，ping 8.8.4.4 的延迟平均是 266ms 。在8.8.8.8查询dns会得到正确的查询结果；在8.8.4.4查询得到的是gfw伪造的结果。打开wireshark抓包分析一下，过滤一下抓包 的结果，只显示dns查询。其实用8.8.4.4查询也能收到正确结果的数据包，只是gfw伪造的结果先到而已；如果换用8.8.8.8查询，查询的结果 是正确的，但是也收到了gfw发出伪造结果，只是这次被抛弃的是gfw伪造的结果而已。
知道了这些，我们可以利用gfw对dns投毒反应 时间有延迟来选择反应比gfw快的海外dns服务器来解析域名，这样可以在很大程度上解决dns投毒的问题。根据上面的测试结果，我们可以肯定在我所处的 环境如果海外dns服务器的反应时间低于140ms则不会受到gfw的dns投毒影响。
在我所处的网络环境下。根据抓包分 析，8.8.8.8的dns查询结果一般会在140ms左右后到达，8.8.4.4的dns查询结果会在250ms左右后到达，而gfw的伪造结果会在 160ms-240ms之间到达。如果把dns设置为8.8.8.8，利用时间差，可以很大程度上避免gfw的dns投毒。顺便说一句，对于 OpenDNS之类的号称没有dns劫持的服务器，如果查询速度不够快，在天朝所处的网络环境下也是无法发挥作用的.
