7. Stub Resolver Considerations (存根解析器考虑事项)

尽管协议并未严格要求这样做, 但大多数 DNS 查询来自存根解析器。根据定义, 存根解析器是最小化的 DNS 解析器, 它们使用递归查询模式将 DNS 解析的大部分工作卸载到递归名称服务器。鉴于存根解析器的广泛使用, DNSSEC 架构必须考虑存根解析器, 但存根解析器所需的安全功能在某些方面与安全感知迭代解析器所需的功能不同。

即使是安全无感知存根解析器也可能从 DNSSEC 中受益, 如果它使用的递归名称服务器是安全感知的, 但是存根解析器要真正依赖 DNSSEC 服务, 存根解析器必须信任所涉及的递归名称服务器以及其自身与这些名称服务器之间的通信通道。第一个问题是本地策略问题: 实质上, 安全无感知存根解析器别无选择, 只能将自己置于其使用的递归名称服务器的控制之下, 因为它不会自己执行 DNSSEC 有效性检查。第二个问题需要某种通道安全机制, 正确使用 DNS 事务认证机制 (如 SIG(0) ([RFC2931]) 或 TSIG ([RFC2845])) 就足够了, 适当使用 IPsec 也可以。特定实现可能有其他可用选择, 例如操作系统特定的进程间通信机制。此通道不需要机密性, 但需要数据完整性和消息认证。

信任其递归名称服务器和与它们的通信通道的安全感知存根解析器可能选择检查其接收的响应消息的消息头中的已认证数据 (Authenticated Data, AD) 位的设置。存根解析器可以使用此标志位作为提示来了解递归名称服务器是否能够验证响应的 Answer 和 Authority 部分中所有数据的签名。

如果由于任何原因安全感知存根解析器无法与其使用的递归名称服务器建立有用的信任关系, 它还可以采取另一个步骤: 它可以通过在其查询消息中设置检查禁用 (Checking Disabled, CD) 位来执行自己的签名验证。因此, 验证存根解析器能够将 DNSSEC 签名视为区域管理员与存根解析器本身之间的信任关系。