DNSのDANEについて

DANE とは、DNS-Based Authentication of Named Entities の略で、DNSSECで保護されたDNS情報を使って、特定のサービスで受け入れるべき証明書や公開鍵の情報を示す仕組みです。

簡単にいうと、通常のTLSでは「この証明書は認証局（CA）が正しいと認めているか」を中心に相手を検証しますが、DANEではそれに加えて、ドメイン管理者自身がDNS上で“この証明書や公開鍵を使う”と宣言できるようになります。

このとき中心になるのが TLSAレコード です。

DANEは、このTLSAレコードをDNSSECで改ざん不能な状態にしたうえで利用する技術だと考えると理解しやすくなります。

DANEは何のために使うのか

DANEの目的は、TLSの相手認証をより強固にすることです。

通常の公開鍵基盤（PKI）では、多数の認証局のどれかが証明書を発行できる構造になっています。

これは便利な一方で、どこかのCAで誤発行や事故が起きると、本来とは異なる証明書が正当なもののように見えてしまうリスクがあります。

DANEでは、ドメイン所有者がDNSSECを使って「このサービスでは、この証明書、あるいはこの公開鍵を正しいものとして扱う」と明示できます。

つまりDANEは、TLSの認証情報をCAだけに依存せず、DNSの信頼連鎖でも支える仕組みです。

DANEで使うTLSAレコード

DANEでは、DNSに TLSAレコード を登録します。

このレコードは、次のような名前に配置します。

_ポート番号._プロトコル.ホスト名

たとえば、mail.example.com の TCP 25番向けなら、次のようになります。

_25._tcp.mail.example.com

この名前のTLSAレコードに、「どの証明書または公開鍵を受け入れるか」という情報を登録します。

TLSAレコードの構造

TLSAレコードは、次の4つの要素で構成されます。

TLSA usage selector matching-type certificate-association-data

たとえば、次のような形です。

_25._tcp.mail.example.com. IN TLSA 3 1 1 <データ>

この4つには、それぞれ意味があります。

usage

usage は、そのTLSAレコードをどのような認証方式として解釈するかを示します。

主な値は次の4つです。

• 0 = PKIX-TA
  通常のPKIX検証を行いながら、特定のCA証明書を信頼アンカーとして使う方式
• 1 = PKIX-EE
  通常のPKIX検証を行いながら、特定のサーバー証明書と関連づける方式
• 2 = DANE-TA
  DNSSECで示した trust anchor を用いる方式
• 3 = DANE-EE
  DNSSECで示したサーバー証明書、またはその公開鍵そのものを使う方式

実務では、DANE-EE（3） が比較的わかりやすく、使いやすい方式としてよく取り上げられます。

selector

selector は、証明書のどの部分を照合対象にするかを示します。

• 0 = 証明書全体
• 1 = 公開鍵部分（SPKI）

公開鍵だけを対象にすると、証明書を更新しても同じ鍵を使う限りTLSAを変えずに済む場合があるため、運用上便利なことがあります。

matching type

matching type は、照合データをどの形式で記録するかを示します。

• 0 = 生データそのまま
• 1 = SHA-256
• 2 = SHA-512

一般的には、ハッシュ値で表現する方式が使いやすく、特に SHA-256 がよく使われます。

certificate association data

ここには、実際の証明書データ、公開鍵データ、またはそのハッシュ値が入ります。

つまり、TLSAレコードの中核となる実データ部分です。

DANEはどのように認証するのか

DANE対応のクライアントやメールサーバーは、接続先に対して次のような流れで確認を行います。

1. 対象ホストのTLSAレコードを取得する
2. そのDNS応答がDNSSECで正しく検証できるか確認する
3. TLSハンドシェイク中に相手が提示した証明書や公開鍵と、TLSAの内容を照合する
4. 一致していれば、TLSAのルールに従って認証を成立させる

ここで重要なのは、TLSAレコードがあるだけでは不十分だという点です。

DNSSECで保護されてはじめてDANEとして意味を持ちます。

もしDNSSECがなければ、途中でTLSAレコードを書き換えられる可能性があり、攻撃者が偽の認証情報を正しいように見せることができてしまいます。

DANE-EE（3）の重要ポイント

DANEを理解するうえで、特に重要なのが DANE-EE（3） です。

この方式では、TLSAレコードに一致する証明書または公開鍵が提示されれば、それを正当なものとして扱います。

つまり、通常のPKIXのように「どのCAが署名したか」を必須条件にしません。

このため、DANE-EEでは一般的なTLSの感覚とは少し違う点があります。

• 通常のPKIX検証に依存しない
• 証明書のホスト名一致確認に依存しない
• 証明書の有効期限そのものに依存しない

ここは誤解されやすい部分ですが、DANE-EEでは“証明書がCAモデル上で正しいか”よりも、“DNSSECで保護されたTLSAがその証明書や公開鍵を有効として示しているか”が重視されます。

つまり、信頼の中心が証明書そのものから、DNSSECで保護された認証情報へ移るわけです。

DANE-TA（2）の位置づけ

DANE-TA（2） は、DNS側で trust anchor を示す方式です。

考え方としては柔軟ですが、運用では少し注意が必要です。

DANE-TAでは、サーバー側が提示する証明書チェーンが、その trust anchor にたどれるように設計されている必要があります。

そのため、単純に「DNSにCAの情報を書けば終わり」というものではなく、証明書チェーンの提示や構成まで含めた運用設計が必要になります。

その意味で、概念上は便利でも、実際の運用ではDANE-EEのほうが理解しやすい場面が多いです。

DANEがよく使われる場面

DANEは仕様上、さまざまなTLSサービスで利用できますが、実際に代表的なのはSMTP です。

つまり、メールサーバー同士が通信するときのTLS保護で特に重要です。

送信側メールサーバーは、受信側ドメインのMX情報とTLSA情報をDNSSECで検証し、そのうえで受信側サーバーが提示する証明書を確認します。

これにより、次のような攻撃への耐性が高まります。

• 中間者攻撃
• STARTTLSダウングレード攻撃
• 偽証明書の利用

ここでよくある誤解が、「DANEはSMTPを完全な強制TLSにする技術なのか」という点です。

実際には、SMTP DANEは“単なるベストエフォートTLSよりも強い、ダウングレード耐性のある運用”として理解するのが適切です。

つまり、メール配送の安全性を大きく底上げする技術ではありますが、単純に「絶対TLS必須化」とだけ言い切ると少し雑になります。

DANEのメリット

DANEの主なメリットは、次の3点に集約できます。

まず、公開CAへの依存を減らせることです。

ドメイン管理者が自分で認証情報を表明できるため、CAの誤発行リスクに対する補強になります。

次に、証明書ピンニングに近いことができる点です。

特定の公開鍵や証明書をDNS側で明示できるため、「この鍵以外は受け入れない」という制御がしやすくなります。

さらに、SMTPとの相性がよい点も大きな利点です。

ブラウザのように統一的なクライアント実装に依存する世界ではなく、サーバー間通信として比較的整った運用ができるため、DANEの価値が出やすい分野です。

DANEの注意点と導入ハードル

一方で、DANEには導入の難しさもあります。

最大のハードルは、やはり DNSSECの運用が前提になることです。

DNSSECは、単にレコードを追加するだけではなく、鍵管理、署名、ロールオーバー、親ゾーンとのDS連携など、通常のDNS運用より一段高いレベルの管理が求められます。

また、証明書更新や鍵切り替え時には、TLSAレコードとの整合性を慎重に保つ必要があります。

証明書だけ更新してTLSAを変え忘れたり、逆にTLSAだけ先に変えたりすると、接続障害が発生する可能性があります。

さらに、DANEは仕様上HTTPSにも使えますが、一般的なWebブラウザで広く普及した仕組みではありません。

そのため、現実にはWeb全体よりも、SMTPのような特定用途での重要性が高い技術だといえます。

具体例

たとえば、mail.example.com の SMTP（25/tcp）に対して、DANE-EE・SPKI・SHA-256 を使う場合、TLSAレコードは概念的に次のようになります。

_25._tcp.mail.example.com. IN TLSA 3 1 1 <SPKIのSHA-256ハッシュ>

この意味は次の通りです。

• 3 = DANE-EE
• 1 = 公開鍵部分を照合
• 1 = SHA-256を使用
• 最後のデータ = 公開鍵のSHA-256ハッシュ

この構成では、サーバーが提示した証明書の公開鍵がTLSAに一致すれば、DANE-EEの条件を満たすことになります。

DANEをどう理解するとわかりやすいか

DANEは、単に「DNSに証明書情報を置く仕組み」とだけ覚えると少し足りません。

より正確には、「DNSSECで保護されたDNSを使って、そのサービスで受け入れるべきTLS認証情報を宣言する仕組み」です。

通常のTLSが“CAが正しいと言っているか”を中心に見るのに対し、DANEは“そのドメイン自身がDNSSEC付きDNSで何を正当と宣言しているか”を重視します。

この違いが、DANEの本質です。

まとめ

DANEは、DNSSECとTLSAレコードを使って、特定サービスのTLS認証情報をDNS側で表明する技術です。

公開CAに依存する通常のPKIモデルを補強し、場合によってはそれに強く依存しない認証方式も実現できます。

特にSMTPでは重要性が高く、メール配送におけるSTARTTLSの実効性を高め、中間者攻撃やダウングレード攻撃への耐性向上に役立ちます。

一方で、DNSSEC運用が前提になるため、導入には相応の知識と運用設計が必要です。

DANEをひとことで表すなら、「TLSの信頼を、CAだけでなくDNSSEC付きDNSにも持たせる仕組み」といえます。

以上、DNSのDANEについてでした。

最後までお読みいただき、ありがとうございました。