RFC 7671《DANE 协议：更新与运行指南》中文导读

1. 定位

DANE（基于 DNS 的命名实体认证）用 DNSSEC 保护的 TLSA 记录来约束某个服务应当出示什么证书，从而摆脱对公共 CA 体系的单点信任。RFC 6698 定义了机制本身，而 RFC 7671 在若干年实现经验之后对其进行澄清与更新，并为实现者、运营者和协议设计者提供操作指南。

对邮件生态而言，这是 SMTP DANE（RFC 7672）的直接依据：MX 主机发布 TLSA 记录后，发送方 MTA 可以在投递前确认对端证书，从而把机会性 TLS 升级为可抵抗中间人的强制 TLS。

2. TLSA 记录的三个参数

一条 TLSA 记录由证书用法、选择器与匹配类型三个参数加证书关联数据组成：

_25._tcp.mx.example.com. IN TLSA 3 1 1 
                                   |  | |
                                   |  | +-- 匹配类型 Matching Type
                                   |  +---- 选择器 Selector
                                   +------- 证书用法 Certificate Usage

• 证书用法：PKIX-TA(0)、PKIX-EE(1)、DANE-TA(2)、DANE-EE(3)；
• 选择器：Cert(0) 匹配整张证书，SPKI(1) 匹配公钥信息；
• 匹配类型：Full(0) 全量，SHA2-256(1)，SHA2-512(2)。

3. 对 RFC 6698 的主要更新

文档第 12 节汇总了对 RFC 6698 的更新，核心几条是：

• TLS 能力要求：客户端至少要支持 TLS 1.0，并且必须支持 SNI（服务器名称指示）——否则多域共用主机无法正确出示证书。
• 用法取舍：不推荐应用支持全部四种证书用法；推荐的设计是只支持 DANE-EE(3) 与 DANE-TA(2)。
• DANE-EE(3)：对端身份匹配与证书有效期的判定仅依据 TLSA 记录集本身，不再另行检查证书中的名字与有效期；同时明确了通过 usage 3、selector SPKI(1) 对裸公钥（RFC 7250）做 DANE 认证的方式。
• DANE-TA(2)：发布摘要型 TLSA 记录（含发布完整公钥的“2 1 0”形式）的服务器，必须在 TLS 证书消息中包含该 TA 证书本身，否则客户端无法构造出可验证的链。
• PKIX-TA(0)：当首个受信任的签发者并非自签名时，客户端可能需要处理超出该签发者的扩展信任链。
• CNAME 与基域：使用 DANE 的应用协议应当规定，在可能的情况下用经安全 CNAME 展开后的名字来推导 TLSA 基域。

4. 发布者的运维规程

DANE 最大的运维风险是不同步：证书已经更换而 TLSA 记录还是旧的（或反过来），会直接导致所有启用 DANE 的对端拒绝连接。文档为此给出了明确的时序规程。

密钥轮换的通用做法是“先加后删”：

• 在部署新证书之前，先把新证书对应的 TLSA 记录加入 RRset，与旧记录并存；
• 等待至少一个 DNS TTL（并考虑负缓存与解析器时钟偏差）后，再在服务器上启用新证书；
• 确认全部服务节点都已切换、且旧证书不再被出示之后，才删除旧的 TLSA 记录。

若使用第三方服务提供商托管邮件服务，则必须与其协调：由谁负责在什么时间点更新 TLSA 记录，是 DANE 部署失败的最常见组织性原因。文档第 6 节专门讨论了服务提供商与 TLSA 发布者之间的同步问题。

5. 摘要算法敏捷性与记录大小

当一条 TLSA RRset 中同时存在多种摘要算法的记录时，客户端应按“同一证书用法与选择器下，只使用最强的可用摘要算法”的规则处理，以便在算法迁移期平滑过渡。发布者在切换摘要算法时，同样遵循先并存、后删除的次序。

文档还提醒注意 DNS 响应大小：DNSSEC 签名本身已经不小，TLSA RRset 若包含多条全量证书记录，容易超出 UDP 报文限制而触发 TCP 回退甚至失败。因此实践中一般使用 SHA2-256 摘要（匹配类型 1）而非全量证书。

最后，DANE 的全部安全性都建立在 DNSSEC 之上：验证方必须使用具备 DNSSEC 验证能力的解析器，且解析器到应用之间的通道必须可信，否则整套机制形同虚设。

参考：https://www.rfc-editor.org/rfc/rfc7671.txt