DANE/TLSA 记录检测工具
向多个公共 DNS 解析器查询域名邮件服务器（MX 主机）发布的 TLSA 记录，检测是否已配置 DANE 证书锁定。
诊断 DANE（TLSA 记录）的证书验证
DANE 是这样一套安排：邮件服务器所出示的证书，**要拿存在 DNS 里的 TLSA 记录来验。** 本工具把某域名各 MX 主机所公开的 TLSA 记录投向数个公开解析器，报出是否已然配好。
**此处万万不可略去的前提是：DANE 惟有立在 DNSSEC 之上方能成立。** 担保 TLSA 记录不曾被篡改的，正是 DNSSEC；**故而在未启用 DNSSEC 的域名上摆下 TLSA，作为防御便等于零。** 这一点正是它与 MTA-STS 最大的分别：MTA-STS 把信任托付给网站证书，**DANE 则托付给 DNSSEC。** 运维上另一处要紧的，是证书的更新——**替换服务器证书时若不同时更新 TLSA 记录，验证便通不过，邮件也就到不了。** 所需的次第是：先添上新的指纹，切换过去，最后才删去旧的。
使用方法
- 输入域名 只给域名即可，形如 `example.com`。
- 查看每台 MX 主机的结果 **TLSA 记录置于各 MX 主机的 `_25._tcp.主机名` 之下。**
- 一并确认有无 DNSSEC **少了 DNSSEC，TLSA 记录便谈不上什么保护。**
- 筹划证书更新的步骤 **让新旧指纹并存一段时日，再行切换。**
用好本工具的小技巧
- TLSA 记录并不位于普通域名下，而是位于特殊名称 `_25._tcp.{MX 主机名}` 下，这就是为什么直接查询域名本身找不到 TLSA 记录的原因。
- 「未配置 DANE」并非异常。DANE 是邮件加密的额外防护层，目前大多数邮件服务器仍未启用。
- DANE 的可信度依赖于该域名的 TLSA 记录本身受到 DNSSEC 签名链的保护。即使找到了 TLSA 记录，也建议配合姊妹工具「DNSSEC 验证检测工具」确认该域名是否已启用 DNSSEC。
- 如果存在多个 MX 主机，本工具会按优先级（数值越小优先级越高）检测最多 3 个主机。
- 如果各解析器结果不一致，可能是记录刚刚更新、缓存尚未统一所致。请稍后重新检测。
这些场景会用到
检视自家的邮件服务器
可揪出这样的出入：本以为摆好了 TLSA，MX 主机那边却没有。
更新证书之前先查一遍
**次第一错邮件便停，故事前一查极为划算。**
在 DANE 与 MTA-STS 之间权衡
**按您更愿把信任托付给谁来选——DNSSEC 抑或网站证书；二者亦可并用。**
弄清往来对象做到了哪一步
可以看出对方究竟用不用 DANE。
DANE 的术语
- TLSA 记录
- **把证书或公钥的指纹放进 DNS 的记录。** 它置于形如 `_25._tcp.mail.example.com` 的名称之下。
- DNSSEC
- **DANE 的前提。** 少了它，TLSA 记录自身便可能被篡改，防御也就无从立起。
- 用法字段
- TLSA 记录里的头一个数字，言明它所指的是证书本身，抑或某个证书颁发机构。
- DANE-EE
- 登记服务器证书本身指纹的方式。**它容许在不依赖任何机构的前提下完成验证。**
- 轮换
- 替换证书及其 TLSA 记录的作业。**先添上新指纹，事后再删去旧的。**
- 机会性 TLS
- 对方支持便加密的那种旧式随意做法。**DANE 与 MTA-STS 把它提升为必须。**
常见问题
闲话 ― 用「证书」而非仅靠「不被窃听」来保护邮件加密
SMTP（邮件传输协议）的加密方式 STARTTLS 长期存在一个弱点：多数邮件服务器采用「机会性加密」（Opportunistic TLS），即对方不支持加密时便退回明文传输，这为「STRIPTLS 攻击」打开了大门——中间人攻击者可以悄悄剥除 STARTTLS 指令，使连接在双方都未察觉的情况下降级为明文。
DANE（基于 DNS 的命名实体认证，RFC 6698）通过在 DNS 中发布 TLSA 记录来应对这一问题。预先将邮件服务器的证书（或其公钥哈希）锁定在 DNS 中，发送方服务器便可验证所连接的主机是否确实提供了预期的证书。与普通 SSL/TLS 证书验证不同，DANE 完全不依赖证书颁发机构（CA）的信任链，只信任 DNSSEC 签名链。
DANE 的弱点在于，只有当域名本身经过 DNSSEC 签名时才能生效。若未启用 DNSSEC，则无法排除 TLSA 记录本身在传输过程中被篡改的可能，DANE 的保证也就失去意义。因此 DANE 的普及程度与 DNSSEC 的普及程度密切相关，欧洲部分注册局（如 .nl、.cz）已率先推广采用。