摘要

  • TLSA 记录位于由端口、传输协议和基础域名组成的所有者名称之下。匹配成功证明的是这一服务组合内的一份证书关联，不是证书对整台主机、整个域名或所有业务的普遍权力。
  • 可复核证据必须保留 TLSA 查询名、DNSSEC 状态、certificate usage、selector、matching type、握手材料、应用规则与观测时间。只留下“DANE 通过”会丢掉授权的边界。

两个监听端口不是同一个授权对象

设想一个测试环境：service.example 在 TCP 443 和 8443 上展示相同证书。签名区域只在 _443._tcp.service.example 发布可用 TLSA RRset。访问 443 的客户端能够验证 DNSSEC 链，再按记录指定的方法检查证书或公钥。访问 8443 的客户端必须查询 _8443._tcp.service.example，不能借用前一个结果。

这是合成控制案例，不指向某个产品。它暴露的错误很常见：系统把“这张证书曾在这台主机上通过 DANE”当作可复用结论。RFC 6698 没有定义这种主机级通行证。端口和传输标签被写进名称，正是为了让同一主机上的不同服务拥有不同的关联、信任方式和轮换节奏。

若日志只按证书指纹或主机名保存通过结果，授权发生时最关键的维度就被删除了。以后即使还能找到同一张证书，也无法说明当时查的是哪个服务。

查询名本身就是证据

直接运行在 TCP 上的 TLS 服务通常使用 _端口._tcp.基础域名。端口是十进制数字，不是事后补上的服务昵称；传输标签把 TCP 与其他传输分开；基础域名则由应用协议规定，不能由分析人员为了方便而任意挑选。

名称跳转会使证明链更长。CNAME 可以改变 TLSA 查询的最终位置，但证书身份判断仍受应用规则约束。采用 SRV 的协议依据 RFC 7673 从服务发现结果导出基础域名。SMTP DANE 又要经过 MX 发现，并对 DNS 错误、引用标识和降级行为使用 RFC 7672 的专门规则。套接字日志中可见的目标地址或主机名，未必足以还原哪个 TLSA 名称真正具有权威。

最低限度的记录应保存原始应用目的地、所有经过 DNSSEC 保护的发现步骤、展开前后的名称、端口、传输协议、最终 TLSA 查询名、DNSSEC 结果，以及把这些元素连起来的应用标准。没有这条链，“TLSA matched”不能被第三方重放验证。

四种 usage 是四种信任决定

TLSA RDATA 的第一个字节决定验证宪法。RFC 7218 为四个最初值提供了稳定名称。

PKIX-TA(0) 在正常 PKIX 路径验证之上限制可接受的 CA；PKIX-EE(1) 在路径验证之上限制终端证书。DANE-TA(2) 通过 DNSSEC 发布信任锚关联；DANE-EE(3) 则直接关联服务的终端证书或公钥。

同一串字节在一种 usage 下匹配，不能被描述成另一种 usage 的成功。使用 1 时，终端材料相同并不允许忽略已过期或无效的 PKIX 路径；使用 3 时，也不能未经应用标准就自动套用所有 Web PKI 名称检查。应用还可以缩小可用集合。SMTP DANE 的运行规则并不是把通用浏览器证书逻辑原样搬到邮件传输。

因此真正的问题不是“DNS 里有没有 TLSA”，而是哪个服务所有者选择了哪种信任模型、客户端是否支持它、应用标准是否允许它，以及失败时是否会降级。

selector 和 matching type 决定匹配对象

selector 0 选择完整 DER 证书；selector 1 选择 SubjectPublicKeyInfo，也就是公钥及其算法结构。证书到期后可以保留同一把钥匙重新签发，此时 SPKI 关联可能继续通过，完整证书关联则会改变。

matching type 0 比较原始选定字节；1 比较 SHA-256；2 比较 SHA-512。只保存一段十六进制值的仪表盘，无法告诉审计人员它是完整证书、公钥，还是二者之一的摘要。

这些选择直接影响恢复。绑定完整终端证书对象更窄，但每次换证书都要协调 DNS；绑定 SPKI 可跨越同钥续证，却扩大了同一私钥失陷的后果。信任锚关联覆盖的变化范围又不同。没有脱离具体部署、密钥保管和回滚能力的“永远最安全组合”。

DNSSEC 验证先于 TLSA 权力

收到格式正确的 type 52 响应不等于获得 DANE 授权。客户端必须区分 secure、insecure、bogus 和 indeterminate。Extended DNS Error 可以解释失败原因，却不能替代密码学验证状态。

未签名的伪造记录不能覆盖正常证书验证。反过来，当应用把一个 secure 且可用的 TLSA RRset 视为服务承诺时，匹配失败后静默退回弱模式会重新打开降级通道。RFC 7672 要求 SMTP 客户端在发现可用的安全 TLSA 记录后验证服务器；验证失败时不得经该服务器投递邮件。

DNSSEC 认证的是某个 DNS 名称下的发布。它不证明发布者独占匹配私钥，不证明端点配置正确，也不等于商业主体授权了此服务的所有使用。DNS 签名链被攻破，可以发布新的 DANE-EE；TLS 私钥被攻破，则可能继续满足旧记录。这两条控制链应分别保管、分别审计。

匹配成功仍未到达应用授权

TLSA 可以证明握手中选定的证书材料满足一份 DNSSEC 认证的关联。它不能证明 ALPN 选中了正确协议、HTTP authority 合法、SMTP 目的地无误、客户端身份已认证、用户有权执行动作，或交易已经完成。

代理还会制造新的边界：前端终止一个通过 DANE 的连接，再向后端建立另一条连接。前一跳的证明不会自动穿过代理。多个功能不同的端点共用同一终端证书时，攻击者可能把流量导向集合中的另一台服务器。RFC 7672 因此提醒，共享终端关联只适合功能等价或协议互不兼容、重定向不能给攻击者带来好处的场景。

可辩护的审计语句应是：“在这个时间，这个所有者名称下 secure 的 usage 3 记录与握手展示的 SPKI 匹配。”它不应被压缩成“这个域名授权了请求”。

轮换是一段重叠时间

稳健轮换通常先发布新关联，再部署新材料，在一段时间内同时保留新旧关联，经过多个解析器和客户端视角验证后，才在 TTL、DNSSEC 签名有效期和端点状态允许时移除旧值。

不同 tuple 的顺序不同。同钥续证可能不改变 SPKI 关联；换钥一定改变。DANE 信任锚轮换也不同于终端证书轮换。缓存可能保留已删除记录，端点可能继续展示旧证书，签名器也可能在正确 RRset 之外提供过期链。

控制记录应标明权威发布、递归缓存观测、证书或公钥部署、旧材料移除和签名有效期。一个解析器上的绿色结果，不能证明全球转换完成。

用越界尝试验证边界

在两个端口展示同一证书，只为其中一个发布 TLSA；更改传输标签；经 CNAME 或 SRV 跳转服务；逐一测试 usage。让 usage 1 的选定字节匹配，同时故意破坏 PKIX 路径，确认客户端拒绝。

再以同一把钥匙续证，比较 selector 0 与 1；用新钥匙轮换并保留重叠；让不同缓存历史的递归解析器查询；分别制造 secure、insecure、bogus、indeterminate。最后让 TLSA 匹配通过，但令 ALPN 或应用授权失败。

正确结果不是 DANE 批准更多，而是实现拒绝把一份精确证据带出它的 tuple。