我们运行私有 CA 并同时使用 DNSSEC 和 DANE。最近我们决定重新发布我们的 CA 根密钥和颁发者密钥，因为这些密钥是在 2008 年设置 PKI 时以 1024 位生成的。我们最初的 TLSA RR 将发布 CA 指向信任锚。然而，重新阅读 RFC 和各种与 DANE 相关的评论提出了是否应该使用 ROOT 公钥的问题。
我们目前正在与我们现有的 DANE 记录平行地试验这个想法。当我们使用https://dane.sys4.de/smtp/进行验证时，我们现有的服务器密钥会检出，但即使我们尚未将服务器密钥切换到新的证书链，也会报告新的 ROOT TLSA 记录。此外，报告了新的信任锚 TLSA RR：
可用的 TLSA 记录
2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e - self signed certificate in certificate chain: (19)
而同一主机的当前 TLSA RR 以这种方式报告：
2, 0, 2 67274b3554289058[...]5fd3917510e6722a
报告的第一条记录是指新的根 CA。第二个是指原来的Issuing CA（由原来的Root CA签名）。
当我检查消息时self signed certificate in certificate chain: (19)，我形成的印象是这是一个错误。但是，如果这是一个错误，那么 CA Root 公钥究竟在哪里适合 DANE 方案？
我通过实验发现是这样的：
如果将根 CA RR 和发出 CA
TLSARR 都放在 DNS 转发区域中，那么上面报告的错误就会消失。例如：鉴于此主机 RR：
如果转发区域中的自签名根 CA 仅存在以下记录，那么我们会看到原始问题中报告的错误（或警告我不确定是哪个）：
检查此测试站点：
产生此错误或警告：
但是，如果
TLSA为由根 CA 与自签名根 CA 一起签名的发行 CA 添加以下 RR；主机RR保持不变；那么两个TLSARR 都被报告为可用而没有任何错误或警告消息：TTL到期后访问测试站点：
给出了这个：
推断是自签名证书“可能”有效但不受信任，而完整的证书链既有效又受信任。
尽管如此，我还是想解释一下这个过程的机制。