DANE/TLSAレコードチェッカー
ドメインのメールサーバー（MXホスト）が公開するTLSAレコードを複数の公開DNSリゾルバーへ問い合わせ、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レコードは通常のドメイン名ではなく、MXホストの `_25._tcp.{ホスト名}` という特殊な名前に配置されます。ドメイン名だけでTLSAを調べても見つからないのはこのためです。
- 「DANE未設定」は異常ではありません。DANEはメール暗号化の追加防御層で、多くのメールサーバーは今も導入していません。
- DANEはDNSSECの署名チェーンによって初めて信頼できる情報になります。TLSAレコードが見つかっても、そのドメインがDNSSECに対応していなければ、姉妹ツールの「DNSSEC検証チェッカー」も併せて確認しましょう。
- MXホストが複数ある場合、優先度（数値が小さいほど優先）が最も高いホストから最大3件までチェックします。
- リゾルバー間で結果が割れる場合、TLSAレコードを更新した直後でキャッシュが混在している可能性があります。しばらく待って再確認してください。
活用シーン
自社のメールサーバーを点検する
TLSA を置いたつもりが MX ホスト側に無い、という食い違いを見つけられます。
証明書の更新前に確認する
**更新の順序を誤るとメールが止まるため、事前の確認が効きます。**
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）を採用しており、攻撃者が中間者攻撃でSTARTTLSコマンドを消し去る「STRIPTLS攻撃」によって、暗号化を無効化されたまま気づかれずに通信を傍受されるリスクがありました。
DANE（DNS-based Authentication of Named Entities、RFC 6698）は、この問題への対策としてTLSAレコードをDNS上に公開する方式です。メールサーバーの証明書（またはその公開鍵ハッシュ）をあらかじめDNSに固定しておくことで、接続先が本当に想定通りの証明書を提示しているかを検証できます。認証局（CA）の証明書検証チェーンに依存せず、DNSSECによる署名チェーンだけを信頼の根拠にする点が、通常のSSL/TLS証明書検証との大きな違いです。
DANEの弱点は、これが機能するためにドメイン自体がDNSSECで署名されている必要があることです。DNSSEC未導入のドメインでは、TLSAレコード自体が改ざんされる可能性を排除できないため、DANEの保証は無意味になってしまいます。このためDANEの普及は、DNSSECの普及率に強く依存しており、欧州の一部レジストリ（.nl・.cz等）で先行して採用が進んでいます。