摘要

  • 9 月 2 日发布的 NSD 4.15.2 修复了一处访问规则判断：客户端证书名称必须与同一条规则中的地址及 TSIG 条件一起匹配。
  • 最初报告的问题不是陌生客户端闯入，而是加入第二个合法证书身份后，原本可以进行的区域传送遭到拒绝。新增测试覆盖了两个合法身份，却不能代替实际部署组合的验收。

给 DNS 主服务器再配置一个合法的辅助服务器，本意是增加副本。若第二个身份反而使第一个身份无法取得数据，配置数量的增长就可能掩盖可用性的倒退。NSD 最近修复的问题，把这种反直觉的可能性落到了具体的规则判断上。

7 月 24 日，一名用户在 NLnet Labs 社区报告中描述了一个测试：RHEL 9.8 上运行来自 EPEL 的 NSD 4.14.0，作为主服务器，另有两台不使用 NSD 的辅助服务器。两个客户端各有证书名称和地址；两条允许区域传送的规则使用相同的 TSIG 密钥。

日志显示，TLS 客户端握手成功，TSIG 检查通过，第一个证书名称也匹配。但接着出现了与另一名称不符的判断，区域传送最终被拒绝。只保留一条规则时，传送可以成功。报告中的私有地址和非标准端口属于测试环境，不能据此画出真实公共网络的故障分布。

8 月 28 日，维护者回复称已复现并修复。随后，9 月 2 日的版本公告明确列入这项修正；截至 9 月 8 日核查，官方下载页仍将 4.15.2 标为当前版本。公开讨论中没有最初报告者升级后的复测结果，不能把维护者确认扩写成所有用户均已恢复。

不是让证书检查变松，而是让条件配对正确

修复提交改变了匹配的组合方式：地址、TSIG 密钥和证书名称，在同一个访问规则条目的判断中共同参与。此前独立进行的证书名称检查，可能因为另一条规则的名称不同而返回失败。

两个客户端拥有不同身份，本来就意味着一个客户端不应匹配另一个客户端的证书名称。问题不在于这种“不匹配”出现，而在于它被用来否决一个本已满足要求的选择。修复后，名称错误仍然不能满足相应规则；变化是它不再凭借另一身份的差异，错误阻断合法匹配。

这里也不能把所有规则简化为“任何一条通过就永远放行”。显式阻止规则仍有意义。准确的说法是：证书条件回到所属条目内，与该条目的其他条件一起判断，而不是取消身份约束。

这个差别对证书轮换尤其重要。旧身份和新身份并存时，运营者增加的是预期允许的组合，不是在要求一个客户端同时具有两个不同名称。只监测 TLS 会话是否建立，无法证明区域数据已按预期交付。

正向测试与拒绝测试，必须一起看

新增回归测试的提交加入了第二个证书身份及其规则。固定在发布标签上的完整测试要求两种合法证书请求都返回区域内容中的标记，同时保留错误名称、未知证书颁发机构以及未提供客户端证书等情况下的拒绝检查。

但该测试的两条证书规则允许任意 IPv4 来源，并使用 NOKEY；原始报告则使用不同地址和共享 TSIG 密钥。因而，源码中的断言有力地说明了多证书身份的预期行为，却不是对地址、密钥、名称全部交叉组合的穷尽证明。本文查阅了代码与测试，没有自行运行 NSD，也没有测量客户网络的恢复情况。

测试还设置了一条独立的 TSIG 授权规则，使符合该规则的请求可经普通 TLS 或 TCP 取得数据。这是配置明示的另一种许可，不是新发现的绕过。RFC 9103区分了身份认证与内容保密：TSIG 本身不加密区域内容。运营者是否允许这种组合，要由其明确的传送策略决定，不能从一次加密连接成功推导出整个副本组都满足保密要求。

另外，官方安全公告记载的 CVE-2026-12490 是 6 月公布、在 4.14.3 中修复的另一项客户端证书绕过问题。不能把它的漏洞编号或影响版本范围贴到这次“多个合法身份导致拒绝”的修复上。现有证据也没有给出新的利用事件、受影响客户数或完整版本矩阵。

这与卢恒关于最小且可在本地核验的安全约束的论述形成一个有限的工程对应：把允许与禁止的条件写清楚，而非用隐含放宽换取表面可用。这里是作者对原则的应用，并非卢恒对 NSD 的评价或背书。