DANE 是什么
DANE（DNS-Based Authentication of Named Entities，RFC 6698）把服务端证书或公钥的指纹发布到 DNS 的 TLSA 记录里，客户端在握手时用经过 DNSSEC 验证的 DNS 答案来校验证书，因此不必只依赖公共 CA。它回答的是「信任锚放在哪」：信任锚从浏览器的 CA 列表转移到域名持有者自己控制的 DNS 区。记录名固定为 _端口._传输协议.域名，例如 443 端口的 TCP 服务写作 _443._tcp.example.com，TLSA 记录必须与 DNSSEC 签名一起使用才有意义。
基本信息
| 记录类型 | TLSA（RFC 6698），名称格式为 _端口._协议.域名 |
|---|---|
| 记录内容 | 用途类型 / 选择类型 / 匹配类型 + 证书关联数据（十六进制） |
| 四种子类型 | PKIX-TA(0)、PKIX-EE(1)、DANE-TA(2)、DANE-EE(3) |
| 选择与匹配 | 选择：整证书(0) 或公钥 SPKI(1)；匹配：SHA-256(1)、SHA-512(2) |
| 前置依赖 | 域名部署 DNSSEC 且验证链完整，否则记录可被伪造或删除 |
| 查询工具 | dig、delv、drill（Linux 与 BSD 的解析器工具集） |
| 典型端口 | _443._tcp（HTTPS）、_25._tcp（SMTP，RFC 7672） |
典型使用场景
- 邮件投递链路加固：收信方发布 TLSA，发信方按 DANE 校验对端证书，抵御中间人窃听与伪造
- 内部服务不想依赖公共 CA：私有 CA 或自签证书配上 TLSA，客户端无需预置根证书
- 证书固定的另一种落地方式：把公钥指纹放进自己控制的 DNS 区，省去逐台改配置分发
- 排查证书校验失败：用 TLSA 记录判断问题出在 CA 链还是指纹不匹配
- 行业或合规要求收紧时的补充手段：把信任锚收回自管，减少对第三方签发机构的依赖
查询与验证示例
查询与验证示例
dig +short TLSA _443._tcp.example.com # 取 TLSA 记录内容，看不到即未发布
dig +dnssec TLSA _443._tcp.example.com # 同时显示 RRSIG，确认记录被签名
delv _443._tcp.example.com TLSA # 用 delv 完成完整 DNSSEC 验证并给出结论
dig +short DS example.com # 父区有 DS 记录才构成信任链的入口
dig +short DNSKEY example.com # 本区签名公钥，缺失说明未启用 DNSSEC
unbound-host -D -v _443._tcp.example.com # 换一款强验证解析器交叉核对结果TLSA 记录逐段读法
| 字段 | 含义 | 取值与异常 |
|---|---|---|
| 用途类型 | 这条记录怎么被使用 | 0-3；取 3（DANE-EE）时证书可以不由公共 CA 签发 |
| 选择类型 | 关联到证书的哪一部分 | 0 整证书、1 公钥 SPKI；证书频繁重签时用 1（SPKI）更稳定 |
| 匹配类型 | 关联数据的算法 | 1 为 SHA-256、2 为 SHA-512；0 是整段原文，实际几乎不用 |
| 关联数据 | 由选定部分派生出的指纹 | 十六进制串；长度与匹配类型对不上说明记录被改坏 |
| 记录名 | _端口._协议.域名 | 端口或协议写错就查不到记录，表现为「没有可用的 DANE 信息」 |
TLSA 只在 DNSSEC 验证通过时才有保护力：验证型解析器未生效、或上游把 RRSIG 剥掉，攻击者就能删除 TLSA 记录让校验回落成普通 CA 校验，这正是降级攻击的路径。部署后请用 delv 这类强验证工具从外部确认验证确实生效。
目前 DANE 的成熟落地集中在邮件（RFC 7672）与少数内部服务；主流浏览器并不按 TLSA 校验 HTTPS 证书，所以 DANE 不能替代公共 CA 来兜住 Web 站点的兼容性，把它当成补充手段更合适。
轮换证书或私钥时，新旧指纹至少要在切换窗口内同时发布，并遵守 TTL：先把新指纹发布出去、等过原 TTL 再换证书，最后删掉旧记录，顺序颠倒就会出现「服务是好的、客户端却全部握手失败」。