最近炒的比较火的一个漏洞是DNS协议本身发现的一个严重问题(CERT VU#800113)。国内媒体对此的报道多数都语焉不详，因此我想有必要说说这个漏洞到底是怎么回事。
首先我们要明确的第一个问题是，DNS查询是如何进行的?对于绝大多数桌面系统来说，DNS的查询并不是由自己的机器完成的，DNS查询会提交给另一台DNS服务器(这台服务器通常是由ISP或者公司提供)，然后这台服务器再去进行真正的查询操作。这样做的好处是DNS的查询结果可以由这台机器给缓 存下来，从而提高查询效率并降低由DNS带来的流量开销(当然，在今天这种开销已经是可以忽略不计的了)。
我们可以看到的一个情况是，一台缓存DNS服务器(与权威DNS相对，这类系统提供的)下面的桌面系统可能有几百、几千、几万甚至几十万台，从攻击的有效性而言，如果能够影响这台服务器的话，相比攻陷其下的桌面系统而言，成本便会降低很多，这种攻击我们通常称之为杠杆式攻击。
针对缓存DNS服务器的杠杆式攻击其实从很早就有研究，除了希望通过劫持网站流量来牟利的骇客之外，还有一些人使用这种方法达到一些其他的目的，例如屏蔽存在安全问题的网站，以及在一些国家存在的互联网内容净化处理等等。
本次VU# 800113是一个足以引起人们重视的问题，尽管它采用的仍然是"Cache 投毒"(cache poisoning)的方法，但这种方法采用了一些新的技巧来使其更加有效。具体来说，DNS的查询过程是由客户端(无论是桌面计算机，或是缓存DNS服 务器发起的查询)发出一个到权威DNS服务器(可能是根DNS，也可能是具体域名的权威DNS)一个UDP请求，然后等待其回应。
UDP是一种无连接的协议，为了能够识别来自不同服务器的回应，DNS协议利用端口和一个称为TXID的识别符(类似TCP的序号)来区分它们。事 实上，早期的DNS协议实现甚至会使用固定的端口来发起DNS请求，这样一来，TXID就成了识别回应的唯一标识。由于DNS协议是在上世纪70年代设计 的，因此TXID序号只有16个bit宽，而另一方面，伪造UDP包的来源地址又很容易(因为UDP并没有提供类似TCP那样内建的防止此类攻击的机 制)，因此，攻击者只需设法让DNS缓存服务器相信自己伪造的来自权威DNS的回应是真实的，就可以达到目的了。
具体地说这种攻击包括两个部分，其一是设法让缓存DNS服务器发起新的DNS查询请求(有很多方法)，其二则是发出大量的伪造包并期待其命中，也就是在真实的权威DNS回应之前，将伪造的，但端口和TXID均能匹配的UDP回应发到缓存DNS服务器。
对于一些以线性递增方式来产生TXID的DNS客户端而言，攻击者可以自行架设一台DNS服务器、诱使对方发出DNS请求，从而大大提高攻击的效 率。对于采用固定端口的DNS客户端来说，攻击者可以通过类似的手段来获取他关心的信息。攻击者可以用各种方式来达到这种目的，包括钓鱼邮件，也包括直接 发起查询等等。
本次VU #800113所描述的问题是，多数DNS缓存服务器实现都存在这两种弱点之一或全部。
说完攻击的原理，我想更多的人关心的问题会是：我们能够做点什么?
如果你是一名桌面用户，那么最好的办法是等待公司或ISP的工作人员修正问题，通过安装适当的补丁，能够消除以上两种弱点。对于 FreeBSD 用户，减轻这类问题影响的办法是在 /etc/rc.conf 中加入 named_enable="YES"，执行 /etc/rc.d/named restart 并在 /etc/resolv.conf 中将 127.0.0.1 配置为域名服务器，这样一来攻击缓存服务器一点便变成了攻击所有的桌面系统，从而大大提高攻击的成本，但缺点是这样做意味着无法利用上游 DNS 的缓存。
如果你是缓存DNS服务器的管理员，那么除了需要打补丁之外(如果你的系统中存在这个漏洞)，还需要考虑部署DNSsec。DNS协议的漏洞通过随机化查询端口和TXID只能部分缓解，而DNSsec才是解决问题的根本。
如果你是权威DNS服务器的管理员，那么事实上你做不了什么，因为缓存DNS服务器并不受你控制。唯一可以做的事情就只剩下为自己的权威域名配置DNSsec了。遗憾的是，目前并不是所有的顶级域名，以及域名注册服务提供商都支持DNSsec。
一些常见的误解：
误解A：靠，又是那个破烂BIND的漏洞，我不用BIND所以没事。
错。除了BIND之外，也有很多其他DNS服务器作为缓存DNS使用时会遇到同样的问题。
误解B：我的Ubuntu系统第一时间修补了这个问题，所以我不受影响。
错。除非你在本地运行DNS缓存服务，并只使用它作为DNS。
误解C：我是打酱油的，DNS被攻击跟我没关系，顶多给人家增加点流量而已，不碍事。
错。通过DNS Cache投毒攻击可以将你引导到一些伪造的钓鱼站点来骗取敏感数据。
误解D：我的权威DNS服务器配置了DNSsec，所以客户一定会访问到正确的网站。
错。事实是，许多早期的DNSsec实现都引入了其他安全漏洞;另一方面，多数缓存DNS服务器并不进行DNSsec校验，因此你仍然需要其他一些手段来减轻这个问题的影响。
全球DNS系统需要来一次DNSsec俯卧撑。