DNSSEC部署：山雨欲来风满楼

文/张子蛟 高金峰 王炯炜 胡宏伟

DNSSEC部署：山雨欲来风满楼

文/张子蛟 高金峰 王炯炜 胡宏伟

2010年5月5日，ICANN宣布已在13个根域服务器上部署DNSSEC（DNS Security Extensions，DNS安全扩展），让业界感到非常突然。DNSSEC作为解决现有DNS体系数据安全性的一个方案，业界认为其部署和实施存在较大的困难和协议缺陷。该项工作的加速实施，可能的原因是近期很多知名网站，例如Twitter、Facebook、百度等，包括一些银行网站被成功实施域名劫持攻击，影响巨大。另一个可能原因是来自美国商务部的压力。

DNS（Domain Name System域名系统）是因特网的关键基础设施，其体系的核心是13台根域服务器，由ICANN（The Internet Corporation for Assigned Names and Numbers，互联网名称与数字地址分配机构）负责管理。

部署DNSSEC，我们该如何应对？实际上，5月5日13个根域服务器并非正式部署DNSSEC，我们先从ICANN的DNSSEC部署时间表谈起。

ICANN 的部署时间表

下面是来自I C A N N官方网站的DNSSEC部署时间表：

2009年12月1日：为VeriSign和ICANN提供内部使用的签名根域。ICANN和VeriSign用来试验使用KSK（Key Signing Key，密钥签名密钥）对ZSK（Zone Signing Key，区域签名密钥）签名的交互协议。

2010年1月：第一个根服务开始以DURZ（deliberately unvalidatable root zone，故意无效根域）的形式提供签名根服务。这些DURZ包含无用的密钥，用来替代根KSK和ZSK，以防止这些密钥被正式使用。

2010年5月上旬：所有的根服务器均提供DURZ。从签名根返回的大尺寸响应报文（大于512字节）的影响可能开始显现。

2010年5月～6月：对DNSSEC部署的方法进行试验，并确定DNSSEC在根域的最终部署方案。

2010年7月1日：ICANN公布根域信任锚（trust anchor），且根操作器开始使用正式密钥提供签名根域服务——签名根域正式投入使用。

以上时间表暂定，可能根据实际测试结果进行调整。截止到目前，已如期执行到第三步。从时间表上看，5月5日部署的仅是DURZ，而非正式的部署，所有根服务器将继续响应非DNSSEC域名查询，但对仅请求DNSSEC的查询会有所影响。总的来讲，DNSSEC部署的这个步骤并未对现存的DNS体系和运行产生大的影响。

但2010年7月1日签名根域正式投入使用时，对因特网，特别是对我国互联网的影响和风险，需要认真评估并做出预案。

从长期看，即使全球所有域名服务器都部署了DNSSEC，新的DNS体系也应该继续响应不支持DNSSEC的客户端查询，直至不支持DNSSEC的老式客户端彻底退出因特网。

图1 DNSSEC域名解析过程示意

DNSSEC域 名解析过程与分析

如图1所示，以解析www.zzu.edu.cn为例，DNSSEC体系下的解析过程如下：

① 客户端向根服务器发出解析.cn的非递归请求。在这之前，客户端应该拥有根域的公钥。

② 根服务器以根私钥对响应报文进行签名，响应报文包括根域服务器信息、.cn域的权威地址、.cn域的公钥。客户端收到报文后，以根公钥对其进行解密验证。

③ 客户端向.cn服务器发出解析.edu.cn的非递归请求。此时，客户端已拥有.cn公钥。

④ .cn服务器以.cn私钥对响应报文进行签名，响应报文包括.cn域服务器信息、.edu.cn域的权威地址、.edu.cn域的公钥。客户端收到报文后，以.cn公钥对其进行解密验证，得到.edu.cn公钥和其权威地址。

⑤ 客户端向.edu.cn服务器发出解析.zzu.edu.cn的非递归请求。

⑥ .edu.cn服务器以.edu.cn私钥对响应报文进行签名，响应报文包括.edu.cn域服务器信息、.zzu.edu.cn域的权威地址、.zzu.edu.cn域的公钥。客户端收到报文后，以.edu.cn公钥对其进行解密验证，得到.zzu.edu.cn公钥和其权威地址。

⑦ 客户端向.zzu.edu.cn服务器发出解析www.zzu.edu.cn的非递归请求。

⑧ .zzu.edu.cn服务器以.zzu.edu.cn私钥对响应报文进行签名，响应报文包括.zzu.edu.cn域服务器信息、www.zzu.edu.cn的解析结果。客户端收到报文后，以.zzu.edu.cn公钥对其进行解密验证。得到最终结果。

从上面的解析过程可知，从根域开始，由上到下逐级签名验证的方式称为信任链（Trusted Chain），即父域与子域之间步步为营、逐级建立信任关系。根域是整个DNSSEC体系的核心和安全入口，每一个支持DNSSEC的DNS解析器都需要安装根公钥，以建立与根域之间的信任关系。每一个域通过RSA/SHA-1密码算法为下级域产生一个公钥/私钥对，下级域的公钥保存在本域，私钥下发给下级域的权威服务器。由此可以看出，下发私钥从安全上来说是一个关键环节。

值得一提的是，美国商务部有可能成为DNSSEC根密钥和根域信任锚的惟一掌控者，这可能使DNSSEC的部署难以被部分专家和国家所接受。VeriSign公司作为根域的管理者之一、DNSSEC部署的重要推手和两个炙手可热的通用顶级域（.com与.net）的掌控者，其主营业务之一即是电子证书销售。在DNSSEC最终的部署方案被确定之前，VeriSign公司是否会在构建DNSSEC信任链的电子证书方面提出有利其主营业务的诉求，我们拭目以待。

图2 DNSSEC信任链示意图

部署时机和概况

对整个因特网来讲，DNSSEC的部署是一个新课题，实施的效果是否能达到预期，有待从长期的实践中观察。仅从部署DNSSEC的时机上来说，DNSSEC的部署还是具备了较为坚实的基础：

截至今年，DNSSEC已有15年的技术积累。DNSSEC的固有缺陷得到逐步的弥补；

近几年来，因特网的网络条件提高很快，带宽得到大幅度提高，新的设备全部支持DNSSEC，不支持DNSSEC的老设备逐步淘汰；

电子商务和社会性网络服务日益发展，民众对因特网的可靠性提出更高要求，而DNS欺骗日益猖獗；

2009年美国商务部在实施DNSSEC方面提出明确需求和日程表。美国的.gov域于2009年率先实施了DNSSEC；

DNS系统Kaminsky漏洞的发现；

操作系统软件、浏览器软件、DNS服务软件的新版本（例如Windows 2008 R2、Windows 7、Bind 9等）提供对DNSSEC的完全支持；

VeriSign宣称，2011年第一季度将在其所管理的.net和.com顶级域上全面实现DNSSEC。

综上所述，从2009年开始，全球掀起了一个DNSSEC的部署高潮，有“山雨欲来风满楼”之势。

图3 相对于DNS，DNSEC占用网络带宽情况

局限性和对策构想

与老DNS系统相比，DNSSEC的最大问题是标记和校验计算增大了服务器的系统开销，从而影响整个DNS体系的响应能力和服务性能。增大的DNS数据包，以TCP替换UDP传输DNS报文，加重了DNS对整个因特网连接的负担。据测试，在NSEC3下，TCP流量相比于UDP通信增加了600倍。同样的解析任务，DNSSEC数据流量相对DNS增加4倍多（图3）。要缓解这个问题，一是需要升级DNS服务器硬件，二是在DNSSEC服务软件中采用一系列优化策略，例如采用类似组播或P2P的技术，以降低DNSSEC对网络带宽的占用。

老DNS对抗DDos（分布式拒绝服务）攻击没有非常有效的办法，采用DNSSEC后，这一点更是雪上加霜。解决的可能方案也是采用类似P2P的技术，以分布式和冗余性抗击DDos攻击，也提高了DNSSEC的鲁棒性。

2003年以前生产的一些路由器、防火墙及其他老网络设备，有不少不支持大DNS报文的传输。一种情况是会拒绝这些报文的通过，这恐怕要考虑类似IPv6 over IPv4的解决办法；另一种情况是将大DNSSEC包拆分，这仅影响速度，无妨。

从上面的讨论，我们知道，DNSSEC数据的安全性主要依赖于公钥体系的安全性，尽管DNSSEC已从技术上采取了一系列措施，例如使用KSK、SSL传输等。由于DNSSEC密钥管理体系较为复杂，协议本身也较为复杂，增加了部署、管理和维护上的负担。这些都需要时间来解决。

另外，DNSSEC并没有解决子域名系统自治、多DNS镜像速度优先的问题。

DNSSEC的部署和实施是一个复杂、全球性的系统工程。DNSSEC的实施，非技术方面的问题大于技术方面，特别是对现有DNS体系的向下兼容性方面，是DNSSEC实施的成败关键。作为对现有DNS基础设施的全面升级，我们没有理由不对其充满信心，并为之尽一份微薄之力。

（作者单位为郑州大学网络管理中心）