域名系统安全研究综述
第28卷第9期2007年9月 通 信 学 报 V ol.28 No.9Journal on Communications September 2007域名系统安全研究综述王垚 1,2,胡铭曾
第28卷第9期
2007年9月 通 信 学 报 V ol.28 No.9Journal on Communications September 2007
域名系统安全研究综述
王垚 1,2,胡铭曾 1,李斌 1,闫伯儒 1,3
(1. 哈尔滨工业大学 计算机网络与信息安全研究中心, 黑龙江 哈尔滨 150001;
2. 中国外汇交易中心,上海201203;3. 微软亚洲工程院,北京 100086)
摘 要:作为互联网关键基础设施的域名系统(DNS)其安全性正面临严峻考验。协议设计脆弱性导致数据信息真
实性和完整性得不到保证;配置故障普遍存在,系统冗余性降低,单点失效问题严重;系统规模不断扩大导致管
理难度急剧增加。从协议脆弱性、实现脆弱性和操作脆弱性3个方面对域名系统面临的威胁进行分类,综述了针
对这些安全威胁的改进方案和研究成果,并论述了进一步研究中需要解决的关键问题。
关键词:域名系统;互联网基础设施;网络安全
中图分类号:TP393.08 文献标识码:A 文章编号:1000-436X(2007)09-0091-13
Survey on domain name system security
WANG Yao1,2, HU Ming-zeng1, LI Bin1, YAN Bo-ru1,3
(1. Research Center of Computer Network and Information Security Technology, Harbin Institute of Technology, Harbin 150001, China;
2. China Foreign Exchange Trade System, Shanghai 201203, China; 3. Microsoft Adranced Technology Center , Beijing 100086, China)
Abstract: DNS(domain name system), as the critical Internet infrastructure, its security is facing great challenge. Proto-
col design vulnerability provides no assurance for data authentication and integrity. Configuration errors are widespread
with diminished server redundancy and severe single point of failure. The continuous development of system scale leads
to the dramatic difficulty in administration. The threats towards DNS were categorized according to protocol, implemen-
tation and operation vulnerability. The improvements and resolutions to these threats were summarized and the new
problems in future study work were discussed.
Key words: domain name system; Internet infrastructure; network security
1 引言
DNS(domain name system,域名系统) 是互联网
上最为关键的基础设施,其主要作用是将易于记忆
的主机名称映射为枯燥难记的IP 地址[1,2],从而保
障其他网络应用(如网页浏览、电子邮件等) 顺利执
行。作为全球最大也是最为成功的分布式数据库系
统,其效率和普及程度是其他服务无法比拟的。一
旦遭受攻击,会给整个互联网带来无法估量的损失。然而近年来对互联网安全性的研究主要集中在信息安全方面,通常使用认证(authentication)和加密(encryption)等手段来保证信息的机密性(confidentiality)和完整性(integrity),但这是以互联网基础设施安全可靠为前提的,针对关键设施的安全事件频繁发生(如DNS 欺骗和路由重定向) 使得这一假设受到前所未有的挑战。作为互联网基础设施,DNS 存在极大的安全隐患,主要表现在:1) 协议设计存在较大的脆弱性(vulnerability),缺乏必要收稿日期:2006-04-20;修回日期:2007-08-01
基金项目:国家重点基础研究发展计划(“973”计划) 基金资助项目 (G2005CB321806)
Foundation Item: The National Basic Research Program of China (973 Program) (G2005CB321806)
,·92· 通 信 学 报 第28卷
的安全性考虑,数据信息真实性(authenticity)和完整性得不到保证;2) 系统规模不断扩大导致管理难度急剧增加,人为错误因素使得配置故障普遍存在,系统冗余性(redundancy)大大降低,单点失效(single point of failure)问题严重;3) 对DNS 安全性的各种改进措施难以大规模应用,且往往又引入新的安全问题。本文综述了DNS 安全领域的最新研究进展,对当前DNS 面临的安全威胁进行了分类比较,从脆弱性、系统可用性(availability)和可生存性(survivability)等角度阐述了研究者提出的各种改进方法和措施,并指出了其难点和未来的研究方向。
本文第2节概述DNS 安全问题现状。第3节对DNS 面临的安全威胁进行分类比较。第4节综述增强DNS 安全性的各种研究方案。第5节展望进一步的研究工作。第6节为结束语。
2 DNS安全问题现状
2.1 DNS基本概念
DNS 服务是互联网上大部分服务和应用正常运转和实施的基础,从Web 到邮件服务,从负载均衡到服务发现(service discovery),DNS 服务已经深入到互联网的各个角落,成为互联网上不可或缺的关键一环。DNS 主要包括3个组成部分,分别是:域名空间(domain name space)和资源记录(resource record) ;名字服务器(name server);解析器(resolver),如图1所示。

图1 DNS体系结构
1)DNS 以域名为索引,每个域名是一棵很大的逆向树中的路径,这棵逆向树就称为域名空间。而域名则被存放在称为资源记录的数据结构中。
2)名字服务器是存储有关域名空间信息的程序,它作为DNS 客户/服务器机制的服务器端,通
常含有域名空间中某一部分的完整信息,这一部分称之为区(zone)。名字服务器分为权威名字服务器和缓存名字服务器2种。
3)解析器是DNS 客户/服务器机制的客户端,通常作为库例程存在,供需要使用名字服务的应用程序引用,负责向名字服务器查询信息并将结果返回给调用它的应用程序。 2.2 DNS 安全现状
近20年来,DNS 服务发展迅速,其注册规模越来越大,管理难度也急剧增加。据美国互联网海量数据中心(ISC)统计,1987年全球DNS 注册主机数仅有20 000条,但截止到2007年1月已增至433 193 199条。其独立域(independent zone)的个数也由1987年的几个增加到2005年的8 290万个[3]。此外,射频识别(RFID)和移动计算等应用的出现和普及使得DNS 的数据发生动态变化。以DNS 作为高可靠性公钥基础设施(PKI)的需求使得DNS 系统的安全性和健壮性问题亟待解决。然而作为互联网的早期协议,DNS 从设计之初就建立在互信模型的基础之上,是一个完全开放的协作体系[2],其上存在的各类数据从未进行加密,没有提供适当的信息保护和认证机制,也没有对各种查询进行准确识别,同时对网络基础设施和核心骨干设备的攻击没有受到足够重视,使得DNS 很容易遭受攻击。2005年3月美国系统网络安全协会发布的关于域名欺骗攻击的警告指出,新一轮攻击中大批.com 域名成为牺牲品,至少有1 300个域名被诱骗到被攻陷的网络服务器[4]。在其公布的2004年度Top20网络安全隐患排行榜中,DNS 的主要应用软件BIND(berkeley Internet name domain)更是排在UNIX 及Linux 操作系统相关安全隐患的首位[5]。由此可见,加强防范对DNS 的攻击、确保DNS 系统安全已经到了刻不容缓的地步。
除了脆弱性之外,DNS 系统本身的可用性和可生存性也是众多学者、研究人员和运营商普遍关注的问题。大部分DNS 服务器为提高可用性都会使用冗余和缓存机制,通常使用多个权威DNS 服务器来提供服务,每台服务器又会缓存客户查询过的信息。但是据统计全球大约有38.78的网站将所有DNS 服务器部署在同一子网内[6],其可生存性大大降低,一旦其所在网络遭到攻击或发生严重的电力故障,会导致整个DNS 系统瘫痪,存在着严重的单点失效问题。此外,缓存的存在虽然减少了访问
,第9期 王垚等:域名系统安全研究综述 ·93·
时间,却是以牺牲一致性(consistency)为代价的,同时也使得服务器发生缓存中毒的机率增大,极大削弱了DNS 系统的可用性。动态更新不及时或发生中断也会降低DNS 系统的可用性。主从服务器之间数据更新缺乏连贯性,客户可能从一些服务器得到陈旧数据,从而导致非故意性攻击。在更新过程中,如果主名字服务器崩溃,一些更新数据就会永久丢失。对DNS 服务器的错误配置也将大大降低DNS 的可用性。文献[7]研究结果显示无用授权(lame delegation)配置错误影响了15的DNS 区,而 .cn 域下存在无效授权错误的区更以高达36的比例排在首位,大约2的区存在循环依赖错误,服务器冗余降低问题普遍存在。
3 DNS 安全威胁分类
一个系统之所以受到威胁,是因为其本身存在可以被渗透的脆弱性,或称弱点。脆弱性被定义为设计、实现和操作过程中的错误或弱点,分为协议脆弱性、实现脆弱性和操作脆弱性3类。本节从这3个方面对DNS 系统面临的安全威胁进行分类比较,如图2所示。 3.1 协议脆弱性
协议脆弱性主要是系统在设计之初对前提假设条件考虑不够充分或之后条件发生变化导致的。由于使用的长期性和广泛性,使得这类脆弱性通常很难从根源上得到修正,DNS 在这一方面极具代表性。由DNS 协议缺乏必要的认证机制,客户无法确认接收到的信息的真实性和权威性,基于名字的认证过程并不能起到真正的识别作用,而且接收到的应答报文中往往含有额外的附加信息,其正确性也无法判断。此外,DNS 的绝大部分通信使用UDP ,数据报文容易丢失,也易于受到劫持和欺骗。DNS 协议脆弱性面临的威胁主要是域名欺骗和网络通信攻击。
3.1.1 域名欺骗
域名欺骗是指域名系统(包括DNS 服务器和解析器) 接收或使用来自未授权主机的不正确信息。在此类威胁中,攻击者通常伪装成客户可信的DNS 服务器,然后将伪造的恶意信息反馈给客户。域名欺骗主要是事务ID 欺骗(transaction ID spoofing)和缓存中毒(cache poisoning)。
1) 事务ID 欺骗
当前最常见域名欺骗攻击是针对DNS 数据报头部的事务ID 来进行欺骗。由于客户端会用该ID 作为响应数据报是否与查询数据报匹配的判断依据,因此可以通过伪装DNS 服务器提前向客户发送与查询数据报ID 相同的响应报文,只要该伪造的响应报文在真正的响应报文之前到达客户端,就可以实现域名欺骗。对ID 的获取主要采用网络监听(sniffing)和猜测序列号两种方法。其中网络监听比较简单,由于DNS 数据报文都没有加密,因此如果攻击者能够监听到客户的网络流量即可获得事务ID 。攻击者通常使用ARP 欺骗的方法进行监听,但是这种方法要求攻击者必须与客户处于同一网络环境中。为突破这种限制,很多攻击者开始采用猜测序列号的方法来进行欺骗。由于DNS 查询报文的事务ID 字段为2个字节,限制了其ID 值只能是0~65 535,大大降低了猜测成功的难度。在此过程中,攻击者通常对提供真实报文的名字服务器发动DoS 攻击,延缓正确应答报文返回,从而保证虚假的应答报文提前返回给客户端。
2) 缓存中毒
为了减少不必要的带宽消耗和客户端延迟,名字服务器会将资源记录缓存起来,在数据的生存期(TTL)内客户端可以直接向其查询。使用缓存可以提高DNS 基础设施的有效性和可扩展性[8]。而攻击者则利用DNS

协议中缓存机制中对附加区数据不
图2 DNS系统安全威胁分类
,·94· 通 信 学 报 第28卷
做任何检查的漏洞,诱骗名字服务器缓存具有较大TTL 的虚假资源记录从而达到长期欺骗客户端的目的[9]。在有效TTL 时段内,缓存的虚假资源记录会扩散到其他名字服务器,从而导致大面积的缓存中毒,很难彻底根除。缓存中毒给互联网带来了新的挑战,其攻击方式主要有以下几个特点:1) 攻击具有隐蔽性,不用消耗太多网络资源就可以使性能急剧受损;2) 采用间接攻击方式使得客户端和服务器都受到攻击;3) 使用貌似合法的记录来污染缓存,很难检测出来;4) 目前的缓存设计缺乏相应的反污染机制,对于精心组织的恶意缓存中毒攻击更是束手无策。
3.1.2 网络通信攻击
针对DNS 的网络通信攻击主要是DoS(denial of service,拒绝服务) 攻击、恶意网址重定向和中间人(man-in-the-middle)攻击。
DoS 攻击是最难解决的一类网络安全问题,具有实施成本低、防范难度大、攻击能力强和隐蔽效果好等特点,危害性极大。同其他互联网服务一样,DNS 系统容易遭受拒绝服务攻击。针对DNS 的拒绝服务攻击通常有两种方式:一种是攻击DNS 系统本身,包括对名字服务器和客户端进行攻击,另一种是利用DNS 系统作为反射点来攻击其他目标。在针对DNS 系统的DoS 攻击中,主要通过发送否定回答显示域名不存在,从而制造黑洞效应,对客户端造成事实上的DoS 攻击,而对名字服务器的攻击则主要是以root 等根名字服务器为目标[10]。在反射式攻击中,攻击者也经常利用root 等顶级服务器作为反射点,用DNS 应答对目标进行洪泛攻击[11]。虽然攻击目标不是DNS 系统本身,但由于DNS 承担域名和IP 地址映射的任务,攻击者通过查询被攻击目标的域名IP 地址,使得DNS 收到大量的查询请求从而同样间接受到DoS 攻击。此外,由于DNS 协议设计上的原因,查询报文通常很小,而响应报文在采用UDP 传输情况下最大可达512字节,因而能够产生放大式的攻击效果,并且超过512字节的报文又采用TCP 传输,更增加了DoS 攻击成功的概率。与Smurf 、Fraggle 等传统IP 欺骗方法通过广播报文实施DoS 攻击不同,针对DNS 的攻击通常利用普通查询过程中DNS 响应报文尺寸远大于请求报文尺寸以及区传送或递归查询过程中DNS 响应报文数量远大于请求报文数量等特点来放大攻击流量,从而产生“四
两拨千斤”的攻击效果。
在恶意网址重定向和中间人攻击过程中,攻击者通常伪装成客户可信任的实体对通信过程进行分析和篡改,将客户请求重定向到假冒的网站等与请求不符的目的地址,从而窃取客户的账户和密码(例如信用卡账号和网上银行密码) 等机密信息,进行金融欺诈和电子盗窃等网络犯罪活动。针对DNS 的攻击工具可以参考Dug Song开发的DSniff 工具包[12]。其中的DNSSpoof 和WebMITM 可以用来对DNS 进行域名欺骗和中间人攻击。 3.2 实现脆弱性
历史上关于计算机或者计算机网络的很多著名安全问题不是由于算法或是协议缺陷造成的,而是由实现错误引起的,通常是在编码阶段由于安全编码水平不高以及程序测试不全面导致在某种特定条件下程序执行出现异常和错误,从而引发灾难性后果。具有代表性的是利用缓冲区溢出(overflow)来发起攻击,而作为分布式系统典型代表的DNS 在这方面也伤痕累累。
1992年,Danzig 等人[11]从类RPC 流(RPC-like traffic) 的角度对DNS 的一个根名字服务器进行了测量,发现其在缓存机制、超时重传算法和替代服务器选择算法方面存在7类实现错误。研究表明由于这些错误的大量存在导致DNS 占用的广域网带宽超出其所需带宽20倍以上。2001年,Brownlee 等人[13,14]对F 根服务器和通用顶级域名服务器(gTLD)的安全性进行了全方位的测量,结果显示尽管历经了10年,Dnazig 在1992年发现的DNS 脆弱性依然大量存在,伪造的A 类型查询、重复查询、无效TLD 查询以及利用根服务器发起的DoS 攻击不仅极大影响了全球DNS 的性能,也严重威胁着整个互联网的安全性。
作为应用最为广泛的DNS 软件,BIND 的漏洞和缺陷无疑给DNS 带来严重的威胁,其缓冲区溢出漏洞一度占据UNIX 及Linux 操作系统相关安全隐患的首位[5]。此外,9.0版本之前查询报文的事务ID 和源端口号并非随机生成[15]。Sacramento [16]还发现BIND 4.x和8.x 两个系列会允许客户向同一IP 地址同时发送多个递归查询请求,由此衍生出一种称为生日悖论(birthday paradox) [17]的攻击方法,这种攻击方法增加了成功猜测到正确的事务ID 的可能性,受到广泛的关注。式(1)给出了成功概率P 的计算公式,其中t
,第9期 王垚等:域名系统安全研究综述 ·95·
3.3.2 域名注册攻击
域名注册攻击的方法主要有域名劫持(domain
n ×(n −1) hijacking) 和类似域名注册。域名劫持是对域名注册2⎛1⎞
(1) p =1−⎜1−⎟管理公司的注册域名记录非法改变使之指向其他t ⎝⎠
Web 站点。攻击者通常会利用域名注册时限,利用
如图3所示,利用生日悖论定理,攻击者只需原域名拥有者忽略域名时限的空隙,购买刚到期的发送800个报文就几乎能够100地预测出事务ID 域名占为己有,或者通过冒充原域名拥有者以电子[18]值,大大减少猜测过程中随机生成的DNS 报文数邮件等方式向域名注册管理公司提出请求修改注量和攻击时间,使得这种攻击更容易得手。另一种册域名记录,将域名重定向到另一组织或站点[21]。攻击方法称为相位空间(phase space)欺骗攻击,基于而类似域名注册攻击通常是利用用户习惯性错误
[19]
Zalewski 的TCP 序列号预测原理来对DNS 查询报拼写、字母相似性和替换顶级域名后缀等方式来注文的事务ID 进行预测,也具有很好的攻击效果。

册与银行、知名企业的域名相类似的域名,从而达
到欺骗客户和窃取机密信息等目的。这种攻击属于非法盗取电子财产,造成的损失是巨大而持久的。 3.3.3 信息泄漏
信息泄漏通常发生在区传送过程中。区传送(zone transfer)是区数据文件装载到辅名字服务器的过程,使主、辅名字服务器之间数据同步。辅名字服务器既可以从主名字服务器装载区数据文件,也 可以从其他辅名字服务器装载。在传送过程中,内
图3 生日悖论攻击成功概率
部网络拓扑、主机名和操作系统等信息有可能会暴露,并从这些信息中判断其功能或发现其他具有漏3.3 操作脆弱性
洞的其他主机,从而使得进一步攻击成为可能[22]。 DNS 最初设计主要考虑物理设备故障,并没有代表事务ID 值的集合,这里取值为65 535,n 是
随机生成的报文数量。
考虑由于人为操作或配置错误所带来的安全隐患。由于缺乏有效的配置管理工具,使得DNS 上存在大量的配置错误(例如无用授权、循环依赖和冗余降低等) ,给整个域名空间带来极大的安全威胁[7]。针对操作脆弱性的安全威胁主要包括域名配置攻击、域名注册攻击和信息泄漏等。 3.3.1 域名配置攻击
域名配置攻击包括无意攻击和有意攻击。其中无意攻击是由于误配置造成的,例如将防火墙等报文过滤软件配置成只允许查询报文发送而不允许应答报文返回。这给DNS 空间带来极大污染,因为名字服务器持续发送查询报文而没有意识到这样的配置使其无法接收到任何应答报文[20]。有意攻击则是利用DNS 协议配置的随意性弱点来实施攻击。这种攻击方法的典型代表是对DNS 通配符(wildcard)的滥用,攻击者通常利用通配符条目来混淆其要真正攻击的目的主机,垃圾邮件也会利用这点向主机名嵌入跟踪信息来验证真实的邮件账号从而避开反垃圾邮件系统的检测。
4 改进方案
目前针对DNS 安全的研究主要集中在3个方面:DNS 协议安全性研究、DNS 配置诊断研究以及DNS 管理和维护研究。各个研究方向看待问题的角度虽然不同,但是从整体上来说都是为了增强DNS 系统的可用性、可靠性及安全性。针对上一节提到的各种DNS 安全威胁,研究者从协议安全性、系统可用性和管理维护等角度提出了许多解决方案和措施,对现有域名系统的安全性加以改进和完善。
4.1 DNS 协议安全性研究
DNS 报文的源真实性和完整性是非常重要的,即所谓的目标安全性(object security)。因此DNS 安全应该关注的是:如何保证收到的DNS 报文的可信任性和完整性;如何保证附加字段的信息是可信任的;如何保证区传送的机密性,即通道安全(channel security)。一直以来,很多学者和研究机构都在探讨DNS 安全性问题,对于DNS 协议所固有的安全缺陷,提出了一些解决方案。1997年1月,
,·96· 通 信 学 报 第28卷
IETF 域名系统安全工作组提出DNS 安全扩展协议
BIND (DNSSEC)[23]来加强DNS 基础设施的安全性。
9.x 系列版本提供对DNSSEC 的支持。DNSSEC 在兼容现有协议基础上引入公钥加密/认证体系,通过事务签名和区签名来提供端到端的数据真实性和完整性保护。主要功能包括:密钥分发;数据完整性和原始性认证;事务和请求认证。DNSSEC 的出现虽然极大改善了DNS 的安全性,但目前仍然没有得到大规模部署,主要存在以下困难:1) 系统效率问题。大量的签名和记录验证带来严重的负载,很难在实际应用中部署。2) 密钥系统的管理问题比较突出,包括密钥的分发、保存、更新以及废除等。DNSSEC 中的密钥是离线存储的,但是由于动态更新需要频繁使用密钥,使得离线的密钥存储局限性很大。而且DNSSEC 假定区的私钥不被窃取,并且负责提供真实名字服务的服务器本身是诚实可信的,这一假定违反了安全管理和域名服务器管理角色分离的原则。3) DNSSEC只提供数据原始性验证和完整性检查,没有提供机密性、控制列表和一致性检验,无法抵御重放攻击。4) 由于只提供单向认证,只对名字服务器的响应进行认证,而没有对客户的查询请求进行认证,因而不能解决缓存中毒的问题。5) DNSSEC也没有提供对DoS 的防护机制。6) DNSSEC本身给DNS 增加了额外的复杂性,也增加了新的实现错误和配置错误的机会。此外,DNSSEC 的移植花费较高,经济因素也是制约其部署的原因之一。因此DNSSEC 的大规模普及和应用任重而道远。
为解决DNSSEC 中存在的问题,很多学者进行了有益的尝试。Cachin 等人[24]通过门限加密方法来分布式存储密钥,使得密钥在线存储和签署成为可能。使用原子广播协议对名字服务器进行安全复制,克服了名字服务器的单点失效问题,具有较强的可生存性。但是其通信协议比较复杂,也没有考虑缓存的情况,并且延迟较大,很难在实际环境中应用。Ateniese 等人[25]提出用对称加密机制来管理DNSSEC 中的密钥,不仅改善了DNSSEC 的性能,而且可以提供必要的数据机密性,抵御重放攻击。此外,对称加密机制也提供互相认证,使得控制列表和一致性检验切实可行。但是对称加密要求每一对通信实体要共享一个会话密钥,导致服务器负载过重。为解决可扩展性问题,Ahmed [26]提出一种层次化的名字服务器结构,结合迭代和递归解析方
法,在一定程度上减少了根名字服务器的密钥存储负担。
缓存中毒也是DNS 协议脆弱性导致的严重威胁。从微观结构来看,必须解决单独区的单点失效问题,提供更新的及时传播;从宏观结构来看,解决整个DNS 系统的可用性问题,要保证发往端解析器的更新记录及时更换。通过关闭名字服务器的递归查询功能或单纯减少数据的TTL 值会减小缓存中毒的可能性,但却极大降低了DNS 域名解析的速度和效率,可谓因噎废食。对于这一问题,Schuba 等人[27]给出了若干解决方案,主要包括权威性验证、上下文相关性检测和限制性使用。通过权威性验证,由权威名字服务器提供的信息才会被缓存。上下文相关性检测包括内容和查询类型的相关,保证只有与查询请求相关的附加信息会被保留。限制性使用则是给缓存的信息加上一些标记,用来标注这些信息在下次解析过程中是否可以使用。Yan Gao等人[28]认为缓存中毒攻击分为存储位置干扰(locality-disruption)攻击和虚假存储位置(false-locality)攻击。根据这两种攻击的内在特征,提出了基于数据流替换算法的检测方案,不仅能检测出单独发起的攻击,还能检测出混合式攻击,并实现了反污染攻击原型系统,有效抵制了缓存中毒攻击。虽然这些方法在不同程度上降低了DNS 的性能并且增加了使用的复杂性,但却极大加强了DNS 的安全性。
由于动态更新没有完整性检查机制,因此也会带来缓存不一致等问题。Amir 等人[29]指出动态更新产生缓存不一致问题,而且更新发向单独的主服务器也会加大单点失效的概率,提出用对等服务器结构来代替主从服务器结构。区更新可以提交给任何一台服务器,然后通过Spread 组群通信机制迅速传播复制。这种对等结构减小了整个区对单一主服务器的依赖。Wilkinson 等人[30]利用SCOLD 系统关键组件的间接路由技术来抵制DNS 更新时遭受的分布式拒绝服务(DDoS)攻击,通过地理位置分散的代理服务器和预备网关在客户端和目标服务器之间建立间接路由。其代理服务器通常由参与者志愿提供或者由ISP 有偿提供,间接路由则用IP 遂道(tunnel)技术来实现。Wang 等人[31]提出基于门限加密的安全DNS 体系结构,来解决区安全密钥在线存储引发的单点失效问题和管理区分问题。认为DNS 面临内外两种攻击:外部是主名字服务器的单
,第9期 王垚等:域名系统安全研究综述 ·97·
点失效;内部是服务器管理员非授权接触私钥所造成的信息泄漏。通过引入区安全服务器和门限加密算法来构造容侵系统以解决上述问题,但是由于局限于同一局域网并且未采用具有容错能力的广播协议,该方案同样有产生单点失效的隐患。Steven Cheung [32]提出了基于形式化描述分方法来保护DNS 等关键基础设施。指出DNS 服务器应该只采用与权威源一致的数据。利用高级容错系统在安全策略违规行为检测、异常行为部件识别、系统诊断和系统重新配置等方面的特性,设计了DNS wrapper 原型系统来过滤可疑消息报文,有效抵御缓存中毒和DNS 欺骗等攻击,从而保障了DNS 系统的安全性。
在网络传输方面通常采用SSL 协议来加强安全性。由于SSL 协议在银行、电信等高等级安全应用领域广泛使用,技术成熟可靠,提供应用级的加密和认证,而且移植方便、代价小,因此在目前情况下比DNSSEC 更具竞争力。Fetzer 等人[33]提出用SSL 协议来改进目前DNS 的安全状况,增强基础设施的可信任性。通过在客户和服务器之间架设可信代理来完成认证工作,对现有的客户端和服务器完全透明。并且使用现有SSL 的CA 认证基础设施,移植代价很小。此外,由于SSL 可以单独配置,因此需要进行安全加固的实体可以独立部署而不依赖于其他实体,从而保证了配置的顺利实施。这种方案的缺点在于SSL 协议是面向连接的,建立在TCP 协议栈之上,因此不适合保护DNS 中广泛使用的UDP 通信数据。并且每个客户和服务器之间都要搭建隧道,负载较大。
Paxson 认为针对名字服务器的反射式DoS 攻击对DNS 构成严重威胁[34]。指出了针对DNS 的两种攻击策略,同时给出了两种方法来对抗攻击,一种是在受害者一方过滤对虚假请求的应答报文,另一种是限制递归名字服务器只为本地机器提供服务。Rikitake [35]提出使用T/TCP来作为DNS 的传输协议。然而作为T/TCP协议中欺骗检测关键点的TAO 测试无法有效抵制恶意攻击。此外,由于DNS 的查询和响应报文主要使用UDP 协议,而UDP 和DNS 协议本身都没有提供对请求源的认证,使得名字服务器很容易受到基于欺骗的DoS 攻击。Guo 等人利用cookie 来检测DNS 欺骗攻击[36]。每一个请求发起者都需要获得权威名字服务器分发的唯一cookie 来标识之后的所有通信。由于欺骗请求无法
给出正确的cookie 因而能够被检测出来,而且这种方案误报率很低。然而这些方法均需要修改DNS 的通信机制,并且需要额外的代理部件进行配合,不仅加重了性能负载,也增加了部署复杂性。Ballani 等人[37]的利用缓存服务器中的过期记录来减轻DoS 造成的影响。由于缓存服务器中的记录即使过期也不被删除,因此可以利用这些记录作为权威名字服务器不可用时的备份记录。可是这种方案违反了DNS 协议关于过期记录的语义,无法得到合理采纳。Pappas 等人[38]也是根据权威名字服务器资源记录变动不频繁这一特点,通过设置长时间的TTL 值来增强DNS 抵御DoS 攻击的能力。实验表明该方法能够将DNS 的可用性提高一个数量级,而且既不需要额外的物理设备,也没有改变DNS 的传统协议设计,然而该方法增加了系统遭受缓存中毒攻击的风险。其他对DoS 攻击的检测方法大多是监测DNS 流量突变异常,而没有发现网络进出流量之间表现出来的不平衡性,也没有研究流量属性特征进而从数据结构角度刻画流量行为。 4.2 DNS 配置诊断研究
配置错误通常包括两种,一种是由于实现脆弱性引起的,另一种是人为因素造成的。
Vixie [39]致力于纠正DNS 在实现方面的错误。在BIND 4.9.3之后增强了对缓存资源记录的检查,并且增加了可信性等级机制,即来源可靠的记录会被优先缓存。但是BIND 的漏洞层出不穷,涵盖各个版本,排在UNIX 及Linux 操作系统相关安全隐患的首位[5]。鉴于此,Bernstein 开发了djbdns [40]来取代BIND 。djbdns 改正了BIND 实现上的很多错误,如非FIFO 缓存数据结构、缓冲区溢出和无法处理未识别记录类型等,每一个查询报文的源端口号也是随机产生,极大提高了DNS 系统的鲁棒性。
许多DNS 管理员缺乏DNS 系统的理论知识和实际经验。由于缺乏系统的文档和自动配置管理工具,人为错误配置导致了很多攻击和故障,如无用授权和冗余降低,因此对配置错误检测工具的需求尤为迫切。目前有几种DNS 配置错误检测工具[41~45],但是它们只能检测DNS 系统中的错误子集,例如识别资源记录错误等具体问题,而且这些检测工具只有一个探测点,无法识别出需要分布检测才能发现的错误。为了解决这个问题,Pappas 等人[46]将DNS 配置赋予两种属性:连续性和独立性,认为配置错误就是对这两种属性的破坏。他们
,·98· 通 信 学 报 第28卷
利用多个探测点对DNS 的配置错误进行检测,并提供了可视化检测工具。清华大学韩殿飞等人[47]对中国域名服务器的几类配置错误进行了测量与分析,发现这些问题同样广泛存在,实验结果表明.cn 域中30以上的区都存在配置问题,对中国互联网的性能和鲁棒性构成了较大威胁。此外,dnsproxy [48]和dnstop [49]也可以很有效地检测配置错误。dnsproxy 运行于防火墙或防火墙内的可信主机上。它将域名空间分割为若干领域(Realm),每个领域由若干名字服务器来提供服务。根据查询的域名,dnsproxy 会将请求分配到相应的领域来查询,对结果进行一致性检验和过滤并记录潜在攻击和错误配置的日志。dnstop 则采用BPF 接口对DNS 查询报文进行分析统计,可以有效地检测伪造的A 类型查询、重复查询和无效TLD 查询等错误报文。台湾交通大学陈昌盛等人[50]利用本体论来描述DNS 系统,设计了基于本体论和知识系统的DNS 配置检测和管理工具iDNS-MS [51],包括DNS 配置和维护、DNS 调试、DNS 流量异常监测、DNS 注册和DNS 教学等子系统,从而有效降低了系统管理员的工作负担。
4.3 DNS 管理和维护研究
作为大规模分布式系统,DNS 的可管理性(manageability)、可控性(controllability)和可维护(maintainability)是十分重要的。除了对DNS 协议安全性的研究之外,很多文章在现有基础上提出了一些安全建议,主要是及时升级服务器软件、严格配置DNS 系统等被动消极的防御手段[52],对于DNS 欺骗等一些难以避免的攻击则缺乏必要的检测方法和防范措施。
使用分离式DNS(split DNS)[53]是比较常见的管理方式。利用视图将域名空间分割为内部域和外部域,从而避免由于双向DNS 数据不加限制地穿过防火墙所带来的安全隐患。内部域的客户可以使用私有地址和递归查询内部域名,无法解析的查询通过转发交由外部域的名字服务器处理。外部域只包含对外公开的区数据,使得在互联网上的暴露最小化。这种方案缺点是配置不当可能会使内部私有地址泄漏从而给互联网名字空间造成污染[20]。
另一种方法是依赖SNMP 的MIB(management information base,管理信息库) 来对DNS 进行管理。将各种不同的DNS 功能划分为两个非重叠类:解析器功能和名字服务器功能,用相应的实体来表示
解析器和名字服务器,并根据DNS 规范、配置文件和现有的DNS 管理工具的使用经验创建相应的对象进行协议描述。但是它主要是对DNS 流量进行审计,很难识别DNS 的配置错误。
在目前的DNS 系统中,域名拥有者既要提供域名解析服务,又要维护自己的名字服务器,使得服务和管理耦合在一起,不但加大了管理难度,而且由于管理者专业水平参差不齐,极大增加了服务器被攻击的风险。因此,研究者通过改变DNS 层次式管理架构(hierarchy structure)来解决这一固有问题,多是利用P2P 网络特有的扁平结构(flat structure) 进行替代,主要的方案包括DDNS [54]和CoDoNS [55]。
DDNS 采用基于Chord [56]的P2P 分布式哈希表(DHT, distributed hash table)来提供名字解析服务,继承了Chord 的容错能力和负载均衡特性,同时也消除了目前DNS 系统中存在的管理问题。把资源记录整合为RRSet ,由所有者签名后插入DHash 中,客户端使用时同样要验证签名。然而DDNS 中存在DoS 的可能,即Chord 网络空间被域名所有者插入大量记录而耗光。此外分布式哈希表不足以服务于DNS ,因为很多功能需要在客户端实现,一旦更改,则需要所有客户端进行更新。CoDoNS 系统则保留了传统DNS 设计中的成功之处,如层次化结构的独立管理和通用的数据库接口,并与目前的DNS 系统完全兼容,可以实现平滑过渡。CoDoNS 由遍布全球的节点构成P2P 自组织覆盖网络(overlay),通过家节点(home node)保存域名记录,并在邻居节点上缓存。如果家节点失效,则最相邻的邻居节点会取而代之成为新的家节点。利用P2P 网络自组织性和自适应性的优势,CoDoNS 可以很好地抵御DoS 攻击,动态地进行负载均衡,从而有效避免了单点失效问题。此外,CoDoNS 中的名字记录通过自我验证可以有效地防止被篡改,并且通过加密授权使得每个具有有效名字记录的节点可以为其他节点提供权威的名字记录,从而打破了名字空间管理员对资源的垄断,实现了域名空间管理与域名解析的有效分离。但是由于缺乏必要的激励机制,P2P 网络中搭便车(free riding)的现象普遍存在,成为制约这类方案实施的瓶颈。清华大学李丹等人[57]对互联网名字空间结构及解析服务进行了深入研究,分析了当前的互联网名字空间结构及其解析服务存在的问题,并对目前的各种互联网名字空间改进方
,第9期 王垚等:域名系统安全研究综述 ·99·
案进行了分类、综述与比较,指出目前的DNS 系统存在着记录更新速度慢、服务模式单一、资源描述能力不够强、配置易出错等缺点, 分析并比较了许多对DNS 进行补充和改进的方案, 包括URN [58]、INS [59]和CoDoNS 。
4.4 DNS 安全技术研究谱系
通过对DNS 安全技术发展历程的分析,可以形成DNS 安全技术研究谱系图,如图4所示。按照协议安全性、配置诊断、管理和维护将DNS 安全技术研究分为3大类,其中白色方框表示安全技术所属类别,深色方框为具体安全技术,从图中可以更加直观地了解具体安全技术的发展历程,为今后DNS 安全技术研究和发展指明方向。
5 未来研究工作展望
作为大规模分布式网络,DNS 可以抽象为一个有向图。名字服务器和解析器构成图的节点,而名字服务器和解析器之间的路由则构成了有向图的边。因此,加强DNS 的安全性就是要加强这些节点和边的安全性。节点的安全主要通过安全评估来保证,包括安全漏洞扫描和权威名字服务器可用性测量;边的安全性则体现在关键路由发现和保护上。此外,DNSSEC 有效配置与平滑过渡、DNS 配置错误检测以及对DNS 攻击的检测和防御等问题也是未来研究的热点问题。 5.1 DNS 系统安全评估
DNS 安全评估主要是根据“木桶原理”对DNS
系统安全方面进行测评,发现DNS 系统中存在的薄弱环节。另外要对特定DNS 系统请求进行监测,统计其中无效DNS 请求,分析其对DNS 系统的影响。具体评估方法包括安全漏洞扫描和权威名字服务器分布探测。
DNS 服务器是DNS 系统中最为重要的环节,BIND 是目前互联网上广泛使用的DNS 服务器软件,其最新版本为9.4.0,新版本修正了很多已知的DNS 漏洞。但是之前的版本在网络上仍然大量存在,在不同程度上存在着脆弱性,容易受到缓存中毒及域名欺骗攻击。而安全漏洞扫描是通过发探测报文的方法来搜集目标DNS 服务器相关信息以及存在的安全隐患,形成相应的漏洞评估报告,协助和指导相关管理人员更新升级软件版本,消除安全隐患。
此外,DNS 名字服务器使用冗余机制来提高服务的稳定性和健壮性。重要的组织机构都配有多台名字服务器提供服务,通常由一台主名字服务器和多台辅名字服务器组成。一旦主名字服务器出现故障,则由辅名字服务器接管,从而保证服务不被中断。然而目前很多机构将全部名字服务器部署在同一子网内,一旦其所处网络出现故障,将导致整个服务瘫痪。名字服务器分布探测就是探测目标域名的权威名字服务器的真实情况,包括服务器个数、IP 地址和部署地点等信息,并以此来判断其是否存在单点失效的风险。这种探测需要支持多点探测来保证测量的准确性[60]。

图4 DNS安全技术研究谱系图
,·100· 通 信 学 报 第28卷
5.2 DNS 系统关键路由发现和保护
DNS 名字服务器用来对外提供域名解析服务。如何对名字服务器进行管理,确保其高效有序的使用和运转是目前面临的重要问题。对名字服务器进行有效管理,就必然要对服务器工作状况进行调查和分析,弄清网络中的报文究竟源自哪里,要访问的是哪些网站的信息,各类网站被访问的频率如何以及所访问的名字服务器分布情况。其服务对象可能遍布全球各地,因此从不同的客户端到达服务器的路由也就千差万别。但是一般情况下,绝大部分路由都会在最后几跳汇接到一段比较固定的路由上,特别对根和顶级域名服务器更是如此。这段固定的路由称为关键路由。这些关键路由是通往DNS 服务器的必经之路,一旦出现问题,将导致与之相连的服务器全面失效,因此要对这些关键路由实施特殊的保护。
保护关键路由的首要问题是如何发现它们。关键路由发现需要对目标名字服务器进行分布式路由探测,然后将探测结果进行分析和综合,最终找到大部分路由的汇接点。探测结果的准确性依赖于测试机的分布情况,测试机分布越广泛,探测结果就越准确。通过对DNS 系统的关键路由进行发现和保护,能够有效分析造成网络时延的成因并定位故障点,极大改善整个Internet 的性能和DNS 的服务质量(QoS),并对互联网基础设施的规划建设和安全防护起到很好的指导作用。 5.3 DNS 异常检测和安全防护
异常检测是网络安全保障措施的重要组成部分,有利于及时发现网络异常行为,快速检测和定位网络故障和性能问题所在,指导网络管理者采取措施加以解决从而避免或减轻故障和攻击造成的影响,对保障网络服务质量、提高网络的可用性及维护网络的可靠性具有重要意义。现实网络中存在两种异常行为,一种是由恶意攻击引起的,一种是系统在软件设计、编码和系统配置过程中的脆弱性所导致的。可以通过基于流量 (volume)和报文载荷(payload)特征的方法进行检测。DNS 系统采用层次化体系结构,由作为客户端的解析器、本地名字服务器和全局名字服务器构成,因此其业务量模型为层级式客户/服务器业务量模型,其中的业务量具有层次性,底层名字服务器完成中继功能,既可能是数据源也可能是数据宿。同时,传统的客户/服务器业务量模型具有不对称性,即服务器到客户端的流
量较大,而在DNS 协议中查询和响应报文尺寸相差不大,并没有明显的流量差异,因此基于流量统计的传统检测方法并不适用于大规模网络环境下DNS 异常的检测和识别。此外,目前通用的异常检测方法多为流量异常(volume anomaly)检测,对没有明显攻击特征的名字服务器端口扫描等攻击束手无策。 针对DNS 名字服务器的端口扫描攻击具有很强的隐蔽性,不像DDoS 攻击那样产生额外的流量,并且攻击报文和正常报文在结构上差异很小,但是端口扫描攻击在结构上会表现出业务量异常(traffic anomaly),因此,针对DNS 端口扫描等隐蔽性攻击开展专门的检测技术研究非常必要。
安全防护技术是保证网络信息系统保密性、完整性、可用性、可控性和不可否认性的综合技术。随着网络规模极速增长,安全等级不断提升,安全防护技术得到长足发展,目前以可生存性增强、容错和容侵等技术为核心的第三代安全技术逐渐成为研究热点。与此同时,域名系统的角色重要性和安全欠缺性矛盾日益严重,绝大部分的名字服务器依然暴露在各种威胁之中,严重威胁互联网的整体安全性。目前对网络攻击和破坏行为的对抗效果并不理想,大多只能抵御已知攻击,缺少对域名系统故障和人为操作失误等因素的处理,在体系结构上多是外在附加的被动防御,未能解决脆弱性的本源问题,无法应对具有随机多变和和传播隐蔽等特点的攻击和破坏行为。因此,如何将安全防护技术系统应用到DNS 这一关键基础设施成为互联网安全领域亟待解决的研究课题。 5.4 DNS 攻击反向追踪
反向追踪技术用来追踪和定位攻击者所在的位置,能够找到攻击数据的源头,对于尽快恢复正常的网络功能、阻止攻击再次发生以及最终让攻击者受到应有惩罚来说至关重要。网络犯罪之所以如此猖獗,在很大程度上是由于网络的开放性使得对攻击者的追踪和惩罚难以实施,无法形成强大的网络威慑力,致使攻击者肆无忌惮地进行破坏。反向追踪技术可以从源头上消除攻击并最终形成网络威慑力。到目前为止已经出现了很多反向追踪技术,如链路测试(link testing)、报文记录(logging)、ICMP 追踪(ICMP traceback)和报文标记 (packet marking) 等。这些追踪机制优缺点并存,没有一种解决方案可以实现有效追踪方法规定的全部需求。这些追踪方案需要在大部分互联网基础设施中的