随着互联网应用的日益广泛以及DNS自身的创新及发展（如智能DNS、国际化域名等），DNS遭遇攻击以后影响范围逐渐从单个区域扩展到多个国家和地区，而且直接影响互联网的安全稳定运行，进而可影响整个国家安全、社会秩序以及公共利益。

DNS安全扩展协议（DNSSEC）主要解决了DNS欺诈以及缓存中毒攻击等问题，是域名安全体系中一项重要的技术。截至2014年初，全球390个顶级域名中已经有197个签署了DNSSEC安全协议，部署比例超过53%。在新通用顶级域（New gTLD）申请中，DNSSEC已经作为必要的申请条件写入了申请人指南。

在今年6月于伦敦举行的ICANN第50次大会上，中国国家互联网信息办公室主任鲁炜也明确指出了中国将全面推进安全域名扩展(DNSSEC)工作。

那么为什么这项技术能够有效遏制DNS欺诈或缓存中毒攻击，而DNSSec的发展之路却又如此艰辛和漫长，以及现在部署的迫切性，以下将给出答案。

DNSSec详解——DNSSec功能

DNSSec全称是域名系统安全扩展，它对于网上可靠的交流与交易都至关重要。它可以修复域名系统中由来已久的易造成重大后果的缓存中毒漏洞。

缓存中毒漏洞究竟存在多少年了呢？大约在25年前，Steve Bellov于1990年在其论文中首次描述了缓存中毒的可能性。其重要性如何呢？可以说我们无法成功应对缓存中毒的威胁，网上的任何事情都不安全，因为任何一项重大交易都是由DNS促成的。

DNSSec的采用在2010和2011年初见端倪后，又似乎中途受阻。DNS业界也做了很大努力，签署了顶级域名，包括根域名.com, .net和.org以及许多国家代码顶级域名。但是其分区的采用却微乎其微。

.com是最大的顶级域名，拥有超过100,000 的签署分区 。一些国家代码顶级域名拥有更高的采用率，但是许多域名的采用情况却如gTLD一般惨淡。问题出在哪儿呢？

DNSSec的工作原理

在讨论DNSSec的普及为何如此缓慢之前，我们需要看一下DNSSec的工作原理以及它是如何防止缓存中毒的。

当然，缓存中毒诱使域名服务器缓存虚假资源记录。在黑客的控制下，这些记录可能会将通用网站如www.ebay.com的记录映射到一个受黑客控制的Web服务器上的IP地址。那台Web服务器提供的内容与eBay的真实内容难以区分。实际上，该Web服务器恰好可以代理来自www.ebay.com的真实内容。用户可能无意间将重要信息输入到欺诈网站，于是被记录下来用以破坏用户账户，提高费用等等。

DNSSec通过允许域名管理员签署数字域名数据，来解决缓存中毒问题。就像签署重要邮件信息一样。

例如，Infoblox的管理员已签署了infoblox.com域名。因此，接收infoblox.com数据的域名服务器可以使用自动生成的数字签名验证该数据。如果该数据有效，那么该域名服务器一定是真实的、完整的。

以infoblox.com为例，这意味着进行验证的域名服务器可以确定www.infoblox.com 的A记录是由infoblox.com域名的正式授权管理员签署的，并且签署后没有修改。如果有人蓄意将www.infoblox.com的A记录注入到一个域名服务器的缓存中，他们将无法假造签名，验证无法通过，域名服务器将拒绝A记录。

关于DNSSec还有很多内容需要了解：比如可证明否定存在的信任链等等。然而，部署为什么耗费如此之长的时间呢？我们先看一下背景资料。

人为因素与DNSSec

现在我们首先讨论一下实施。DNSSec的首次实施发生在1999年的BIND 8中，几乎无法使用。首次签署域错综复杂，犹如拜占庭工程，要求多个命令行工具– dnssec-keygen, dnssec-signzone等等，每个命令行都有不同理解，几个或十几个命令行选项与选项参数。你运行这些，他们创建文件，你将这些文件添加到原有的域数据文件中，你又要去运行其他工具。

任何时候只要修改过域名甚至没有修改过但是签名快到期时都要重新签署，你不得不运行命令行工具再次签署。命令行工具重新生成该域名内的所有签名，即使你只修改了一个记录。

好消息是互联网系统协会及供应商（包括Infoblox在内）已投入大量精力简化与自动化这些流程。现在你只需在GUI内一键确认（点击几次）便可签署域名，或者借助rndc签署域名，而且域名的维护也可以自动进行。然而，可能是很多管理员对之前恐怖的手动过程仍心有余悸吧。

导致DNSSec发展缓慢的另一人为因素是不确定性，这是由域名服务器的一些执行者和一些DNS管理员造成的。首次描述DNSSec的RFC 2065出版于1997年1月。实施该标准的过程中又产生了DNSSec的修改版，这在1999年3月出版的RFC2535中有描述。然而，体验再次证明该版本对于管理一个像Internet一样大的网络是不实际的。这引起了DNSSec的新增变化，也就是2005年3月出版的RFC 4033至4035。

这些修正还是不充分。隐私权拥护者认为DNSSec签署的域名容易通过“假域名转移”使其内容泄露，一些注册机构（运行.com等顶级域名的组织机构）认为将签名添加到其域名中NS记录的每一集群中将极其繁琐和麻烦。因此，介绍另一全新DNSSec记录类型NSEC3的RFC5155于2008年3月应运而生。

历史细节固然重要，但更重要的是DNSSec从1997年到2008年改变了很多，它开始瞄准域名服务器实施人员和DNS管理员。可以理解，部分人会选择推迟添加DNSSec支持其域名服务器或签署其域名，他们等待一切尘埃落定。

现在已经到了2014年，一切基本都已就绪，每个主要域名服务器实施，从BIND到微软DNS服务器，再到NSD和Unbound等新来者都支持DNSSec。因此，是时候行动起来了。

部署DNSSec的动机、日常费用和DNSSec的未来

怎么才能激励网络管理员广泛采用DNSSec呢？有个组织机构绝对有能力影响DNSSec的采用：那就是PCI安全标准委员会，负责PCI数据安全标准和其他监管支付卡行业标准的发展。长久以来，坊间就流传该机构考虑要求网站接受支付卡的企业使用DNSSec签署其域名，以便实现PCI DSS合规性。鉴于信用卡接受度已渗透到各大主要网站，这一要求将产生巨大的影响力。

域名的推广用到了两种武器：胡萝卜和大棒，那么孰优孰劣呢？一些顶级域名使用胡萝卜的方法取得了很好的成绩，而相比之下，使用OMB大棒的SIDN结果却十分惨淡。管理荷兰顶级域名.nl的SIDN为注册签署域名的注册者提供优惠，几个星期后，网上就产生了大量的签署分区。

DNS管理员不情愿部署DNSSec，诱使其部署的最后一种强硬方法可能是：法律诉讼，或法律诉讼威胁。成功的缓存中毒攻击本身很难检测到（TTL过期后中毒记录通常奇迹般地从缓存中消失），而这类攻击的确会发生。我认为迟早有一天爱打官司的国家的某些人（比如美国人）会成为缓存中毒的受害者，其银行账号被榨干。届时受害者的人身事故赔偿律师会寻找财大气粗的人承担责任，然后他们非常兴奋的发现其客户访问的企业网站没有使用DNSSec签署域名，其客户的ISP也没有验证DNSSec数据。

有时DNSSec日常管理费用也是妨碍其采用的一大因素。以RRSIG记录为例可以看出，很明显签署后域名会变大。签署域名不仅会增加每个RRset（如果你从一个密钥对翻到另一对）的RRSIG记录，而且这些记录也比绝大多数“正常”(非DNSSec)记录大很多。签署域名通常会使该域名增加4-7倍。这将对该域名所需的权威域名服务器与递归域名服务器缓存数据（因为它们也会缓存签名，公共密钥等等）的内存空间产生直接影响。递归域名服务器和权威域名服务器之间产生的流量也会增加。

如果你对DNSSec有所了解，可能会认为流量增加不会影响递归域名服务器进行验证，因为它不会将查询中的DO (DNSSec OK)设置到权威域名服务器。然而，现代BIND域名服务器是默认设置DO的，因此会收到DNSSec记录，无论是否使用其进行验证。何必如此费事呢？那些域名服务器无法确定作为转发器的下游域名服务器不能验证。下游服务器需要的是DNSSec记录。因此无论怎样，你的BIND域名服务器的缓存都会随着DNSSec记录的增加而增大。

执行验证的递归域名服务器上的CPU使用率也会随着DNSSec部署的增加而增加。验证单一RRSIG记录要求加密散列操作和非对称的解密操作；该过程所需的计算远比使未签署的DNS反馈脱离有线并反排列进缓存中所需的计算多的多。更糟的是，由于处理一个查询可能包含以下多个引用，每个引用都由可能需要验证的记录组成。如果你的域名服务器无法解析DNSKEY记录，该记录包含需要执行验证的公共密钥，那么它就需要另外发送查询进行寻找，从而不得不验证DNSKEY记录了！

当然，本文讨论的是DNSSec部署缓慢的问题。至少当许多DNS管理员读到这篇文章时，你无需担心你的递归域名服务器占用太多CPU周期来验证签署数据，或者DNSSec记录占用的内存。如果你生活在荷兰，那情况就不一样了。

以上因素共同作用，DNSSec部署缓慢也就不足为奇了。但是DNSSec采用的最大障碍如标准的不断变化，使用早期工具管理签署域名的困难等已不足畏惧。运维DNSSec的日常管理费用确实存在，它会随着签署越来越多的域名而逐步被引入。

剩下的只是动机了。或许某些人所在的组织机构或者所在的国家有部署DNSSec的切实激励机制，但绝大多数人没有这样的“胡萝卜”。不加入合规制度如PCI DSS或法律诉讼的威胁都不能作为强迫部署DNSSec的理由，部署DNSSec完全取决于你自己。然而，如果你希望继续使用互联网完成任何重大交易，广泛采用DNSSec绝对是必要的。我希望你可将此看作是我给你的“胡萝卜”。