摘要

  • Sam Weiler 撰写的 RFC 5074 描述了 DLV：当父区没有提供通常所需的 DS 记录时，验证器仍可通过另一条路径确认已签名的子区。
  • 这条路并非“免信任”。解析器必须预先把某个 DLV 域配置为信任锚，随后才能将该域中经过验证的记录用于目标区域。
  • ISC 在 2017 年删除了登记记录，却保留一个签名空区照顾旧解析器；2020 年 RFC 8749 将 DLV 调整为 Historic，理由是普通 DNSSEC 委派链已广泛铺开，而额外验证代码仍有维护成本。

DNSSEC 的链条可能断在父区

一个区域能够签名，并不代表外部解析器一定能验证它。通常，父区会发布 Delegation Signer（DS）记录，把子区 DNSKEY 与父区的签名数据连接起来。若某个上级区域尚未签名，或注册商没有接收并发布子区的 DS，验证器就无法沿既有层级一路回溯。DNSSEC 早期推广时，根区和许多顶级域都尚未签名，这使部分已经签名的子区无法形成完整的普通信任链。

DNSSEC Lookaside Validation（DLV）增加了另一条入口。RFC 5074 规定，一个独立签名的 DLV 域可以保存其下游区域的认证记录，即使那些区域并非 DLV 域的直接子区。验证器验证该 DLV 记录集后，可把它当作 DS 使用，再继续检查目标区域的 DNSKEY 与签名。RFC 4431 将 DLV 资源记录定为类型 32769；这份记录规范由 Mark Andrews 与 Sam Weiler 共同撰写。Weiler 撰写的 RFC 5074 则解释了 DLV 机制及验证器的处理方式。

关键限制在于，解析器不会因为看见一个登记服务就自动相信它。运营者必须先配置 DLV 域的信任锚。DLV 所做的是绕过缺失的父区连接，换用运营者明确接受的另一信任来源。RFC 5074 还要求优先尝试适用的普通信任锚：如果常规路径已经验证成功，就不必启动 DLV。若多个 DLV 域覆盖同一目标区域，规范把优先级留给实现，并建议把这项选择开放给运营者设置。额外路径带来了弹性，也带来了一个必须看得见的配置决定。

退场依赖真实配置，而不只依赖标准文本

ISC 称其 DLV Registry 于 2006 年开始提供服务，作为 DNSSEC 推广过程中的临时协助。随着根区及更多顶级域建立签名委派，另建信任路径的价值逐渐下降。W. Mekking 与 Dan Mahoney 撰写的 RFC 8749 记载：根区在 2010 年 7 月完成签名；截至 2019 年 5 月，1,531 个顶级域中有 1,389 个从根区获得安全委派。2020 年，该 RFC 将 RFC 4431 和 RFC 5074 改列为 Historic。

但标准状态更新并不会自动清除运营中的旧配置。ISC 在 2017 年 9 月 30 日撤下 DLV 登记记录，同时保留 dlv.isc.org 这个签名空区。ISC 报告说，若连这一区域也直接撤掉，一些仍配置为查询 DLV 的旧版 BIND 解析器可能会对大量客户端查询返回 SERVFAIL。保留空区让旧配置不再取得过时的 DLV 断言，同时减少一次性关闭服务造成的影响；这是 ISC 对其测试到的旧配置所作的说明，不代表所有解析器都会出现相同结果。

RFC 8749 点明两边的权衡：DLV 能减轻父区签名和注册商接受 DS 的压力，但也增加验证器代码的复杂度。作者列出的实现包括 BIND 9 与 Unbound，并称当时没有已知的私营企业应用。这是 2020 年发表时的观察范围，不是 2026 年所有解析器配置的统计。现有证据支持一个有限结论：DLV 在普通链条不完整时补上了入口；当常规委派普及后，它不再值得作为长期验证路径，而退出时仍必须顾及留下来的配置。

这里借用 Heng Lu 第 64 号笔记作为编辑视角：共同机制是否保持必要的最小范围，变更是否以真实部署来判断。该笔记不是关于 Weiler 或 DNSSEC 的技术证据。

来源