DNSSEC 原理、配置与布署简介( 二 ) _签名

尽管的目标仅限于此（即不保护DNS信息的保密性和服务的可用性），但是，的成功布署对互联网的安全还有其他好处，比如提高电子邮件系统的安全性，甚至把DNS作为一个公钥基础设施（PKI）。
本文所介绍的工作原理基于RFC 4033-4035 ，关于DNS工作原理、配置和数字签名技术超出了本文的范围，感兴趣的读者可以参考[8] 。在此基础上简单介绍最常用的域名服务系统（BIND）的基本配置过程，最后在国际上的布署情况以及可能给网络安全带来的影响。
2 原理
简单的说，依靠数字签名保证DNS应答报文的真实性和完整性。权威域名服务器用自己的私有密钥对资源记录（ , RR）进行签名，解析服务器用权威服务器的公开密钥对收到的应答信息进行验证。如果验证失败，表明这一报文可能是假冒的，或者在传输过程、缓存过程中被篡改了。RFC 4033概要介绍了所提供的安全功能并详细介绍了相关的概念，下面通过一个简化的实例介绍的工作原理。
如图2所示，一个支持的解析服务器（中-Aware ）向支持的权威域名服务器（-Aware Name ）请求域名时，它除了得到一个标准的A记录（包含IPv4地址）以外，还收到一个同名的RRSIG记录，其中包含这个权威域的数字签名，它是用.的私有密钥来签名的。为了验证这一签名的正确性，解析服务器可以再次向的域名服务器查询响应的公开密钥，即名为的类型的资源记录。然后解析服务器就可以用其中的公钥验证上述记录的真实性与完整性。
图2 基本工作原理
但是，解析服务器如何保证它所获得的.返回的公开密钥（记录）是真实的而不是假冒的呢？尽管.在返回记录的同时，也返回对这个公钥的数字签名（名为的RRSIG记录）；但是，攻击者同样可以同时伪造公开密钥和数字签名两个记录而不被解析者发现。
象基于X509的PKI体系一样，也需要一个信任链，必须有一个或多个开始就信任的公钥（或公钥的散列值），在RFC 4033中称这些初始信任的公开密钥或散列值为“信任锚（Trust ）” 。信任链中的上一个节点为下一个节点的公钥散列值进行数字签名，从而保证信任链中的每一个公钥都是真实的。理想的情况下（全部布署），每个解析服务器只需要保留根域名服务器的就可以了。
在上面的例子中，假设解析服务器开始并不信任.的公开密钥，它可以到.的上一级域名服务器net.那里查询.的DS（，即DS RR）记录， DS RR中存储的是. 公钥的散列值（比如用SHA-1算法计算得到的160比特数据的16进制表示）。假设解析服务器由管理员手工配置了.net的公钥（即Trust ），它就可以验证.公钥（）的正确与否了。
2.1 的资源记录
为了实现资源记录的签名和验证，增加了四种类型的资源记录： RRSIG（）、(DNSKey)、DS( )、NSEC(Next ) 。前三种记录已经在上面的实例中提到了， NSEC记录是为响应某个资源记录不存在而设计的。具体的说明参见RFC 4034 ，本文概要介绍如下。
2.1.1 记录
资源记录存储的是公开密钥，下面是一个的资源记录的例子：
. 86400 IN256 3 5 ( ….. == )
其中256是标志（flag）字段，它是一个16比特的数，如果第7位（左起为第0位。这一位是区密钥（Zone Key）标志, 记为ZK）为1 ，则表明它是一个区密钥，该密钥可以用于签名数据的验证，而且资源记录的所有者（.）必须是区的名字。第15位称为安全入口点（ Entry Point ， SEP）标志，将在下面介绍。