在发现经常访问的网站出现宕机或者误入某些非常下流网站的原因是由于域名系统(DNS)被污染而造成的。域
名系统缓存污染并属于不经常发生的问题，但问题是一旦出现真正发生的情况，就可能会导致互联网上大部分区
域陷于停顿状态。解决这一潜在威胁的办法是什么?答案就是域名系统安全扩展(DNSSEC)。
域名系统通常是这样的情况下被污染的。DNS是互联网地址名单的管理者。在它的帮助下，你不需要自己输入
出类似“http：//209.85.135.99/”这样一个谷歌拥有的众多IPv4地址之一来访问对应的网站，只要简单地输入
“http：//www.google.com”就可以达到相应的目的。但是，你的浏览器是如何确认“209.85.135.99”就属于谷
歌的正确地址呢?就本身而言，它是做不到这一点的。它需要依赖于DNS，并且，在这里没有什么好抱怨的，普通
DNS系统里没有内置任何措施，来确保返回给浏览器的相关信息是正确有效的。
而DNSSEC的作用就是通过要求网站利用DNS服务器来对域名和对应的网络IP地址进行验证的方式来防止DNS缓
存被污染。为了确保信息不受到破坏，DNSSEC利用数字签名和公钥技术来对交换信息进行了加密。由于需要破坏
流行网站的DNS信息才能获取加密信息，这种防护措施反过来又让黑客对DNS服务器的攻击更难实现。
从7月15日开始，作为主DNS服务器的13台互联网根域名服务器已经实现了对DNSSEC的支持。到现在，在互联
网全部294个顶级域(TLD)中已经有55个开始支持DNSSEC。这里面包括了所有非盈利性组织使用的.org域，教育机
构使用的.edu域。并且，威瑞信已经决定从2011年初起为.net域提供DNSSEC支持。
对于我们中的大多数人来说，这个层次的变化真得无所谓。我们并不需要呼叫根域名服务器或者顶级域来对
域名进行解析。实际上，现在切换到DNSSEC给我们带来的影响才刚刚开始。在10月18日，康卡斯特成为第一家部
署DNSSEC的主要互联网服务供应商。因此，如果你现在想使用DNSSEC的话，就已经没问题了。不论你是否属于康
卡斯特的用户，都可以将自己的DNS服务器指向IP地址设置为75.75.75.75和75.75.76.76。关于操作的详细说明，
你可以观看康卡斯特提供的DNSSEC说明视频。如果你想了解为什么说使用DNSSEC是一个好主意的话，可以登录新
建立的安全域名系统使用指南网站，上面提供了全面详细的说明资料。
所以，如果说DNSEC是一个非常好的主意的话，为什么不是所有人都已经做到了呢?这个么，你看，如同任何
互联网的重大调整，在应用DNSSEC到旧的程序和硬件上时，可能会出现问题。
最主要的问题就是一些路由器、交换机和防火墙不能有效处理DNSSEC的数据包。DNS流量使用的是用户数据报
协议(UDP)，在通常情况下，DNS用UDP数据包的大小是在512字节之内。因此，网络上的很多软件和硬件都默认拒
绝超过512字节的任何UDP数据包。不幸的是，DNSSEC的数据包总是大于512字节。
在某些系统中，这会导致DNS出现故障。而在其它系统中可能会导致故障并转移到传输控制协议(TCP)中。与
UDP相比使用TCP的缺点就是，占用的带宽大得多。尽管可能不是什么大问题，但对于企业网络的管理者来说，这
会导致潜伏期明显增加。并且，没人喜欢互联网速度变慢。
此外，当客户搜索一家不存在的网站时，一些互联网服务供应商和DNS服务器会对DNS答复信息进行重写，将
他们重定向到经过定制的搜索页面上。举例来说，我使用OpenDNS的原因就是，它的DNS查询速度比我的互联网服
务供应商更快。但是，如果我输入的域名不存在，它将会返回一个OpenDNS的搜索页面。在DNSSEC下使用OpenDNS
这么做时，会发生什么情况?我不知道，但我有种工作情况不会很正常的不好感觉。
顺便提一下，在DNS安全管理方面，OpenDNS已经提供了其它选择：DNSCurve。DNSCurve将如何实现与DNSSEC
协同工作呢?答案是不可能。它们试图利用截然不同的方法来实现DNS安全。对于用户来说，这可能就意味着，不
管其它地方使用的是什么安全措施，你依然可以使用DNS，但如果大家使用的不是相同技术的话，在安全方面就不
会获得任何保障。
就个人来看，我认为大家目前能做的最好情况，就是更新内部DNS软件和固件到最新的DNSSEC兼容版本。我们
还可以了解上游的DNS是否按照域名系统运行分析研究中心为非网络管理员用户提供的指南部署了DNSSEC，为了简
单起见，你也可以选择运行Java应用程序，快速得到清晰明确的确定答案。
总之，如果发现使用的ISP没有使用DNSSEC的话，提醒他们尽快部署。DNSSEC是未来发展的趋势，ISP部署使
用的越早，获得的安全性就越高。
