DANEとは何ですか？

DANE（DNS-Based Authentication of Named Entities）は、DNSのTLSAレコードを使用してTLS証明書を検証するプロトコルです。RFC 6698/7671で標準化され、DNSSECと組み合わせて証明書の信頼性をDNS経由で保証します。認証局（CA）への依存を減らし、メールサーバー間のTLS通信を強化します。

DANEの利点は何ですか？

①CA（認証局）への依存を削減し、不正な証明書発行リスクを軽減②SMTP通信でのTLS暗号化を確実に適用（ダウングレード攻撃防止）③自己署名証明書でも信頼性を確保可能④DNS経由で証明書情報を公開するため設定が透明です。DNSSEC対応が前提条件となります。

DANEとMTA-STSの違いは？

DANEはDNSSECベースでTLSAレコードにより証明書を検証、MTA-STSはHTTPSベースでポリシーファイルによりTLS必須を宣言します。DANEはより強力ですがDNSSEC必須、MTA-STSは導入が容易です。両方の併用が推奨されます。

DANE（DNS-Based Authentication of Named Entities） | 用語集

Q: DANE-TAとDANE-EEの違いは何ですか？

DANE-TA（Usage 2）はCA証明書やLet's Encryptの中間証明書を指定し、そのCAが発行した証明書を信頼します。DANE-EE（Usage 3）はサーバー証明書自体の公開鍵ハッシュを直接指定し、CAの判断を経由せず検証します。SMTP向けにはEE方式（3 1 1）が一般的に使われます。

Q: 証明書を更新するとメールが届かなくなることはありますか？

TLSAレコードの更新を忘れたまま証明書だけ更新すると、DANE検証に失敗してTLS接続が拒否され、送信側MTAによってはメールが遅延・バウンスすることがあります。Let's EncryptのようにACME経由で証明書を自動更新する構成では、TLSAレコードも自動更新するスクリプトやDANE対応ツールを併用するのが定石です。

Q: 自社ドメインがDNSSECに対応していない場合はどうすればよいですか？

DNSSECはDANEの前提条件のため、対応していないドメインではDANEを利用できません。まずレジストラやDNSホスティング側でDNSSEC署名を有効化する必要があります。DNSSEC対応が難しい場合は、暫定的にMTA-STSやSTARTTLSの強制設定で暗号化を担保する方法もあります。

この用語をシェア

Facebook X (Twitter)

DANEとは

DANE（DNS-Based Authentication of Named Entities）は、RFC 6698（および運用上の詳細を定めたRFC 7671）で標準化された、DNSベースのTLS証明書検証技術です。DNSSEC署名されたTLSAレコードをDNSに登録することで、従来のCA（認証局）に依存しない証明書検証を実現します。

名前の由来は「Named Entities（名前を持つ実体）」を「DNSベースで認証する」という発想にあります。もともとはWebブラウザのHTTPS通信も視野に入れて設計されましたが、ブラウザベンダー各社がDANEの採用を見送ったこともあり、実際に広く使われているのはSMTP（メールサーバー間通信）向けのDANE for SMTP（RFC 7672）です。本記事では特にメールサーバー運用の観点からDANEを解説します。

混同されがちですが、DANEは証明書そのものを発行する仕組みではなく、「この証明書（またはこの公開鍵）を信頼してよい」という情報をDNS経由で宣言する仕組みです。証明書の発行自体は引き続きLet's EncryptなどのCAや自己署名証明書が担い、DANEはその検証ルートにDNSSECという第二の信頼の連鎖を追加する位置づけになります。

DANEの仕組み

DNSSECとの関係が前提になる理由

DANEの安全性は100%DNSSECに依存しています。DNSSECが署名していないゾーンでTLSAレコードだけを公開しても、攻撃者がDNS応答を偽装してTLSAレコード自体を差し替えられるため、検証の意味がありません。逆にいえば、DNSSECで署名済みのゾーンであれば、TLSAレコードの真正性はDNSSECの署名チェーン（ゾーン鍵→親ゾーンのDSレコード→ルートゾーン）によって保証されるため、追加の第三者機関（CA）を介さずに証明書の正当性を確認できます。SMTP送信側のMTAは、DNSSEC検証に対応したフルリゾルバ（Unbound、BINDのDNSSEC検証機能など）を経由してTLSAレコードを取得し、AD（Authenticated Data）ビットが立っていることを確認したうえでDANE検証を行います。

TLSAレコードの4フィールド構成

TLSAレコードは「Certificate Usage」「Selector」「Matching Type」「Association Data（証明書ハッシュ）」の4フィールドで構成されます。

_25._tcp.mail.example.com. IN TLSA 3 1 1 (
  a1b2c3d4e5f6... # 証明書フィンガープリント（SHA-256）
)

フィールド	代表的な値	意味
Certificate Usage	0（PKIX-TA）/ 1（PKIX-EE）/ 2（DANE-TA）/ 3（DANE-EE）	CA検証を併用するか、DNSのみで完結させるかを指定。SMTPでは3（DANE-EE）が主流
Selector	0（Full Certificate）/ 1（SubjectPublicKeyInfo）	証明書全体をハッシュ化するか、公開鍵部分のみをハッシュ化するか
Matching Type	0（Exact）/ 1（SHA-256）/ 2（SHA-512）	ハッシュアルゴリズム。実運用ではSHA-256（値1）が一般的
Association Data	16進数文字列	上記アルゴリズムで計算した証明書または公開鍵のハッシュ値そのもの

SMTP接続確立時の検証フロー

送信側MTA（例：Postfix）が受信側にメールを配送する際、DANEは概ね次の順序で検証されます。

送信側MTAが受信ドメインのMXレコードを解決し、DNSSEC検証つきでAレコード/AAAAレコードを取得
MX先ホスト名に対応する_ポート._tcp.ホスト名形式のTLSAレコードをDNSSEC検証つきで取得（例：_25._tcp.mail.example.com）
STARTTLSでTLSセッションを開始し、受信側から提示された証明書を取得
取得した証明書（またはその公開鍵）のハッシュを計算し、TLSAレコードのAssociation Dataと一致するか照合
一致すれば接続を信頼して通信を継続、不一致であればsmtp_tls_security_level = dane設定下では接続を拒否またはキューに保持

DANE-TAとDANE-EEの使い分け

Certificate Usage 2（DANE-TA）は「このCA（Trust Anchor）が発行した証明書のみ信頼する」という指定で、CA自体の判断は引き続き必要です。一方Usage 3（DANE-EE：End Entity）はサーバー証明書そのものの公開鍵ハッシュを直接指定するため、CAの判断を完全にバイパスします。Let's Encryptのように90日ごとに証明書が自動更新される運用ではEE方式が扱いやすく、実運用でも「3 1 1」の組み合わせが最も多く採用されています。

具体例・ユースケース

dig でTLSAレコードを確認する

DANE対応済みのドメインかどうかは、以下のようにdigコマンドで確認できます。DNSSEC検証が通っているかは応答フラグのad（Authenticated Data）で判断します。

# TLSAレコードとDNSSEC検証状態を確認
dig +dnssec TLSA _25._tcp.mail.example.com

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1
_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 a1b2c3d4e5f6...

posttls-finger でPostfixから疎通確認する

Postfix付属のposttls-fingerコマンドを使うと、実際にDANE検証を伴うSTARTTLS接続を試行し、TLSAレコードとの照合結果をログで確認できます。

# DANEモードで対向ホストへTLS接続を試行
posttls-finger -c -l dane mail.example.com

# ログ出力例（成功時）
Verified TLS connection established to mail.example.com[203.0.113.10]:25:
  TLSv1.3 with cipher TLS_AES_256_GCM_SHA384

証明書更新運用でのシナリオ

典型的な失敗パターンとして、Let's Encryptの証明書更新（certbot renew）がcronで自動化されている一方、TLSAレコードの更新が手動運用のまま放置されているケースがあります。証明書の公開鍵が更新されるとTLSAレコードのハッシュ値と一致しなくなり、DANE検証に失敗して送信側からのメールが拒否・遅延する事態につながります。運用上は、certbotのdeploy-hookに「新しい公開鍵からTLSAレコード用ハッシュを再計算してDNSに反映する」スクリプトを組み込み、証明書更新とTLSAレコード更新を同一トリガーで実行するのが定石です。また、切り替え時の失敗を避けるため、旧証明書用と新証明書用の2つのTLSAレコードを一時的に併存させておく（ロールオーバー方式）運用も広く行われています。

DANEのメリットとデメリット

メリット

CA依存の低減: 証明書の信頼判断をCAだけに委ねず、DNSSECという別系統の信頼チェーンで裏付けられる
ダウングレード攻撃・中間者攻撃への耐性: STARTTLSのネゴシエーションを中間者が妨害しても、DANEポリシーが有効な限り平文フォールバックを許さない設定にできる
自己署名証明書でも信頼性を確保可能: DANE-EE方式なら第三者CAを介さず、自己署名証明書でも安全にTLS通信を確立できる
透明性の高い運用: 証明書ポリシーがDNSという公開情報として確認できるため、監査や第三者検証がしやすい

デメリット・注意点

DNSSEC導入の複雑さ: レジストラやDNSホスティング事業者がDNSSECに対応している必要があり、鍵管理（ZSK/KSKのロールオーバー）の運用負荷が発生する
TLSAレコード更新忘れのリスク: 証明書更新の都度TLSAレコードを追随させないと、正規の証明書更新なのにDANE検証エラーでメールが届かなくなる
送信側の対応状況に依存: 受信側でDANEを設定しても、送信側MTAがDANE検証に対応していなければ効果を発揮しない（主要な対応例はPostfix、Exim。一部クラウド型メールサービスは非対応）
DNSキャッシュ・TTLとの兼ね合い: TLSAレコード更新直後は古いレコードがキャッシュされている可能性があり、反映までにTTL分のタイムラグが生じる

混同されやすい用語・類似技術との違い

DANEはDNSSECやMTA-STSなど、名前や目的が似た技術と混同されやすいため、それぞれの役割の違いを整理します。

技術	検証の起点	DNSSEC必須	主な用途
DANE（TLSA）	DNSのTLSAレコード	必須	SMTP等の証明書検証をDNS経由で行う
DNSSEC単体	DNS応答自体の署名検証	（それ自体がDNSSEC）	DNS応答の改ざん・偽装防止全般。DANEの前提基盤
MTA-STS	HTTPS経由のポリシーファイル	不要	SMTP TLS必須化の宣言。DANEより導入は容易だが検証はやや弱い
CAA（Certification Authority Authorization）	DNSのCAAレコード	推奨だが必須ではない	どのCAが証明書を発行してよいかを制限。証明書の「発行時」の制御であり、DANEのような「接続時」の検証ではない
HPKP（廃止済み）	HTTPレスポンスヘッダ	不要	Webブラウザ向けの公開鍵ピン留め。運用リスクが高く主要ブラウザで廃止済み。DANEとは別系統の技術

特に混同されやすいのはDANEとMTA-STSです。両者はどちらも「SMTP通信でTLSを強制し、ダウングレード攻撃を防ぐ」という目的は共通していますが、信頼の根拠がDNSSEC（DANE）かHTTPS＋DNS上のポリシーファイル（MTA-STS）かという点で設計思想が異なります。実務では、DNSSEC対応済みのドメインではDANEを主軸にしつつ、DNSSEC未対応の相手先や過渡期の保険としてMTA-STSを併用する構成が一般的です。

自社メールサーバー運用への応用

前提条件

DNSSEC有効化: ドメインでDNSSECが有効であること（レジストラまたはDNSホスティング事業者の管理画面で有効化し、上位ゾーンへDSレコードが登録されていることを確認）
TLS証明書: 有効なTLS証明書（Let's Encryptなどの無料証明書でも可）
権威DNSサーバーのTLSAレコード対応: 利用しているDNSホスティングサービスがTLSAレコードのゾーン登録に対応していること（主要な国内外のDNSホスティングサービスは対応が進んでいるが、事前に確認しておくと安全）

なお、DNSSECの有効化はドメインのレジストラ側と権威DNS側の双方の設定が必要になる場合があります。自社でDNSサーバーを運用している場合はゾーン署名鍵（ZSK）・鍵署名鍵（KSK）の生成と定期的なロールオーバー運用も必要になるため、社内にDNSSEC運用の知見がない場合は、DNSSEC対応済みのマネージドDNSサービスに委任する構成の方が運用負荷を抑えられます。

TLSAレコード生成

# 証明書からTLSAレコードを生成
openssl x509 -in /etc/letsencrypt/live/mail.example.com/cert.pem -pubkey -noout | \
openssl pkey -pubin -outform DER | \
openssl dgst -sha256 -binary | \
xxd -p -u -c 32

# DNSに登録（例）
_25._tcp.mail.example.com. IN TLSA 3 1 1 A1B2C3D4E5F6...

Postfixでの設定

# main.cf - 送信側（他ドメイン宛のDANE検証）を有効化
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

# tls_policy（特定ドメインのみ強制したい場合）
example.com dane

# main.cf - 受信側（自ドメインの証明書提示）はSTARTTLSの通常設定でよい
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtpd_tls_security_level = may

DANEはあくまで「送信側が相手のTLSAレコードを検証する」仕組みなので、Postfixのsmtp_*系パラメータ（送信）とsmtpd_*系パラメータ（受信）の役割を混同しないよう注意が必要です。DovecotはメールボックスへのIMAP/POPアクセスを担うため、SMTP間通信を検証するDANEとは直接関係しませんが、Dovecotが提示するTLS証明書とPostfixが提示するTLS証明書を同一のものに統一しておくと、証明書更新・TLSAレコード更新の運用を一本化しやすくなります。

運用チェックリスト

ドメインのDNSSECが有効か（レジストラの管理画面またはdigのadフラグで確認）
証明書更新の自動化（certbot renewなど）とTLSAレコード更新スクリプトが同じタイミングで動くようになっているか
本番反映前にposttls-fingerやdane.sys4.deなどの検証ツールでTLSAレコードの整合性を確認したか
DNSのTTLを短めに設定し、証明書切り替え時の反映遅延を許容範囲に収めているか
誤設定時の影響範囲を抑えるため、まずsmtp_tls_security_level = mayで様子を見てからdaneに切り替えているか

導入効果

メール送信のセキュリティ向上: TLS接続の信頼性確保
中間者攻撃防止: 不正な証明書の検知
暗号化強制: DANE対応ドメインへの暗号化送信

まとめ

DANEは、DNSベースで証明書を検証する先進的な技術です。自社メールサーバーでDANEを導入するには、DNSSEC有効化とTLSAレコード登録が必要です。導入により、メール送信のセキュリティが大幅に向上し、中間者攻撃・ダウングレード攻撃のリスクを軽減できます。一方で、DNSSECの運用負荷や証明書更新時のTLSAレコード追随忘れといった運用上の落とし穴もあるため、導入前にはPostfixのsmtp_tls_security_level = mayでの試験運用や、posttls-fingerによる疎通確認を経て段階的にdaneモードへ移行することが望ましいでしょう。MTA-STSとの併用も含め、自社の受信・送信双方のドメインでどこまで強制するかを設計してから導入するのが実務上の定石です。

2025-2026年の最新動向

DANEの採用拡大が続いています。ドイツ、オランダなど欧州を中心にDANE対応メールサーバーが増加し、DNSSEC署名ドメインの増加とともにDANEの実用性が高まっています。

DANE + MTA-STSの併用が推奨パターンとなっています。DANEはDNSSEC対応環境で最強のTLS検証を提供し、MTA-STSはDNSSEC未対応環境でのフォールバックとして機能します。

Let's EncryptとDANEの統合が容易になり、自動証明書更新とTLSAレコードの自動更新を組み合わせた運用が普及しています。certbotのDANEプラグインやスクリプトによる自動化が進んでいます。

マネージドDNSサービスのDNSSEC対応拡大も追い風になっています。Cloudflare、AWS Route 53、さくらのクラウド DNSなど主要なDNSホスティングサービスの多くがDNSSEC署名とTLSAレコード登録に対応しており、以前に比べて自社でDNSSECの鍵管理を持たずにDANEを導入するハードルは下がってきています。ただし、DNSSECの有効化そのものはドメインごとの手動作業が必要な場合が多く、大量のドメインを一括運用している組織では導入の優先順位付けが引き続き課題になっています。

外部リンク

よくある質問（FAQ）

Q. DANEとは？

DNSのTLSAレコードでTLS証明書を検証するプロトコルです。DNSSECと組み合わせてCA依存を減らし、メール通信のセキュリティを強化します。

Q. DANEの利点は？

CA依存の削減、ダウングレード攻撃防止、自己署名証明書の信頼性確保が主な利点です。DNSSEC対応が前提条件です。

Q. MTA-STSとの違いは？

DANEはDNSSECベース、MTA-STSはHTTPSベースです。DANEはより強力ですがDNSSEC必須、MTA-STSは導入が容易です。両方の併用が推奨されます。

Q. DANE-TAとDANE-EEの違いは何ですか？

DANE-TA（Usage 2）はCA証明書を信頼の起点として指定し、DANE-EE（Usage 3）はサーバー証明書自体の公開鍵ハッシュを直接指定します。SMTP向けにはCAの判断を経由しないDANE-EE（「3 1 1」）が広く使われています。

Q. 証明書を更新するとメールが届かなくなることはありますか？

TLSAレコードの更新を忘れたまま証明書だけ更新すると、DANE検証に失敗してメールが遅延・拒否される可能性があります。証明書自動更新のフックにTLSAレコード更新スクリプトを組み込むのが定石です。

Q. 自社ドメインがDNSSECに対応していない場合はどうすればよいですか？

DNSSECはDANEの前提条件のため、未対応の場合はまずレジストラ側でDNSSEC署名を有効化する必要があります。対応が難しい間は、MTA-STSやSTARTTLS強制設定で暫定的に暗号化を担保する方法もあります。

Q. DANEはWebサーバー（HTTPS）でも使えますか？

仕様上はHTTPSでも利用可能ですが、主要なWebブラウザがDANE検証をサポートしていないため、実質的にはSMTPをはじめとするサーバー間通信（メール、XMPPなど）での利用が中心です。ブラウザ向けの証明書検証はCertificate TransparencyやHSTSなど別の仕組みが主流になっています。

この用語についてもっと詳しく

DANEに関するご質問や、メールサーバー構築のご相談など、お気軽にお問い合わせください。

お問い合わせサービス一覧

DANE（DNS-Based Authentication of Named Entities）