DNS反劫持的几种方式
2016-02-28 20:07
337 查看
家里联通宽带到期,之前使用的时候感觉出口速度并不好,听说移动宽带因为用的人少,出口带宽不错,准备换一下试试.临上马之前先考察一下,普遍反映移动的DNS限制比较多,各种DNS劫持.要是能有办法检测到自己正在使用的DNS是哪个就好了,还好有这个:
http://dnsleaktest.com/
![](http://img.blog.csdn.net/20160228201325035?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
结果如下:
![](http://img.blog.csdn.net/20160228201340911?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
检测之前已经把本机DNS设置成114.114.114.114了,从结果上看果然有问题,应该是使用了透明DNS代理的技术,导致DNS泄漏.
![](https://dnsleaktest.com/img/transparent-dns-proxy.png)
总结一下:
DNS劫持,劫持单条DNS查询信息,返回不正确的结果.
透明DNS代理,劫持所有查询信息,只要是经过运营商网关的发往53端口的UDP类型的DNS协议,全部都转移到自己DNS服务器上去,所以在本机上设置是没用的.
这样一来,即使在内部网络中部署了DNS服务器也只可以起到加速作用,依然无法反劫持.因为内网中的DNS服务器向上级DNS服务器请求时的数据同样会被透明DNS代理劫持到ISP的DNS上.内部DNS服务器缓存的数据依然是被污染过的.
如果想突破这种劫持,有三种方式. 这三种方式,都需要在本机对DNS请求数据进行预处理,所以本机都需要部署处理程序,同时将本地DNS设置为127.0.0.1.
1. 使用DNS协议的TCP形式.
按照约定,DNS服务器都要同时实现TCP形式的DNS协议处理.这样一来,只需要在本地把UDP形式的协议转换为TCP形式就可以了.可以使用的工具有:
(1)
socat
socat是linux下很好用的端口转发工具,支持UDP转TCP,试用了一下,并不好用,经常各种错误.
使用方法倒是很简单: socat udp4-listen:53,reuseaddr,fork TCP:114.114.114.114:53
socatwindows版本的下载地址
(2)
Tcp-DNS-proxy和pwx-dns-proxy
这两个都是专门的DNS协议转换工具,实际使用了一下,效果都很不理想,速度很慢.
(3)pdnsd
这个其实是个dns服务器,需要设置向上级服务器请求时只使用TCP格式.貌似也就这个方案比较靠谱.
之前还有尝试过其他的端口转发工具,要么不支持UDP,要么号称支持UDP,但是只支持UDP到UDP,不支持UDP到TCP.
2. 使用加密软件对DNS请求和回复数据进行加密.
这种方式的弊端是,既然内部有加密,外部必须有一个相应的解密工具.对个人来说,外部还需要部署一套专门的解密工具,需要VPS,代价有点大.
使用这种方式的工具找到两个:
(1)
dnscrypt
这个工具貌似很有名,所以本身内置的DNS服务器地址已经大部分被封.速度很不理想,没有尝试自己部署服务器端会怎么样.
(2)
tcp-over-dns
没有具体试用.
3. 使用其他端口.
没有具体试用,没找到现成的工具.这种方式,需要本地转发DNS请求到指定端口,然后还需要在外网部署使用特定端口的DNS服务器.同样需要一台VPS.
http://dnsleaktest.com/
结果如下:
检测之前已经把本机DNS设置成114.114.114.114了,从结果上看果然有问题,应该是使用了透明DNS代理的技术,导致DNS泄漏.
![](https://dnsleaktest.com/img/transparent-dns-proxy.png)
总结一下:
DNS劫持,劫持单条DNS查询信息,返回不正确的结果.
透明DNS代理,劫持所有查询信息,只要是经过运营商网关的发往53端口的UDP类型的DNS协议,全部都转移到自己DNS服务器上去,所以在本机上设置是没用的.
这样一来,即使在内部网络中部署了DNS服务器也只可以起到加速作用,依然无法反劫持.因为内网中的DNS服务器向上级DNS服务器请求时的数据同样会被透明DNS代理劫持到ISP的DNS上.内部DNS服务器缓存的数据依然是被污染过的.
如果想突破这种劫持,有三种方式. 这三种方式,都需要在本机对DNS请求数据进行预处理,所以本机都需要部署处理程序,同时将本地DNS设置为127.0.0.1.
1. 使用DNS协议的TCP形式.
按照约定,DNS服务器都要同时实现TCP形式的DNS协议处理.这样一来,只需要在本地把UDP形式的协议转换为TCP形式就可以了.可以使用的工具有:
(1)
socat
socat是linux下很好用的端口转发工具,支持UDP转TCP,试用了一下,并不好用,经常各种错误.
使用方法倒是很简单: socat udp4-listen:53,reuseaddr,fork TCP:114.114.114.114:53
socatwindows版本的下载地址
(2)
Tcp-DNS-proxy和pwx-dns-proxy
这两个都是专门的DNS协议转换工具,实际使用了一下,效果都很不理想,速度很慢.
(3)pdnsd
这个其实是个dns服务器,需要设置向上级服务器请求时只使用TCP格式.貌似也就这个方案比较靠谱.
之前还有尝试过其他的端口转发工具,要么不支持UDP,要么号称支持UDP,但是只支持UDP到UDP,不支持UDP到TCP.
2. 使用加密软件对DNS请求和回复数据进行加密.
这种方式的弊端是,既然内部有加密,外部必须有一个相应的解密工具.对个人来说,外部还需要部署一套专门的解密工具,需要VPS,代价有点大.
使用这种方式的工具找到两个:
(1)
dnscrypt
这个工具貌似很有名,所以本身内置的DNS服务器地址已经大部分被封.速度很不理想,没有尝试自己部署服务器端会怎么样.
(2)
tcp-over-dns
没有具体试用.
3. 使用其他端口.
没有具体试用,没找到现成的工具.这种方式,需要本地转发DNS请求到指定端口,然后还需要在外网部署使用特定端口的DNS服务器.同样需要一台VPS.
相关文章推荐
- Java凝视Annotation
- ASP.NET MVC学习之路由篇(2)
- ASP.NET MVC学习之路由篇(1)
- Swift
- 在内网建一个FTP服务器,并且可以通过外网访问
- 选课总结--用户体验初识
- 《leetCode》:Sum Root to Leaf Numbers
- DGGame序-回归Blog重构自我
- Java中的包访问权限
- 容器类概述(1)
- 1052 Linked List Sorting
- c++强类型枚举enum class NEWTYPE
- ASP.NET MVC学习之模型绑定(2)
- [MySQL] 事务隔离级别
- Java 中InputStream与Reader的区别
- OpenStack快速安装
- ASP.NET MVC学习之模型绑定(1)
- 函数返回一个指针
- 【BZOJ3511】土地划分【最小割】
- 怎样在 ubuntu 和 debian 中通过命令行管理 KVM