DNS域名污染又称域名服务器缓存投毒

admin · 发表于 2021-11-19 22:11:56

网域服务器缓存污染（DNS cache pollution），又称域名服务器缓存投毒（DNS cache poisoning），是指一些刻意制造或无意中制造出来的域名服务器数据包，把域名指往不正确的IP地址。一般来说，在互联网上都有可信赖的网域服务器，但为减低网络上的流量压力，一般的域名服务器都会把从上游的域名服务器获得的解析记录暂存起来，待下次有其他机器要求解析域名时，可以立即提供服务。一旦有关网域的局域域名服务器的缓存受到污染，就会把网域内的计算机导引往错误的服务器或服务器的网址。
中文名DNS污染外文名DNS pollution名称DNS污染别名1域名服务器缓存污染别名2域名服务器快照侵害类似手段DNS劫持污染源旁路路由器

定义编辑
某些网络运营商为了某些目的，对DNS进行了某些操作，导致使用ISP的正常上网设置无法通过域名取得正确的IP地址。
某些国家或地区出于某些目的为了防止某网站被访问，而且其又掌握部分国际DNS根目录服务器或镜像，也会利用此方法进行屏蔽。
常用的手段有：DNS劫持和DNS污染。
常用方法编辑
对于运营商，网络管理员等人，尤其是在办公室等地方，管理员希望网络使用者无法浏览某些与工作无关的网站，通常采用DNS抢答机制。机器查询DNS时，采用的是UDP协议进行通讯，队列的每个查询有一个id进行标识。
查询
源IP 目的IP 内容
192.168.2.2 8.8.8.8 Standard query 0x0001 PTR 8.8.8.8.in-addr.arpa
8.8.8.8 192.168.2.2 Standard query response 0x0001 PTR google-public-dns-a.google.com
192.168.2.2 8.8.8.8 Standard query 0x0002 A baidu.com
8.8.8.8 192.168.2.2 Standard query response 0x0002 A 220.181.57.217 A 123.125.114.144 A 180.149.132.47
192.168.2.2 8.8.8.8 Standard query 0x0003 AAAA baidu.com
8.8.8.8 192.168.2.2
Standard query response 0x0003
我们对一次正常的DNS请求进行抓包，结果如下表：
这里我们查询了百度的A记录（ipv4）以及AAAA记录（ipv6）每一个请求都有一个回应。

奇怪的查询
源IP 目的IP 内容
192.168.2.2 8.8.8.8 Standard query 0x0001 PTR 8.8.8.8.in-addr.arpa
8.8.8.8 192.168.2.2 Standard query response 0x0001 PTR google-public-dns-a.google.com
192.168.2.2 8.8.8.8 Standard query 0x0002 A facebook.com
8.8.8.8 192.168.2.2 Standard query response 0x0002 A 8.7.198.45
8.8.8.8 192.168.2.2 Standard query response 0x0002 A 159.106.121.75
192.168.2.2 8.8.8.8
Standard query 0x0003 AAAA facebook.com
8.8.8.8 192.168.2.2 Standard query response 0x0003 A 93.46.8.89
8.8.8.8 192.168.2.2 Standard query response 0x0002 A 31.13.90.2
8.8.8.8 192.168.2.2 Standard query response 0x0003 AAAA 2a03:2880:f01a:1:face:b00c:0:1
从上表中我们可以看到一个神奇的东西，本地在向服务器发送id为3的查询时，返回的结果竟然有以id2标识的结果，同时在整个查询中，A记录居然返回了三条，通过whois来对上述的三条A记录进行检查，我们发现，只有31.13.90.2才是facebook的ip地址，也就是那个姗姗来迟的id为2的查询结果，而标记着编号为3的AAAA查询结果中，我们竟然发现了一个A记录的查询结果。由此可见，上表用底色标记的就是被污染的DNS。下面我们就来讲述一下这个的实现方法。

原理解析
我们假设A为用户端，B为DNS服务器，C为A到B链路的一个节点的网络设备（路由器，交换机，网关等等）。然后我们来模拟一次被污染的DNS请求过程。
A向B构建UDP连接，然后，A向B发送查询请求，查询请求内容通常是：“A bc372.com”，这一个数据包经过节点设备C继续前往DNS服务器B；然而在这个过程中，C通过对数据包进行特征分析（远程通讯端口为DNS服务器端口，激发内容关键字检查，检查特定的域名如上述的“bc372.com",以及查询的记录类型"A记录"），从而立刻返回一个错误的解析结果（如返回了"A 123.123.123.123"），众所周知，作为链路上的一个节点，C机器的这个结果必定会先于真正的域名服务器的返回结果到达用户机器A，而目前我们的DNS解析机制有一个重要的原则，就是只认第一，因此C节点所返回的查询结果就被A机器当作了最终返回结果，用于构建链接。

防除方法编辑
对付DNS劫持，只需要把系统的DNS设置手动切换为国外的DNS服务器的IP地址即可解决。
对于DNS污染，一般除了使用代理服务器和VPN之类的软件之外，并没有什么其它办法。但是利用我们对DNS污染的了解，还是可以做到不用代理服务器和VPN之类的软件就能解决DNS污染的问题，从而在不使用代理服务器或VPN的情况下访问原本访问不了的一些网站。当然这无法解决所有问题，当一些无法访问的网站本身并不是由DNS污染问题导致的时候，还是需要使用代理服务器或VPN才能访问的。
DNS污染的数据包并不是在网络数据包经过的路由器上，而是在其旁路产生的。所以DNS污染并无法阻止正确的DNS解析结果返回，但由于旁路产生的数据包发回的速度较国外DNS服务器发回的快，操作系统认为第一个收到的数据包就是返回结果，从而忽略其后收到的数据包，从而使得DNS污染得逞。而某些国家的DNS污染在一段时期内的污染IP却是固定不变的，从而可以忽略返回结果是这些IP地址的数据包，直接解决DNS污染的问题。

验证方法编辑
我们在命令行下通过这样一条命令：
nslookup 域名 144.223.234.234(例如：bc372.com)，即可判断该域名是否被污染，由于144.223.234.234不存在，理应没有任何返回。但我们却得到了一个错误的IP（不确定）。即可证明这个域名已经被DNS污染了。

解决方案编辑
1、使用各种SSH加密代理，在加密代理里进行远程DNS解析，或者使用VPN上网。
2、修改hosts文件，操作系统中Hosts文件的权限优先级高于DNS服务器，操作系统在访问某个域名时，会先检测HOSTS文件，然后再查询DNS服务器。可以在hosts添加受到污染的DNS地址来解决DNS污染和DNS劫持。
3、通过一些软件编程处理，可以直接忽略返回结果是虚假IP地址的数据包，直接解决DNS污染的问题。
4、如果你是Firefox only用户，并且只用Firefox，又懒得折腾，直接打开Firefox的远程DNS解析就行了。在地址栏中输入：
about:config
找到network.proxy.socks_remote_dns一项改成true。
5、使用DNSCrypt软件，此软件与使用的OpenDNS直接建立相对安全的TCP连接并加密请求数据，从而不会被污染

		自动登录	找回密码
密码			立即注册