DNSSec调研报告

DNSSec 调研报告刘冰洋2008310477清华大学计算机科学与技术系，北京，100084摘 要：DNS （域名系统）已成为互联网服务的重要基础设施，但它存在着严重的安全漏洞，近年来针对这些安全漏

DNSSec 调研报告

刘冰洋2008310477

清华大学计算机科学与技术系，北京，100084

摘 要：DNS （域名系统）已成为互联网服务的重要基础设施，但它存在着严重的安全漏洞，近年来针对这些安全漏洞的网络攻击给DNS 和互联网带来了巨大的损失。DNSSec 为DNS 提供了安全扩展功能，支持对数据源及事务和请求的认证，从而在一定程度上遏制了相关的网络攻击。本文回顾了DNS 的发展历程与其面临的安全威胁，介绍了DNSSec 的基本原理和组成部分，分析了DNSSec 存在的问题，调研了DNSSec 在全球的部署情况，并对其未来应用进行了展望。

关键词：DNS, DNSSec, DNS安全, 互联网安全.

Abstract : DNS (Domain Name System) is now a very important infrastructure of the Internet. However, it was designed with a lot of vulnerability. These years, the network attacks taking advantages of its vulnerability have brought huge damage to the DNS and Internet. DNSSec, the security extension of DNS, was designed to secure DNS. It supports the authentication of the data origin and transaction and request, so that it mitigates the relevant attacks. This paper reviews the history of DNS and its vulnerability, and introduces the rationale of DNSSec. We analyzed the problems in DNSSec, investigated its deployment progress around the world, and also presented the future application of DNSSec.

Keywords : DNS, DNSSec, Internet Security.

1 引言

1.1 DNS 发展历程

DNS （Domain Name System，域名系统）[1]出现之前，网络用户需要在本机上维护一个HOSTS 配置文件，这个文件包含本机与网络上的其他系统通信时所需要的信息。当网络变得复杂时，这样做的缺点是显然的：每台机器都需要手工维护一个HOSTS 文件，某一台机器的配置更新将导致每台与其通信的机器修改配置，网络规模增大时手工维护HOSTS 文件是不可行的。

1983年，在TCP/IP部署后不久，域名系统——即DNS ——被发明了出来。该系统用于命名组织到域层次结构中的计算机和网络服务[2]。DNS 负责将易于记忆的域名与计算机的IP 地址映射起来，供用户查询。DNS 于1983年成为国际标准，RFC882[3]和RFC883[4]分别描述了DNS 的概念和实现说明。DNS 大大推动了互联网、尤其是万维网的发展，逐渐成为全球性的重要互联网基础设施。

DNS 是一个树状结构，根域名为“. ”；顶级域名包括“.com ”、“.net ”、“.org ”、“.edu ”、“.gov ”等，还包括各国家和地区的顶级域名，如“.cn ”、“.au ”等。每个域又可以下设多

个子域，子域又可以再设子域，如此迭代下去。每个域内设置多台（一般至少为两台）域名服务器（Name Server），负责分配子域域名、维护域名到IP 地址映射关系的记录。

DNS 中的另外一种实体是域名解析服务器（Resolver ），它负责为客户主机（Client ）提供域名解析（即域名查询）的服务。它将一些域名到IP 地址的映射记录保存到本地，称为“缓存”，缓存需要定时更新。当用户所要查询的域名在这个缓存中没有命中时，它需要代理用户去查询该域名的权威域名服务器，并将查询结果转发给用户。这个“代理查询”的过程是从DNS 树的根节点开始，逐级向下递归查找，直到收到权威域名服务器的应答或请求超时。

逻辑上域名服务器与域名解析服务器是两个不同的概念和实体，而在现实的应用中，往往将二者合并起来，即一台域名服务器往往也提供了域名解析的服务——通常被统称为DNS 服务器。

下图给出了一个DNS 的查询过程的例子，主机（Client ）向本地DNS 服务器（DNS Server）提交对域名“contoso.com ”的查询请求，若该服务器的缓存中存在些条目，则向主机返回结果并结束此次查询，否则，它将向根域名服务器（Root Server）提交查询请求；根域名服务器将其指向“.com ”的顶级域名服务器（Com Server），后者再将其指向“contoso.com ”的权威域名服务器（Contoso Server）；最后由它把结果返回给本地DNS 服务器，后者将结果返回给查询的主机。此次过程结束后，本地域名服务器可能会将“contoso.com ”的记录保存到自己的缓存中，这样，下次有主机查询该域名时，就可以直接返回缓存中的结果了。

图 1 DNS查询实例

1.2 DNS 的安全隐患

正如互联网早期的许多协议一样，DNS 协议在设计之初也没有考虑到安全问题，所以在其不断的发展和应用过程中暴露了许多的安全漏洞，并出现了一些有针对性的安全攻击。比如：DNS 缓存污染（DNS Cache Poisoning）[5]、DNS 放大攻击（DNS Amplification Attack）

[6]、DNS 客户洪泛攻击（Client Flooding）[7]、DNS 动态更新攻击（DNS Dynamic Update Vulnerabilities ）[7]、域名欺诈（Domain Name Phishing）[8]等等。

这些安全问题中，DNS 缓存污染被认为是关系到互联网核心安全的决定性问题之一[9]。DNS 缓存污染是指一个DNS 解析服务器被注入了错误的缓存，比如将域名A 指向了域名B 的IP 地址。所谓的“注入”，即指该解析服务器在查询某域名记录时，接受了一个非权威域名服务器的错误回应，并将该错误回应保存到自己的缓存中。这种非权威域名服务器的“错误回应”可能由其错误的配置造成，可能是被黑客利用，也可能根本就不是域名服务器、而是黑客的一台计算机（比如实施中间人攻击）。通过DNS 缓存污染，可以造成用户无法正常访问网络（DoS ），可以将用户导向一个其不期望访问的网站（进而实施窃取信息、诈骗等），也可以将很多用户导向一个目标网站并使其瘫痪（DDoS ）。由于DNS 缓存污染攻击易于发起、危害巨大，逐渐成为互联网的重要安全威胁，也是成为了网络管理人员十分头疼的安全问题。

1.3 DNSSec 简介

DNSSec 是DNS Security Extensions（DNS 安全扩展）的缩写[10]。由于DNS 协议的安全漏洞和目前严重的安全问题，IETF 成立了dnssec 工作组（后来被取代为dnsext （DNS Extensions ）工作组[11]），研究DNS 协议的安全扩展。DNS 安全扩展制订了一系列RFC ，包括概念技术、协议设计、报文格式、哈希算法、密钥管理等多方面。这些RFC 几经更新，目前较为广泛接受的协议描述是RFC2535[12]，该协议在RFC4035进行了更新[13]。由于有关DNSSec 的一系列RFC 还在设计中，尚未有定论，本文主要介绍RFC2535中所描述的DNSSec 。

DNSSec 的目标是为DNS 解析服务器（Resolver ）提供数据源认证和数据完整性验证的功能。通过DNSSec 的部署，可以增强对DNS 域名服务器的身份认证，进而帮助防止DNS 缓存污染等攻击——DNSSec 是实现DNS 安全的重要一步和必要组成部分。

1.4 本文主要内容与文章结构

本文主要介绍DNSSec 的原理，分析可能存在的问题，调研其部署现状，并对分析其应用前景。

本文后续部分组织如下：第2章介绍DNSSec 的原理和组成部分；第3章对DNSSec 进行分析，指出其可能存在的问题；第4章介绍DNSSec 的部署现状，并对其未来的应用前景进行分析；第5章总结全文；致谢和参考文献分别在第6和第7章。

2 DNSSec 的原理与组成

2.1 DNSSec 的目标

DNSSec 协议的设计要遵循以下目标和设计原则：

1) 为DNS 解析服务提供数据源身份认证和对数据完整性验证。从而扼制DNS 缓存污

染等攻击。

2) 不强制进行访问控制或者数据加密。DNS 是一个公共的网络服务基础设施，不能因

为访问控制或数据加密的引入破坏这一基本前提，但是DNSSec 也不强制不能进行数据的加密。

3) 向后兼容。即DNSSec 协议的数据可以被旧版本的DNS 协议正确存储和分发（尽

管可能无法正确解释）。

4) 支持增量部署。互联网中一部分部署了DNSSec 的域可以在其它域不部署DNSSec

的情况下实现部署收益。

2.2 DNSSec 的基本原理

DNSSec 利用哈希算法计算报文摘要，从而实现数据完整性验证；利用公钥机制实现对数据源的认证。简单地来看：部署了DNSSec 的权威域名服务器在应答查询请求时，首先使用哈希算法计算应答报文的摘要，再将此摘要用自己的私钥加密生成签名后存储到报文中；查询方收到应答报文，利用该服务器的公钥解密签名获得摘要，再将此摘要与从报文数据计算出的摘要进行对比来完成数据的完整性的验证。如果数据完整性验证成功，则也同时完成了对数据源（权威域名服务器）的身份认证，否则认识身份认证失败。

DNSSec 可以在以下三种实体上进行部署：DNS 域名服务器（Name Server）、DNS 解析服务器（Resolver ）、DNS 客户端（Client ）。

2.3 DNSSec 的组成部分

DNSSec 由以下几个部分组成：

1) 密钥分发

DNSSec 的密钥（尤指属于某一域名的公钥）分发机制不仅可以分发用于DNS 域验证的公钥，而且可以支持与域名有关的非以DNS 目的的其它信息的分发。公钥的分发支持多种密钥类型和多种密钥算法。具体的密钥分发系统和密钥算法暂不讨论。

2) 数据源认证

数据源认证是DNSSec 设计的核心目标。其基本原理已经在2.1节中进行了描述。

3) DNS 事务与请求认证

DNS 事务与请求认证是为了对DNS 的查询请求和DNS 消息头进行验证。这项验证保证了域名服务器的请求应答可以达到请求的发送者、并且该应答来自请求者想要查询的服务器。要做到这些，只需要对回送的应答报文的签名进行一些处理——即，使用一些与请求和应答相关联的信息来生成签名——这样，就一举两得地实现了双向认证。

3 DNSSec 协议分析

3.1 安全性分析

DNSSec 借助公钥机制对数据完整性和数据源进行验证（在事务与请求认证中，也提供了对请求方的身份认证）。通过数据源认证，可以在一定程度上遏制DNS 缓存污染和DNS 客户洪泛攻击；通过事务与请求认证，可以减少DNS 动态更新攻击的危害。然而，对于DNS 放大攻击、域名欺诈等，由于它们的原理不是假冒数据源，而是利用假冒源地址或者近似域名等手段，所以难以通过DNSSec 来防治。

3.2 运算代价

引入DNSSec 之后，DNS 域名服务器在应答一个请求时，需要在原有的计算量基础上，增加对数据内容的哈希运算，以及对摘要的签名运算——我们知道，哈希算法如MD5（在RFC2537[14]中被规定为一种摘要生成算法）的运算量是很大的——这就大大增加了DNS 域名服务器的计算负荷；同样，对应答报文的认证也需要类似的运算代价。这就使得DNS 域名服务器或者域名解析服务器可能成为DoS 的攻击目标。实际上，目前很多部署了DNSSec 的域都相应的升级了硬件设备（比如升级了多核的处理器），来应付增加的计算开销。

3.3 密钥管理

但凡引入公钥机制的系统设计都会遇到密钥管理、分发的问题。公钥机制的引入往往意味着要引入一套完整的公钥基础设施，而这是很难做到的——这也正是IPSec 之所以至今没有得到广泛应用的原因之一。而这个问题相对于DNS 来说，可能没有严重，因为它本身的树形结构和已经形成完善的管理体系，公钥体统的建立并不难。然而，由于DNSSec 并不可能一夜之间部署到整个互联网，而是一部分一部分的增量部署起来的，所以必然使得那些先部署了DNSSec 的子域形成一个一个的“孤岛”，它们之间的密钥管理和分发机制还没有一个完善的解决方案：比如，如果一个域的私钥泄露，想要撤消这对密钥并使用一对新的密钥，目前还无法解决。总之，DNSSec 使用公钥体系比起其它系统（如IPSec ）有基础设施的优势，但仍然存在着一些困难。

3.4 管理代价

DNSSec 固然为DNS 服务提供了一套安全解决方案，但由于DNSSec 比原来简单的DNS 复杂的多，那么培训一个得力的网络管理人员，由其负责升级设备或软件、配置系统、处理故障等工作，都较原来更为复杂，从而为网络运行机构引入了较大的管理开销。 4 DNSSec 的实现与部署

4.1 DNSSec 的实现

本节将介绍BIND （Berkeley Internet Name Daemon）和Windows Server 2003 DNS提供的对DNSSec 相关功能的支持。

4.1.1 BIND

BIND 是一个实现DNS 协议的开源软件[15]。它是DNS 相关协议族的参考实现，但仍然可以作为产品级的软件。迄今为止，它是互联网中被使用最为广泛的DNS 软件。BIND 最初由美国加州大学伯克利分校的几名毕业生编写，并发布在4.3BSD 上。现在由Internet Systems Consortium进行维护和支持。

自从版本8.1.2开始，BIND 发布了对DNSSec 的支持。目前其最新版本为9.6.1。BIND 宣布其支持DNSSec 相关的所有标准。

本文不对BIND 的配置、使用方法进行介绍。

4.1.2 Windows Server 2003 DNS

Windows Server 2003 DNS是一套运行在Windows Server 2003上的提供DNS 服务的应用程序[16]。它并不完全支持RFC2535中所述的所有DNSSEC 的特性，而只提供RFC2535中定义的“基本支持”。

本文不对Windows Server 2003 DNS的配置、使用方法进行介绍。

4.2 DNSSec 的部署情况

前面已经提到，DNSSec 支持增量部署；在实际的部署过程中，也正是先有一部分网络（或域）部署起来，目前部署的范围正在逐渐扩大。

网站xelerance 发布了截止到2007年11月21日，全球范围内的DNSSec 的部署情况[17]，如下图：

图 2 DNSSec在全球范围内的部署情况

可见许多顶级域名服务商已经开始部署了DNSSec 。截止2007年11

月，中国大陆还没

有DNSSec 的部署。

2008年12月，“代表着超过1.12亿个域名(占所有已注册域名的65)的七家主要域名厂商已经组建了一个行业联盟，宣布共同采用DNS 安全扩展机制—DNSSEC 。 DNSSEC 行业联盟包括：运营.com 和.net 注册业务的VeriSign 、运行.biz 和.us 注册业务的NeuStar ；.info 运营商 Afilias Limited；.edu 运营商EDUCAUSE 以及运营.org 注册业务的The Public Interest Registry ”[18]。可见，从这些顶级域名的运营商开始，DNSSec 要逐渐在全球范围内大规模部署开去了。

此外，DNSSEC Deployment Initiative网站上也提供了有关DNSSec 部署的方法和动态新闻[19]。

5 总结与展望

DNS 已经成为互联网上重要的服务系统和基础设施，然而传统的DNS 协议却存在着诸多安全漏洞，利用这些漏洞的网络攻击已经给DNS 和互联网服务带来了巨大的破坏。DNSSec 提出为DNS 安全提供了一套较好的解决方案，它通过利用公钥机制对数据源或事务请求双方的认证，从而在一定程度上防止DNS 服务器伪造的问题，遏制了DNS 缓存污染、DNS 客户洪泛攻击和DNS 动态更新攻击的实施。

然而，DNSSec 也存在着一些问题，比如：它不能防止DNS 放大攻击、域名欺诈等，哈希、签名运算开销过大、容易成为DoS 的攻击目标，密钥管理体系较为复杂、尚有一些未被解决的问题，协议较为复杂、带来管理和维护上的负担等等。这些问题中，有些是DNSSec 本身无法解决也不计划去解决的问题（如防止DNS 放大攻击、域名欺诈等），而还有一些是待解决的问题。

由于针对DNS 的攻击越来越多，DNSSec 的部署得到了越来越多运营商的重视，近年来其部署速度加快，而顶级域名运营商组成的行业联盟则更是加快了其部署的进度。由于DNSSec 本身的重要性、相关标准的相对完善性、行业普遍的重视程度和DNS 系统本身建立公钥系统的天然优势，我们有理由相信，DNSSec 将会在未来10年内快速地在全球范围内部署，并且逐步取代原有的DNS 。

6 致谢

感谢段海新老师和张甲同学的指导和帮助。

7 参考文献

[1] “Domain Name System,” Wikipedia, June 2009.

[2] “DNS,” 百度百科, baike.baidu.com/view/22276.htm, June 2009.

[3] P. Mockapetris, “DOMAIN NAMES - CONCEPTS and FACILITIES,” RFC 882, November

1983.

[4] P. Mockapetris, “DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION,” RFC

883, November 1983.

[5] “DNS cache poisoning,” Wikipedia, June 2009.

[6] Niranjan, “DNS Amplification Attack,” Security Tools News & Tips, February 2007.

[7] Diane Davidowicz, “Domain Name System (DNS) Security,” Yahoo Geocities, 1999.

[8] “Domain name phishing schemes a growing problem,” Internet-Security.ca, December 2006.

[9] S. Bellovin, “Report of the IAB Security Architecture Workshop,” RFC 2316, April 1998.

[10] “Domain Name System Security Extensions,” Wikipedia, June 2009.

[11] “DNS Extensions (dnsext) Charter,” IETF, April 2009.

[12] D. Eastlake, “Domain Name System Security Extensions,” RFC 2535, March 1999.

[13] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose, “Protocol Modifications for the

DNS Security Extensions,” RFC 4035, March 2005.

[14] D. Eastlake, “RSA/MD5 KEYs and SIGs in the Domain Name System (DNS),” RFC 2537,

March 1999.

[15] “ISC BIND,” Internet Systems Consortium (ISC.org).

[16] Microsoft TechNet, “DNSSEC 概述,” Microsoft TechNet中文主页.

[17] Paul Wouters, “World Wide DNSSEC Deployment,” ,

November 2007.

[18] 网界网佚名, “致力保护DNS 安全 顶级域名运营商采用DNSSEC,” 网界网,

[19] DNSSEC Deployment Initiative, .