技术摘要| 论 DNSSEC 系统的信任锚点和旁路验证扩展 (DLV)

域名树和 DNS 递归查询

DNS 作为一个非常重要的互联网基础设施，已经陪伴我们走过了数十个春夏秋冬。DNS 系统的最基础的功能，便是将一个人类可读的域名，转化为一个机器可读的 IP 地址。然后安全性并不在 DNS 系统设计的早期考量之中。直到 DNSSEC 的出现，才给这个问题带来了一线解决的希望。

DNS 域名系统是一个树状结构。根域名构成了域名系统的根，根域名之下有若干个全球顶级域名，比如耳熟能详的 .com ， .org 等等。再往下便是大家更加熟悉的 baidu.com， apple.com 这些域名。就这样，域名系统构成了域名数。

域名的递归查询操作也便是在这样的树上进行从根到叶子的查询操作。比如查询 www.baidu.com 的 IP 地址。那么首先 DNS 查询报文首先发往了全球 13 个根 DNS 服务器之一。这些服务器进一步返回了 .com DNS 服务器的地址，也就是一个 NS 记录。之后，向 .com DNS 地址查询 baidu.com 的 DNS 服务器地址。最后从 baidu.com 的 DNS 服务器地址查询得到 www.baidu.com 的 IP 地址。

当然，引入了缓存和 CNAME 之后，使得查询过程变得更加复杂，但是原理上就是域名树上递归地从根到叶子的递归查询过程。

DNSSEC 的签名验证过程

DNSSEC 是这样的，在 DNS 系统中引入了一个类似 PKI 的体系，并提供了域名和公钥哈希的绑定关系。这样，可以使用公钥来验证域名解析及其签名。DNS 域名树的结构，正好提供了一个非常可靠的 PKI/CA 结构，因此 DNSSEC 是直接架设在域名树之上，而无需额外维护一个 CA 体系。

域名的签名过程是这样的，域名的 A 记录及其他记录通常称为是 RR 记录。域名所有者将生成两对公私钥 ZSK 和 KSK，分别被称为域签名秘钥和秘钥签名秘钥。使用 ZSK 域签名秘钥的私钥签名 RR 记录并形成了 RR 签名记录，也就是 RRSig 。之后，再使用 KSK 签名 ZSK 的公钥。

这个公钥信息被记录为 DNSKey 记录。并将公钥的哈希摘要提交给上一级域名所有者 DNS 服务器，形成 DS 记录。 DS 记录就这样提供了域名和公钥的绑定关系。DNSKey 记录载有公钥信息，保存在域名所有者的 DNS 服务器处；DS 记录载有公钥的哈希摘要，保存在上一级域名的 DNS 服务器中。

为什么需要 KSK 和 ZSK 呢？

是为了秘钥复用而设计的，通常 ZSK 会经常用于签名 RR 记录，其丢失和被破解的可能性较大。因此需要与身份绑定功能解耦，因此拆分出了 KSK 秘钥。

DNSSEC 验证过程和 DNS 查询过程类似，会需要从根域名出发，以此查询下一级域名的 NS 记录及其 DS 记录。之后，验证如下两点：

1. 验证 DNSKey 记录的哈希摘要是否和上级 DS 记录相匹配
2. 验证 RRSig 记录是否是 RR 的一个合法签名

如果验证通过，那么则说明 RR 记录是被 DNSSEC 所保护的，其没有被非法篡改。

DNSSEC 的信任锚点

因此我们可以发现， DNSSEC 的信任关系就是 DNS 域名树的关系。根域名 DNS 服务器作为系统的根 CA， 存储着顶级域名的 DS 信息。顶级域名服务器上则存储着二级域名的 DS 信息。一个树状的 PKI/CA 就这么建立起来了!

和 PKI/CA 体系类似，我们的浏览器中也需要保存若干预先定义的证书，作为系统信任的基石。理想情况下，我们的浏览器只需要保存根域名的公钥信息，即可递归地完成整个域名树上的全部域名的 DNSSEC 签名验证。

但是现实往往是骨干的，在某一个域名的验证路径上的任何一个节点不提供 DNSSEC 扩展，那么域名树的连通性就遭到了迫害，这个子树上的所有叶子节点（也就是域名就无法使用 DNSSEC），这也就成为了 DNSSEC 普及上的最大障碍之一。

目前，我们的域名树还没有构成一个完整的树，其上任然存在着若干个连通分支。为了缓解这种问题，我们的浏览器中现在仍需保存着多个DNSSEC公钥信息，形成多个信任锚点。同时，仍然有许多期望使用 DNSSEC 功能的域名无法部署 DNSSEC 。

DLV DNSSEC 旁路验证机制

DLV(RFC 4431) 是解决这一问题提出的缓解方案。比如域名 .xyz 不支持 DNSSEC 功能，那么自然 ertuil.xyz 域名无法进行 DNSSEC 验证。

这时候，一个被称为 aha.org 服务器向世界宣布提供 .xyz 域的 DNSSEC 验证功能。这样 ertuil.xyz 自然可以添加一条 DLV 记录（和 DS 记录格式一致）。只是这条 DLV 记录不再保存在上一级的 .xyz 服务器出，而是保存在了 aha.org DNS 服务器处。

形象的说， DLV 扩展将一个被孤立的连通分支通过挂载到主域名树的另一个节点上，实现了连通性。因此 aha.org 有一个要求就是其本身必须要实现 DNSSEC！

那么现在有一个问题，就是客户端怎么知道 .xyz 的 DNSSEC 服务委托给了 aha.org 呢？只能和信任锚点类似，通过预配置的方式，告诉客户端 .xyz 的 DNSSEC 服务器被委托给了 aha.org 并且 aha.org 是值得信任的。

这样，我们的信任锚点配置变得更加复杂化了，这是 DLV 的一个妥协的后果。还有一个问题是每一个客户端都需要配置 DLV 信息才能够使用 DLV 扩展，这使得系统的灵活性和推广得到了进一步的阻碍。