摘要

  • 只有经过 DANE 完整验证、且 TLSA 链与服务端证书链相符的握手，才能为特定 SNI 名称与端口建立非零扩展钉扎。TLSA 的 TTL 管当前数据新鲜度，钉扎期限管未来证据是否仍可取得。
  • 有效的 TLSA 不存在证明、不安全委派证明，或经过验证的零期限转换，都能清除钉扎；钉扎仍有效时直接缺少扩展并不等于否定证明，客户端可能必须中止连接。

先认证那个用来查询 DNS 的服务

DNS over TLS 提供了一个很直观的难题。客户端想用 DANE 认证 DNS 解析器，需要先取得该服务的 TLSA 记录及其 DNSSEC 验证链；但此时要使用的解析器正是尚未完成认证的对象。RFC 9102 提出的实验性 dnssec_chain 扩展，让服务端把完整的 DNSSEC 认证链直接放进 TLS 握手，从而绕开这次带有循环依赖的带外查询。

服务端响应里同时出现两类信息。一组 RR 与 RRSIG 回答“此刻什么是真的”；16 位的 ExtSupportLifetime 则以小时为单位，回答“该服务器或为同一名称服务的集群，还承诺支持这个扩展多久”。两个答案在同一握手里交付，但有效期绝不能合并。

Shumon Huque 与 Viktor Dukhovni、Willem Toorop、Paul Wouters、Melinda Shore 共同署名 RFC 9102，文档同时把最初构想归于 Adam Langley。IETF 档案与 Huque 本人的公开简介显示，他长期从事 DNS 基础设施、网络与安全协议工作，现任职于 Salesforce，此前曾在 Verisign 与宾夕法尼亚大学工作。这说明他为何是理解此设计的合适人物入口，却不把一份集体完成的实验性 RFC 变成个人发明。

看到字段，不等于取得承诺

非零钉扎有严格的起点。响应必须包含有效的 TLSA 认证链，该链必须与服务端在 TLS 中出示的证书链匹配，并让握手通过 DANE 认证。只验证消息格式、只由 PKIX 接受证书，或只看见一个非零数值，都不能建立相同状态。否则攻击者反而可以注入一个长期钉扎制造拒绝服务。

状态键也很窄。客户端请求中带入 TCP 端口，服务名称取自 SNI。服务端为这种带内方式构造 TLSA 名称时，不得把 SNI 后面的 CNAME 展开为另一个名称。因此钉扎属于“名称＋端口”，不自动覆盖同一 IP 上的其他虚拟主机，也不覆盖该域名的所有服务。

客户端仍掌握期限上限。RFC 9102 允许它把服务端给出的值缩短到本地最大值，并指出受控服务端可能恶意报出七年上限的理论风险。但本地上限太短，也会缩小抵抗降级的时间窗。这不是服务端的单方面命令，而是服务端提出、客户端按本地风险政策接受的有界承诺。

一次握手里的两只钟

经过验证的 TLSA RRset 可以缓存到其 TTL 到期。在此之前，客户端可以直接用它认证后续连接，不必每次请求 dnssec_chain。TTL 一到，即使扩展钉扎还剩很久，旧 TLSA 也不能继续当作当前证据；客户端必须重新取得有效状态。

短钟由 TTL 与 RRSIG 有效窗口组成，保护记录的新鲜度。长钟由 ExtSupportLifetime 构成，保护证据供应能力。RFC 9102 明确说明，长钟不受任何 DNS TTL 或 RRSIG 失效时刻限制，原因不是它延长了旧签名，而是它要求服务端在长钟期间更新并交付新的链。只保留一个过期时间，会把“数据还新鲜”与“服务仍负有回答义务”混成一件事。

会话恢复又增加一个必要区分。恢复的 TLS 会话不会发送 dnssec_chain；在 TLS 1.3 中，承载该扩展的 Certificate 消息本身也不会重发。如果监控系统把所有“无扩展”的握手一律判成降级，就会制造错误告警。回执必须同时记录完整或恢复握手、缓存 TLSA 的到期点、钉扎到期点以及实际用于认证的证据。

经过签名的“没有”，不是没有回答

域名运营者可以删除 TLSA。此时，支持扩展的服务器应返回覆盖相应名称与端口的 DNSSEC 不存在证明。客户端验证该证明后，现有钉扎可以清除；证明委派已不再安全，也可以清除钉扎。之后是否改用 PKIX，仍由客户端本地政策决定。

直接省略扩展没有这种权威。若钉扎尚未到期、缓存中也没有未过期 TLSA，客户端就必须要求服务端返回带有效 TLSA 或有效不存在证明的扩展。服务端没有返回时，客户端必须中止或延迟通信，直到通过带外方式取得有效证据；带外也失败，TLS 连接就必须终止。

这条差别正是反降级机制的核心。攻击者即使拿到一张会被 PKIX 接受的错误证书，也不能只靠隐藏 DANE 材料让客户端自动退回 WebPKI。沉默不继承否定证明的效力。

所以，RFC 9102 特别指出：要求扩展继续存在，不等于要求 TLSA、DANE，甚至 DNSSEC 永久存在。域名方可以删除 TLSA，也可以撤掉 DS、终止安全委派。钉扎期间仍需保留的是可验证的状态交付——先前是正面链，转换后可以是否定链。

下线顺序：先归零，再等待

如果运营者要彻底停用扩展，不能一步拔掉。规范要求先在经过 DANE 认证的握手中把 ExtSupportLifetime 改为零，再等待此前所有非零期限都可能自然到期，最后才停止服务。TLSA 或 DNSSEC 可以更早移除，但面对仍持有旧钉扎的客户端，服务器仍必须交付相应的认证否定证明。

托管环境会让这条时间线跨越组织边界。域名所有者控制 DNS 并可能迁移供应商；托管商可能控制证书、TLS 节点与认证链生成。RFC 因而建议，非零期限只能在双方同意时启用。只要集群中有一个节点无法兑现，负载均衡就会把同一客户的连接变成时好时坏的硬失败。

带内交付也没有让服务器自封信任根。客户端仍从预配置的 DNSSEC trust anchor 验证链，需要维护锚点轮换，也需要足够准确的时间判断 RRSIG。扩展解决的是证据运输，不是证据的最终权威来源。

RFC 9102 的实验性地位必须保留。TLS 工作组曾担心钉扎会增加部署难度，文档把真实部署中的这些问题列为实验要研究的对象。此次审阅的公开材料无法证明当前各大客户端或服务器的采用率。它真正留下的，是一种精确状态机：正面声明、经过认证的否定，以及根本没有回答，必须导致不同的判断。

来源