DANE（DNS-based Authentication of Named Entities）

概要

DANE（DNS-based Authentication of Named Entities） は、DNSSEC で保護された DNS に TLSA レコードとして証明書情報を公開し、クライアントが CA のトラストモデルに依存せずに証明書を検証できるようにする仕組みです。RFC 6698（2012 年）で定義され、RFC 7671（2015 年）で運用上のガイダンスが追加されました。

従来の PKI モデルでは、ブラウザーのトラストストアに含まれる数百の CA のうち、どの CA でも任意のドメインに対して証明書を発行できます。2011 年の DigiNotar 事件では、侵害された CA が google.com の不正証明書を発行し、中間者攻撃が可能になりました。CAA レコードは CA に対する発行制限を求めるものですが、CA がチェックを怠れば機能しません。

DANE はこの問題を DNS 層で解決します。ドメインオーナーが TLSA レコードに「どの証明書（または CA）が正当か」を宣言し、クライアントはその DNS レコードを DNSSEC で検証することで、CA のトラストストアに依存しない証明書確認を実現します。

DANE は SMTP での採用が進んでいます。RFC 7672（2015 年）が SMTP における DANE の利用を定義しており、Postfix、Exim、Gmail、Microsoft 365 などが DANE に対応しています。一方、ウェブブラウザーでの採用はほとんど進んでいません。Chrome と Firefox はいずれも DANE をネイティブにサポートしていません。

仕組み

DANE は TLSA レコードに証明書のハッシュや公開鍵を宣言し、DNSSEC の署名検証を通じて証明書の正当性を確認します。

TLSA レコード

DANE は DNS の TLSA レコードタイプ（タイプ番号 52）を使用します。TLSA レコードは _port._protocol.hostname の形式で設定します。

_443._tcp.example.com. IN TLSA 3 1 1 E1B8...（SHA-256 ハッシュ）

TLSA レコードのフィールドは次の 4 つです。

Certificate Usage（最初の数字）は、証明書のマッチング対象を指定します。

• 0（PKIX-TA）— 証明書チェーンのトラストアンカー（CA 証明書）に一致し、かつ PKIX 検証を行う
• 1（PKIX-EE）— エンドエンティティ証明書に一致し、かつ PKIX 検証を行う
• 2（DANE-TA）— トラストアンカーに一致するが、PKIX 検証は不要
• 3（DANE-EE）— エンドエンティティ証明書に一致するが、PKIX 検証は不要。自己署名証明書でも可

Selector（2 番目の数字）は、証明書のどの部分をマッチングに使うかを指定します。

• 0 — 証明書全体（Full certificate）
• 1 — 公開鍵のみ（SubjectPublicKeyInfo）

Matching Type（3 番目の数字）は、マッチングの方法を指定します。

• 0 — 完全一致（証明書データそのもの）
• 1 — SHA-256 ハッシュ
• 2 — SHA-512 ハッシュ

実運用では 3 1 1（DANE-EE、公開鍵、SHA-256）の組み合わせが最も広く使われています。DANE-EE は CA 証明書に依存せず、公開鍵の SHA-256 ハッシュは証明書の更新時にも鍵を再利用すれば TLSA レコードを変更する必要がありません。

DANE と DNSSEC の関係

DANE は DNSSEC が前提です。TLSA レコードが DNSSEC で署名されていない場合、攻撃者が DNS 応答を改ざんして偽の TLSA レコードを注入できるため、DANE のセキュリティモデルが崩壊します。

DANE を導入するには、ドメインのゾーン全体に DNSSEC を設定する必要があります。親ゾーンへの DS レコードの登録、ZSK と KSK の鍵管理、署名の定期更新が求められます。

SMTP での DANE

RFC 7672 は SMTP での DANE 利用を定義しています。メールサーバー間の通信で STARTTLS が使われる際、DANE は次のように機能します。

1. 送信側 MTA が受信ドメインの MX レコードを DNSSEC 付きで解決する
2. MX のホスト名に対する TLSA レコードを DNSSEC 付きで問い合わせる
3. TLSA レコードが存在すれば、STARTTLS を必須とし、受信サーバーの証明書を TLSA レコードと照合する
4. 一致しなければ配送を拒否する

DANE を使うと、SMTP STARTTLS の日和見暗号化（opportunistic encryption）を強制暗号化に格上げできます。通常の STARTTLS は暗号化なしにフォールバックする可能性がありますが、DANE が有効な場合は証明書検証に失敗するとメール配送を中止します。

設定例

TLSA レコード用のハッシュ生成から DNS 設定、Postfix での DANE 送信設定までを示します。

TLSA レコードの生成

サーバー証明書の公開鍵から TLSA レコード用のハッシュを生成するには次のコマンドを使います。

openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -hex

(stdin)= e1b8a5f3...（SHA-256 ハッシュ値）

生成したハッシュを DNS に設定します。

_443._tcp.example.com.  IN  TLSA  3 1 1 e1b8a5f3...
_25._tcp.mail.example.com.  IN  TLSA  3 1 1 e1b8a5f3...

Postfix での DANE 送信側設定

# main.cf
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtp_tls_dane_insecure_mx_policy = dane

smtp_tls_security_level = dane を設定すると、Postfix は送信先の TLSA レコードを確認し、存在すれば DANE 検証を行います。TLSA レコードが存在しないドメインには通常の日和見暗号化でフォールバックします。

確認方法

dig で TLSA レコードを確認するには次のコマンドを使います。

dig TLSA _443._tcp.example.com +short

3 1 1 E1B8A5F3...

TLSA レコードの DNSSEC 検証状態を確認するには +dnssec フラグを追加します。

dig TLSA _443._tcp.example.com +dnssec +short

ad フラグ（Authenticated Data）がレスポンスに含まれていれば、DNSSEC 検証が成功しています。

SMTP の DANE 対応を確認するには次のコマンドを使います。

dig TLSA _25._tcp.mail.example.com +short

外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。TLSA レコードタイプは直接サポートされていませんが、ドメインの基本的な DNS 設定を確認する際に有用です。

curl "https://labee.dev/api/dns?domain=example.com&type=MX"

{
  "success": true,
  "data": {
    "domain": "example.com",
    "records": {
      "MX": [
        { "priority": 10, "exchange": "mail.example.com" }
      ]
    }
  },
  "error": null,
  "meta": { "responseTime": 123 }
}

MX レコードが正しく設定されていることを確認した上で、TLSA レコードの設定を dig で検証する流れになります。

よくある問題

DANE の導入・運用で発生しやすいトラブルは、DNSSEC の前提条件と証明書更新の連携に集中しています。

DNSSEC が未設定で DANE が機能しない

DANE は DNSSEC が前提です。TLSA レコードを設定しても、ドメインの DNSSEC が有効になっていなければ、DANE 対応クライアントは TLSA レコードを信頼しません。親ゾーンへの DS レコードの登録が漏れているケースが多く見られます。

証明書更新時の TLSA レコード更新漏れ

証明書を更新した際に公開鍵が変わると、TLSA レコードのハッシュ値も更新する必要があります。Let’s Encrypt のような自動更新環境では、証明書更新のタイミングで TLSA レコードの更新を自動化するスクリプトが必要です。更新漏れが発生すると、DANE 対応の送信サーバーがメール配送を拒否します。

公開鍵を再利用する（CSR に同じ鍵を使う）方法で TLSA レコードの更新を不要にできますが、鍵漏洩時のリスクが高くなります。

ブラウザーが DANE に対応していない

Chrome と Firefox はいずれも DANE のネイティブサポートを実装していません。ウェブブラウジングにおける DANE の利用は、ブラウザー拡張に限定されます。DANE は主に SMTP（メールサーバー間通信）で実用的な価値を発揮しています。