摘要

  • draft-ietf-dance-client-auth-14 于 9 月 11 日上传，目前仍处于工作组最后征求意见及文件负责人跟进阶段；它是 Internet-Draft，不是已批准的标准或 RFC。
  • 第 14 版明确列出四种“非 DNSSEC 验证 TLSA 记录集”的结果：验证失败、未认证回答、NXDOMAIN 与 NODATA。服务器必须终止握手，或在本地政策允许时把客户端视为未认证。
  • 一份受访问控制的查询决策记录，应保存结果类别、验证路径、政策版本和后续授权状态。这是本文的治理建议，不是 IETF 新增要求。

版本号背后的那一处变化

IETF Datatracker把《通过 DANE TLSA 记录进行 TLS 客户端认证》第 14 版的更新时间记为 2026 年 9 月 11 日。它由安全领域的 DANCE 工作组维护，目标状态为 Proposed Standard。不过页面当前仍显示 In WG Last Call，文件负责人正在跟进；IESG 一栏是 Waiting for AD Go-Ahead::AD Followup。这些是流程坐标，不能改写成批准结论。

文件历史显示，13 版在 7 月 23 日上传；7 月 28 日，工作组状态从 Submitted to IESG for Publication 返回 In WG Last Call；14 版在 9 月 11 日被接受。新闻点不是文件已经抵达终点，而是新版本改变了服务器判断的一段文字。

13 版只处理 DNSSEC 验证失败。14 版改为：凡返回结果不是经 DNSSEC 验证的 TLSA 记录集，都进入同一分支，并把验证失败、因未签名区域或不安全委派产生的未认证回答、NXDOMAIN、NODATA 一一列出。

随后规则没有变成四套。服务器必须发出 TLS handshake_failure 并终止连接，或者在其政策允许时继续，但把客户端视作未认证。新版扩充了输入分类，没有替运营者选择风险容忍度。

客户端报出查询名

RFC 6698与 RFC 7671中的常见 DANE 路径，是客户端用 DNS 中的 TLSA 记录核验服务器证书或公钥。DANCE 草案把同一思路转向客户端身份。

支持该方案的服务器在 CertificateRequest 中发出拟议的 dane_clientid 扩展。希望使用 DANE 的客户端再随 Certificate 消息提供自己 TLSA 记录的完整所有者名称。服务器不根据端口或传输协议拼接名称，而是查询客户端给出的精确名称。方案要求 TLS 1.3 或 DTLS 1.3 及以上版本。

服务器可以在本机沿 DNSSEC 链验证到已配置的信任锚，通常是根；也可以通过安全连接依赖验证型解析器，并要求回答带有 AD 位。这两种路径都可能给出相同结果，但证据来源不同。审计时若不记录采用哪条信任路径，最终决定便无法完整复现。

截至研究截点，IANA TLS ExtensionType 注册表尚未显示 dane_clientid 的已分配值；草案本身也使用将来分配的表述。因此不能把正在讨论的扩展写成已有编号或广泛部署的能力。

四类结果对应四个起点

DNSSEC 验证失败意味着按适用的信任链和验证规则，所得数据没有通过认证。它是密码学观察，不自动证明攻击，也不自动指出哪个参与者犯错。

未认证回答是另一种情况。区域未签名，或者到 TLSA 所有者名称的委派路径不安全时，该处没有形成要求认证数据的完整链条。它与“有签名但验证不通过”并不相同。RFC 4033对签名区域、未签名区域与信任锚预期的区分，正是为了避免把二者混为一谈。

NXDOMAIN表示所查询名称不存在；NODATA则容许名称存在，只是没有被查询的 TLSA 类型。RFC 2308确立的否定回答处理保留了这一差别。设备名称被删除、名称已经建立但凭据尚未配置，显然需要不同的排查路线。

四者都不是恶意行为判决。旧名称、刻意的不安全委派、尚未完成的配置、破损的验证链都可能产生相关观察。草案让 TLS 只处理它真正知道的状态，这是克制而正确的边界。

问题发生在记录端。如果日志只剩一个 handshake_failure，四类输入已经被同一个结果覆盖；如果连接继续，日志又只写“允许未认证”，原因同样消失。服务可用不等于证据完整。

DNS 之后还有两道门

取得验证过的 TLSA 记录集也未完成客户端认证。服务器还要依据记录中的证书用途、选择器与匹配类型，把内容同客户端证书或裸公钥比较。匹配失败时，草案再次允许服务器终止，或依政策按未认证状态继续。

匹配成功仍不等于应用授权。草案允许服务器实施自己的允许名单、身份域范围或角色政策。一个经过 DANE 认证的客户端可能没有访问某项资源的权限；一个以未认证状态继续的连接，也可能只能到达公开或受限界面。

所以至少要分开三层：DNS 查询类别、DANE 凭据匹配、应用授权。把三者压成一个“成功”字段，会让不同权力主体的决定看起来像同一件事。

留下一份最小查询决策记录

没有必要把内部案卷塞进 TLS。客户端名称可能对应个人、设备或业务职责，草案的安全考量也提示了关联与隐私风险。所缺证据适合存入一份访问受限的查询决策记录。这是 Daniel Kade 的编辑建议，不是 IETF、DANCE 或 IANA 要求。

记录可以绑定观测时间；客户端提交的 TLSA 所有者名称的授权明文或受保护哈希；查询类型；四类结果中的一类；DNSSEC 状态；本地验证还是安全连接下的外部解析器；信任锚或解析政策引用；服务器政策版本；最终选择的分支。若流程继续，还应分别记录凭据是否匹配及应用是否授权。

没有抵达的步骤应写“未到达”，不能靠想象补齐。NXDOMAIN 后不能虚构证书不匹配，不安全委派也不能改写成“伪造”。保存期限和查询权限应与身份敏感度匹配。公开报告可以只给出各类数量与政策变更，不公开设备名称或连接历史。

Heng Lu 的 Policy Mirror要求把行动者、规则与证据放在同一面镜子里观察：DNS 运营者控制记录与委派，客户端声明待查询的名称，服务器选择验证路径和 TLS 处置政策，应用最终分配权限。Minimum Initial Specification强调共享规范应足够小，让本地未来决策仍可调整。14 版保留了这种空间；最小记录只是防止本地选择失去可解释的来源。

来源

  1. IETF Datatracker — draft-ietf-dance-client-auth-14
  2. Datatracker 文件历史
  3. 不可变 13 版
  4. 不可变 14 版
  5. DANCE 工作组
  6. RFC 6698 — DANE TLSA
  7. RFC 7671 — DANE 运行规则
  8. RFC 2308 — DNS 否定缓存
  9. RFC 4033 — DNSSEC 导论与要求
  10. IANA TLS ExtensionType 注册表
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Minimum Initial Specification