计算机网络 DNSSEC原理

               

DNSSEC 原理、配置与布署简介

Posted on  May 16, 2011  by  Duan Haixin

作者：段海新，清华大学信息网络工程研究中心

摘要：DNSSEC是为解决DNS欺骗和缓存污染而设计的一种安全机制。本文概要介绍DNSSEC的背景、工作原理、在BIND上的配置，最后介绍国际上的布署情况和它可能对互联网安全体系的影响。

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类型的资源记录。然后解析服务器就可以用其中的公钥验证上