1 DNSSEC的背景和目的
域名系统(Domain Name System,DNS)是一些“Too simple, Too Naive”的互联网先驱者设计的,它象互联网的其他协议或系统一样,在一个可信的、纯净的环境里运行得很好。但是今天的互联网环境异常复杂,充斥着各种 欺诈、攻击,DNS协议的脆弱性也就浮出水面。对DNS的攻击可能导致互联网大面积的瘫痪,这种事件在国内外都屡见不鲜。
尽管DNS的安全问题一直被互联网研究和工程领域广为关注,但是有一种普遍存在的攻击却始终没有解决,即DNS的欺骗和缓存污染问题。DNS安全扩 展(DNS Security Extension, 即DNSSEC)主要是为了解决这一问题而提出的(尽管它还有其他用途)。因此,在介绍DNSSEC的原理之前有必要简单介绍DNS欺骗和缓存污染攻击的 原理。
1.1 DNS欺骗攻击和缓存污染
用户在用域名(www.example.com)访问某一个网站时,用户的计算机一般会通过一个域名解析服务器(Resolver Server,也称递归服务器(Recursive Server))把域名转换成IP地址。解析服务器一般需要通过查询根域名服务器(root)、顶级域名服务器(TLD)、 权威域名服务器(Authoritative Name Server),通过递归查询的方式最终获得目标服务器的IP地址,然后交给用户的计算机。在此过程中,攻击者都可以假冒应答方(根、顶级域、权威域、或 解析服务器)给请求方发送一个伪造的响应,其中包含一个错误的IP地址。发送请求的用户计算机或者解析服务器很傻、很天真地接受了伪造的应答,导致用户无 法访问正常网站,甚至可以把重定向到一个伪造的网站上去。由于正常的DNS解析使用UDP协议而不是TCP协议,伪造DNS的响应报文比较容易;如果攻击 者可以监听上述过程中的任何一个通信链路,这种攻击就易如反掌。
更加糟糕的是,由于DNS缓存(Cache)的作用,这种错误的记录可以存在相当一段时间(比如几个小时甚至几天),所有使用该域名解析服务器的用户都无法访问真正的服务器。攻击者可能是黑客、网络管理者等等(比如利用用户的拼写错误,把对不存在域名NXDOMAIN的访问重定向到一个广告页面),但本文不去讨论这些攻击者的身份和动机。
1.2 DNSSEC的目标、历史和意义
上述攻击能够成功的原因是DNS 解析的请求者无法验证它所收到的应答信息的真实性,而DNSSEC给解析服务器提供了防止上当受骗的武器,即一种可以验证应答信息真实性和完整性的机制。 利用密码技术,域名解析服务器可以验证它所收到的应答(包括域名不存在的应答)是否来自于真实的服务器,或者是否在传输过程中被篡改过。
尽管从原理上来说DNSSEC并不复杂,但是从1997年第一个有关DNSSEC的标准RFC 2065 [2] 发布至今已经十多年了,直到最近一两年才有了可观的进展。1999年IETF对DNSSEC标准进行了修订RFC 2535[3],但很快被证明这次修订是失败的。直到2005年,一个可用的DNSSEC标准才制定出来(RFC 4033-4035)[4][5][6],目前主流域名服务软件(如BIND )实现的也是这一版本。2008年,IETF又发布了一个NSEC3(RFC5155)[7]标准,以提高DNSSEC隐私保护能力。 随着DNSSEC的推广,也许还会有一些新的问题和新的修订,DNSSEC标准仍在发展过程中。
尽管DNSSEC的目标仅限于此(即不保护DNS信息的保密性和服务的可用性),但是,DNSSEC的成功布署对互联网的安全还有其他好处,比如提高电子邮件系统的安全性,甚至把DNS作为一个公钥基础设施(PKI)。
本文所介绍的DNSSEC工作原理基于RFC 4033-4035,关于DNS工作原理、配置和数字签名技术超出了本文的范围,感兴趣的读者可以参考[8]。在此基础上简单介绍最常用的域名服务系统 (BIND)的基本配置过程,最后DNSSEC在国际上的布署情况以及可能给网络安全带来的影响。
2 DNSSEC原理
简单的说,DNSSEC依靠数字签名保证DNS应答报文的真实性和完整性。权威域名服务器用自己的私有密钥对资源记录(Resource Record, RR)进行签名,解析服务器用权威服务器的公开密钥对收到的应答信息进行验证。如果验证失败,表明这一报文可能是假冒的,或者在传输过程、缓存过程中被篡 改了。 RFC 4033概要介绍了DNSSEC所提供的安全功能并详细介绍了相关的概念,下面通过一个简化的实例介绍DNSSEC的工作原理 。
如图2所示,一个支持DNSSEC的解析服务器(RFC4033中Security-Aware Resolver)向支持DNSSEC的权威域名服务器(Security-Aware Name Server)请求域名www.test.net.时,它除了得到一个标准的A记录(包含IPv4地址)以外,还收到一个同名的RRSIG记录,其中包含 test.net这个权威域的数字签名,它是用test.net.的私有密钥来签名的。为了验证这一签名的正确性,解析服务器可以再次向test.net 的域名服务器查询响应的公开密钥,即名为test.net的DNSKEY类型的资源记录。然后解析服务器就可以用其中的公钥验证上述 www.test.net. 记录的真实性与完整性。
图2 DNSSEC基本工作原理
但是,解析服务器如何保证它所获得的test.net.返回的公开密钥(DNSKEY记录)是真实的而不是假冒的呢? 尽管test.net.在返回DNSKEY记录的同时,也返回对这个公钥的数字签名(名为test.net的RRSIG记录);但是,攻击者同样可以同时 伪造公开密钥和数字签名两个记录而不被解析者发现。
象基于X509的PKI体系一样,DNSSEC也需要一个信任链,必须有一个或多个开始就信任的公钥(或公钥的散列值),在RFC 4033中称这些初始信任的公开密钥或散列值为“信任锚(Trust anchors)”。信任链中的上一个节点为下一个节点的公钥散列值进行数字签名,从而保证信任链中的每一个公钥都是真实的。理想的情况下(DNSSEC 全部布署),每个解析服务器只需要保留根域名服务器的DNSKEY就可以了。
在上面的例子中,假设解析服务器开始并不信任test.net.的公开密钥, 它可以到test.net.的上一级域名服务器net.那里查询test.net.的DS(Delegation Signer, 即DS RR)记录,DS RR中存储的是test.net. 公钥的散列值(比如用SHA-1算法计算得到的160比特数据的16进制表示)。假设解析服务器由管理员手工配置了.net的公钥(即Trust Anchor),它就可以验证test.net.公钥(DNSKEY)的正确与否了。
摘自:http://blog.chinaunix.net/uid-7210505-id-3344641.html