[计算机网络]：DNSSEC原理( 二 ) _dns

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）标志，将在下面介绍。
下一个字段“3”是协议（）字段，它的值必须是3，表示这是一个，这是为了与以前版本兼容而保留下来的。其他的值不能用于签名的验证。
下一个字段“5”是算法（）字段，标识签名所使用的算法的种类。其中常用的几种：1：RSA/MD5; 3：DSA/SHA-1; 5 RSA/SHA-1;
最后括号中的是公开密钥（ Key）字段，它的格式依赖于算法字段。
在实践中，权威域的管理员通常用两个密钥配合完成对区数据的签名。一个是Zone- Key(ZSK)，另一个是Key- Key(KSK) 。ZSK用于签名区数据，而KSK用于对ZSK进行签名。这样做的好处有二：
（1）用KSK密钥签名的数据量很少，被破解（即找出对应的私钥）概率很小，因此可以设置很长的生存期。这个密钥的散列值作为DS记录存储在上一级域名服务器中而且需要上级的数字签名，较长的生命周期可以减少密钥更新的工作量。