文/段海新

DNSSEC原理、配置与部署

文/段海新

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

DNSSEC的背景和目的

域名系统（Domain Name System，DNS）是一些“太单纯、太幼稚”的互联网先驱者设计的，它像互联网的其他协议或系统一样，在一个可信的、纯净的环境里可以运行得很好。但是今天的互联网环境异常复杂，充斥着各种欺诈、攻击，DNS协议的脆弱性也就浮出水面。对DNS的攻击可能导致互联网大面积的瘫痪，这种事件在国内外都屡见不鲜。

DNS作为互联网最重要的基础设施之一，它的安全问题一直被互联网研究和工程领域广为关注，但是有一种普遍存在的攻击却始终没有解决，即DNS的欺骗和缓存污染问题。DNS安全扩展（DNS Security Extension, 即DNSSEC）主要是为了解决这一问题而提出的。因此，在介绍DNSSEC的原理之前有必要简单介绍DNS欺骗和缓存污染攻击的原理。

DNS欺骗攻击和缓存污染

用户在用域名访问某一个网站时，用户的计算机一般会通过一个域名解析服务器（Resolver Server，也称递归服务器（Recursive Server））把域名转换成IP地址。解析服务器一般需要查询根域名服务器（root）、顶级域名服务器（TLD）、 权威域名服务器（Authoritative Server），通过递归查询的方式最终获得目标服务器的IP地址，然后交给用户的计算机（如图1所示）。

在上述任何一个请求／应答的过程中，攻击者都可以假冒应答方（根、顶级域、权威域或解析服务器）给请求方发送一个伪造的响应，其中包含一个错误的IP地址。发送请求的用户计算机或者解析服务器很天真地接受了伪造的应答，导致用户无法访问正常网站，甚至可以把IP重定向到一个伪造的网站上去。由于正常的DNS解析使用UDP协议而不是TCP协议，伪造DNS的响应报文比较容易。如果攻击者可以监听上述过程中的任何一个通信链路，这种攻击就易如反掌。

更加糟糕的是，由于DNS缓存（Cache）的作用，这种错误的记录可以存在相当一段时间（比如几个小时甚至几天），期间所有使用该域名解析服务器的用户都无法访问真正的服务器。

DNSSEC的目标、历史和意义

上述攻击能够成功的原因是DNS 解析的请求者无法验证它所收到应答信息的真实性。DNSSEC给解析服务器提供了防止受骗的武器，即一种可以验证应答信息真实性和完整性的机制。利用密码技术，域名解析服务器可以验证它所收到的应答（包括域名不存在的应答）是否来自于真实的服务器，或者是否在传输过程中被篡改过。

尽管从原理上来说DNSSEC并不复杂，但是从1997年第一个有关DNSSEC的标准RFC 2065发布至今已经十多年了，直到最近一两年才有了一定的进展。1999年IETF对DNSSEC标准进行了修订，并推出RFC 2535，但这次修订很快被证明是失败的。直到2005年，一个可用的DNSSEC标准才制定出来RFC 4033-4035，目前主流域名服务软件（如BIND ）实现的也是这一版本。2008年，IETF又发布了一个NSEC3 RFC5155标准，以提高DNSSEC隐私保护能力。 随着DNSSEC的推广，也许还会有一些新的问题和新的修订，DNSSEC标准仍在发展过程中。

尽管DNSSEC的目标仅限于此（即不保护DNS信息的保密性和服务的可用性），但是DNSSEC的成功部署对互联网的安全还有其他好处，比如提高电子邮件系统的安全性，甚至可以把DNS作为一个公钥基础设施（PKI）。

本文所介绍的DNSSEC工作原理基于RFC 4033-4035，关于DNS工作原理、配置和数字签名技术超出了本文的范围，感兴趣的读者可以参考。

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记录（IP地址）以外，还收到一个同名的RRSIG记录，其中包含test.net这个授权域的数字签名，它是用test.net.的私有密钥来签名的。为了验证这一签名的正确性，解析服务器可以再次向test.net的域名服务器查询响应的公开密钥，即DNSKEY资源记录。然后解析服务器就可以用其中的公钥验证上述记录的真实性与完整性。

解析服务器如何保证它所获得的test.net.返回的公开密钥（DNSKEY记录）是真实的而不是假冒的呢？尽管test.net.在返回公开密钥记录的同时，也返回对这个公钥的数字签名，但是，攻击者同样可以同时伪造公开密钥和数字签名两个记录而不被解析者发现。

与基于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. 公钥的散列值（比如用MD5算法计算得到的128比特数据，再用base64编码得到的一个字符串）。假设解析服务器由管理员手工配置了.net的公钥（即Trust Anchor），它就可以验证test.net.公钥（DNSKEY）的正确与否了。

DNSSEC的资源记录

为了实现资源记录的签名和验证，D N S S E C增加了四种类型的资源记录：RRSIG（Resource Record Signature）、DNSKEY(DNS Public Key)、DS(Delegation Signer)、NSEC(Next Secure)。前三种记录已经在上面的实例中提到了，NSEC记录是为响应某个资源记录不存在而设计的。具体的说明参见RFC 4034，本文概要介绍如下。

DNSKEY记录

DNSKEY资源记录存储的是公开密钥，下面是一个DNSKEY的资源记录的例子：

其中256是标志字段（flag），它是一个16比特的数，如果第7位（左起为第0位。这一位是区密钥（Zone Key）标志, 记为ZK）为1，则表明它是一个区密钥，该密钥可以用于签名数据的验证，而且资源记录的所有者（example.com.）必须是区的名字。第十五称为安全入口点（Security Entry Point，SEP）标志，将在下面介绍。

下一个字段“3”是协议（protocol）字段，它的值必须是3，表示这是一个DNSKEY，这是为了与以前版本DNSSEC兼容而保留下来的。其他的值不能用于DNSSEC签名的验证。

下一个字段“5”是算法（Algorithm）字段，标识签名所使用的算法的种类。其中常用的几种：1：RSA/MD5; 3：DSA/SHA-1; 5 RSA/SHA-1。

最后括号中的是公开密钥（Public Key）字段，它的格式依赖于算法字段。

在实践中，权威域的管理员通常用两个密钥配合完成对区数据的签名。一个是Zone-Signing Key(ZSK)，另一个是Key-Signing Key(KSK)。ZSK用于签名区数据，而KSK用于对ZSK进行签名。这样做的好处有二：

（1）KSK的密钥签名的数据量很少，被破解（即找出对应的私钥）概率很小，因此可以设置很长的生存期。这个密钥的散列值作为DS记录存储在上一级域名服务器中而且需要它的数字签名，较长的生命周期可以减少密钥更新的工作量。

（2）ZSK签名的数据量比较大，因而破解的概率较大，其生存期应该小一些。因为有了KSK的存在，ZSK可以不必放到上一级的域名服务中，减少了管理的开销。

RRSIG记录

为保证模拟结果的可靠性，对光滑管从0.5～2.0m/s的入口流速进行模拟，由于研究流体为无相变流体在光滑管管内作强制流动，可将模拟得到的摩擦系数fA与Blasius公式计算理论值对比[9]，从而判定模拟结果的可靠性。结果如表2所示。

RRSIG资源记录存储的是对资源记录集合（RRSets）的数字签名。下面是对一个A记录签名后得到的RRSIG记录：

从第五个字段（“A”）开始各字段的含义如下：

类型覆盖（The Type Covered Field）：表示这个签名覆盖什么类型的资源记录，本例中是A。

算法：数字签名算法，同DNSKEY记录的算法字段；本例中5表示RSA/SHA-1。

标签数量（The Labels Field）：被签名的资源域名记录所有者（host.example.com.）中的标签数量，如本例中为3，*.example.com.为2，“.”的标签数量为0。

接下来的几个字段分别是被签名记录的TTL、有效期结束时间、开始时间。

2642是密钥标签（Key Tag），它是用对应公钥数据简单叠加得到的一个16比特整数。如果一个域有多个密钥时（如一个KSK、一个ZSK），Key Tag可以和后面的签名者字段（example.com.）共同确定究竟使用哪个公钥来验证签名。

DS（Delegation Signer）记录存储DNSKEY的散列值，用于验证DNSKEY的真实性，从而建立一个信任链。不过，与DNSKEY存储在资源记录所有者所在的权威域的区文件中不同，DS记录存储在上级域名服务器（Delegation）中，比如example.com的DS RR存储在.com的区中。

下面是一个DS记录的实例：

DS 之后的字段依次是密钥标签（Key Tag）、算法和散列算法（1代表 SHA-1）。后面括号内的内容是dskey.example.com.密钥SHA-1计算结果的16进制表示。Example.com必须为这个记录数字签名，以证实这个DNSKEY的真实性。

NSEC记录

NSEC记录是为了应答那些不存在的资源记录而设计的。为了保证私有密钥的安全性和服务器的性能，所有的签名记录都是事先（甚至离线）生成的。服务器显然不能为所有不存在的记录事先生成一个公共的“不存在”的签名记录，因为这一记录可以被重放（Replay）；更不可能为每一个不存在的记录生成独立的签名，因为它不知道用户将会请求怎样的记录。

在区数据签名时，NSEC记录会自动生成。比如在vpn.test.net和xyz.test.net之间会插入下面的这样两条记录：

其中NSEC记录包括两项内容：排序后的下一个资源记录的名称（xyz.test.net.）以及vpn.test.net.这一名称所有的资源记录类型（A、RRSIG、NSEC），后面的RRSIG记录是对这个NSEC记录的数字签名。

在用户请求的某个域名在vpn和xyz之间时，如www.test.net.，服务器会返回域名不存在，并同时包括 vpn.test.net的NSEC记录。

DNSSEC对现有DNS协议的修改

由于新增DNS资源记录的尺寸问题，支持D N S S E C的域名服务器必须支持EDNS0（RFC2671），即允许DNS报文大小必须达到1220字节（而不是最初的512字节），甚至可以是4096字节。

DNSSEC在报文头中增加了三个标志位：

（1）DO（DNSSEC OK, 参见RFC3225）：支持DNSSEC的解析服务器在它的DNS查询报文中，必须把DO标志位置1，否则权威域服务器认为解析器不支持DNSSEC就不会返回RRSIG等记录。

（2）AD （Authentic Data）：AD是认证数据标志，如果服务器验证了DNSSEC相关的数字签名，则置AD位为1，否则为0。这一标志位一般用于自己不做验证的解析器（non-validating security-aware resolvers）和它所信任的递归解析服务器（securityaware recursive name server）之间，用户计算机上的解析器自己不去验证数字签名，递归服务器给它一个AD标志为1的响应，它就接受验证结果。这种场景只有在它们之间的通信链路比较安全的情况下才安全，比如使用了IPSEC和TSIG。

（3）CD （Checking Disabled）： 关闭检查标志位用于支持DNSSEC验证功能的解析器（validating security-aware resolver）和递归域名服务器之间，解析器在发送请求时把CD位置1，服务器就不再进行数字签名的验证而把递归查询得到的结果直接交给解析器，由解析器自己验证签名的合法性。

最后，支持验证的DNSSEC 解析器对它所收到的资源记录的签名（RRSIG），必须能够区分以下四种结果：

（1）安全的（secure）：解析器能够建立到达资源记录签名者的信任链，并且可以验证数字签名的结果是正确的。

（2）不安全的（insecure）：解析器收到了一个资源记录和它的签名，但是它没有到达签名者的信任链，因而无法验证。

（3）伪造的（Bogus）：解析器有一个到资源记录签名者的信任链，但是签名验证是错的。可能是因为受到攻击了，也可能是管理员配置错误。

（4）不确定（Indeterminate）：解析器无法获得足够的DNSSEC 资源记录，因而不能确定用户所请求的资源记录是否应该签名。（待续）

(作者单位为清华大学信息网络工程研究中心)