DNSSEC原理

　　简单的说，DNSSEC依靠数字签名保证DNS应答报文的真实性和完整性。权威域名服务器用自己的私有密钥对资源记录(Resource Record, RR)进行签名，解析服务器用权威服务器的公开密钥对收到的应答信息进行验证。如果验证失败，表明这一报文可能是假冒的，或者在传输过程、缓存过程中被篡改了。 RFC 4033概要介绍了DNSSEC所提供的安全功能并详细介绍了相关的概念，下面通过一个简化的实例介绍DNSSEC的工作原理 。

图2 DNSSEC基本工作原理

　　如图2所示，一个支持DNSSEC的解析服务器(RFC4033 中Securi ty-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也需要一个信任链，必须有一个或多个开始就信任的公钥(或公钥的散列值)，在RFC4033中称这些初始信任的公开密钥或散列值为“信任锚(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)的正确与否了。