摘要

  • TLSA RRset 只有结合 DNSSEC 验证结果才构成 DANE 证据：不安全或无法判定的数据不可用，bogus（验证失败）数据必须触发失败。
  • 证书用途、选择器和匹配类型共同决定比较对象与适用的证书验证规则。
  • 即使关联数据已安全发布，它仍可能不可用，或者与服务器实际提供的证书或密钥不匹配。
  • 运维记录必须把已发布、安全、可用、匹配和已接受五种状态分开。

设想某项服务在午夜成功更换证书。所有服务器都已部署新证书链，但部分客户端缓存的 TLSA 关联仍指向旧公钥。DNS 中确实有 TLSA，HTTPS 健康检查也正常，变更工单于是关闭。然而这些客户端仍会中止连接，因为认证过的关联与服务器提供的密钥不再匹配。

这是一个假设场景，不对应任何具体运营商。它揭示的是“发布关联”与“协调证书接受所需全部输入”之间的差距。

发布只是第一种状态

RFC 6698 规定 TLSA 由证书用途、选择器、匹配类型和证书关联数据构成。前三个字段不是附注：它们决定关联是约束公共 CA 路径、提供信任锚，还是直接指定域签发的终端证书；比较完整证书还是 SubjectPublicKeyInfo；使用原始字节、SHA-256 还是 SHA-512。

查询名称还取决于服务端口、传输协议和 TLSA 基准域名。查询错服务名，或在不安全的别名处停止，可能得到格式正确却用于错误决策的 DNS 数据。RFC 7671 还把经过安全验证的 CNAME 展开纳入首选基准域名推导。只保存 TLSA RDATA 的清单会丢失它原本约束的服务身份。

DNSSEC 决定关联能否发言

RFC 6698 把 DNSSEC 验证状态作为使用条件。安全状态的 TLSA RRset 必须用于证书关联，除非本地策略禁止具体关联。bogus 响应必须阻止 TLS 启动或中止正在进行的连接。不安全或无法判定的 RRset 不能用于 TLSA 认证。

因此，“DNS 中存在”弱于“验证为安全”，而安全仍不等于可用。客户端不认识的用途、选择器或匹配类型会使关联不可用；畸形的比较数据以及客户端策略认为过弱的算法也一样。

如果查询后没有任何可用关联，应用按正常方式处理 TLS，不采用 TLSA 输入。如果存在一个或多个可用关联，客户端要执行相应比较，并找到成功匹配。能力和本地策略不同的客户端可能对同一已发布 RRset 得出不同处理结果，这不等于任何一方否认记录存在。

服务器提供的证书仍须满足记录

证书用途改变“匹配成功”的含义。部分用途继续要求 PKIX 路径验证；DANE 用途可以建立 DNSSEC 支持的信任锚，或直接关联终端实体。选择器则决定保留同一密钥的证书续期能否继续匹配，还是证书每个字节都必须相同。

RFC 7671 补充了运维条件。DANE-TA 部署必须让服务器提供足够完整的证书链，并在特定情况下传送信任锚证书。使用 SPKI 选择器的 DANE-EE 可以在密钥不变时跨越证书续期，但服务器如果换了公钥仍会失败。摘要算法敏捷性只在先排除畸形和不支持的关联后应用。

所以服务器健康不能代替 DANE 健康。传统 PKIX 客户端可能顺利握手，而 DANE 客户端应当拒绝。同样，没有可用安全关联时，机会式策略可能继续使用未认证 TLS，但强制认证策略不能连接。接受与否是协议和客户端依据证据作出的决定，不是 DNS 行内自带的属性。

时间也会把发布与接受分开

TLSA TTL、RRSIG 有效期、解析器缓存年龄和证书部署顺序共同限制观察。RFC 7671 警告，意外变更证书或链后，客户端缓存的旧 TLSA 关联可能导致验证失败。过长的 DNSSEC 签名有效期也会延长已签名旧数据可被重放的窗口。

轮换计划必须协调新旧证书关联、权威发布、从服务器传播、验证解析器缓存、服务部署和回滚。某一权威服务器已显示新记录，并不能证明真实客户端此刻看到相同绑定。