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）已率先推廣採用。