我们运行一个私人CA，同时使用DNSSEC和DANE。 最近我们决定重新颁发我们的CA根和颁发者密钥，因为当我们的PKI在2008年build立时，这些密钥是在1024位生成的。我们原来的TLSA RR指向颁发CA作为信任锚。 然而，重新阅读RFC和各种与DANE有关的评论提出了是否应该使用ROOT公钥的问题。
我们目前正在试图将这个想法平行于我们现有的DANElogging。 当我们使用https://dane.sys4.de/smtp/进行validation时，我们现有的服务器密钥会检出，但即使我们尚未将服务器密钥切换到新的证书链，也会报告新的ROOT TLSAlogging。 此外，新的信任锚点TLSA RR因此被报告：
可用的TLSAlogging
2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e - self signed certificate in certificate chain: (19) 而同一个主机的当前TLSA RR是这样报告的：
2, 0, 2 67274b3554289058[...]5fd3917510e6722a
报告的第一个logging是指新的根CA. 第二个是指原始颁发的CA（由原始根CA签名）。
当我self signed certificate in certificate chain: (19)检查消息self signed certificate in certificate chain: (19)我形成的印象是这是一个错误。 但是，如果这是一个错误，那么CA Root公钥在什么地方适合DANEscheme呢？
我通过实验发现的是：
如果将根和发布的CA TLSA RR放在DNS转发区，则上面报告的错误消失。 例如：
鉴于这个主机RR：
_443._tcp.inet04.hamilton.harte-lyne.ca. 300 IN CNAME _tlsa._dane.trust.harte-lyne.ca.
如果只有以下logging存在于前向区域中的自签名根CA，那么我们会看到原始问题中报告的错误（或警告我不确定它是哪个）：
;# CA_HLL_ROOT_2016 public key hashed sha512 Trust Anchor (active) _tlsa._dane.trust.harte-lyne.ca. 300 IN TLSA ( 2 1 2 c26e0ec16a46a97386e8f31f8ecc971f2d73136aa377dfdaac2b2b00f7cab4bb29b 17d913c82093b41fd0d9e40b66a68361c126f1f4017f9ce60eabc5adba90e )
检查这个testing网站：
https://dane.sys4.de/smtp/inet04.hamilton.harte-lyne.ca
产生这个错误或警告：
Usable TLSA Records 2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e - self signed certificate in certificate chain: (19)
但是，如果将以下TLSA RR添加到由根CA签署的发证CA以及自签名根CA中; 主机RR保持不变; 那么两个TLSA RR报告可用，没有任何错误或警告消息：
;# CA_HLL_ISSUER_2016 public key hashed sha512 Trust Anchor (active) _tlsa._dane.trust.harte-lyne.ca. 300 IN TLSA ( 2 1 2 380259229e21a1946b38cfc594cbc993b61bc93762b7b6c6637b3eef9c5a2bb70c5 89b91beb73bd1304eac11b3917e33819e2b47d25d4966435a2a3e83c1f80f )
TTL到期后访问testing网站：
https://dane.sys4.de/smtp/inet04.hamilton.harte-lyne.ca
给出这个：
Usable TLSA Records 2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e 2, 1, 2 380259229e21a194[...]435a2a3e83c1f80f
推断是自签名证书“可能”有效但不可信，而完整的证书链既有效又可信。
尽pipe如此，我还是希望能够解释这个过程的机制。