TLSA レコード

概要

TLSA レコード は、TLS 接続で使用する証明書やその公開鍵の情報を DNS に公開するためのレコードです。RFC 6698（2012年）で定義されており、レコードタイプ番号は 52 です。DANE（DNS-Based Authentication of Named Entities）プロトコルの基盤となるレコードで、DNSSEC による署名と組み合わせて使用します。

従来の TLS 証明書検証は、ブラウザーやクライアントに組み込まれた数百のルート認証局（Root CA）の信頼に依存しています。TLSA レコードを使うと、ドメイン管理者が「このサーバーではこの証明書（またはこの公開鍵）を使う」と DNS 上で宣言でき、認証局の信頼モデルに依存しない、あるいは補完する証明書検証が可能になります。

仕組み

TLSA レコードは Certificate Usage、Selector、Matching Type の 3 つのフィールドで検証モデルと照合方法を指定します。

レコードの構造

TLSA レコードのオーナー名はポート番号とプロトコルを含む形式です。

_443._tcp.example.com.  IN  TLSA  3 1 1 2bb183af2b8cb5e...

フィールド	説明
_port	ポート番号（アンダースコア付き）
_proto	プロトコル。通常は _tcp
Certificate Usage	証明書の使い方を指定する番号（0〜3）
Selector	証明書のどの部分を照合するか（0 または 1）
Matching Type	照合データの形式（0、1、2）
Certificate Association Data	照合に使う証明書データまたはハッシュ（16 進数表記）

Certificate Usage（用途）

Certificate Usage フィールドは TLSA レコードの検証モデルを決定します。

値	名称	説明
0	PKIX-TA	指定した CA 証明書が信頼アンカーであり、かつ通常の PKIX（認証局チェーン）検証も行う
1	PKIX-EE	指定した証明書がサーバー証明書と一致し、かつ PKIX 検証も行う
2	DANE-TA	指定した CA 証明書を信頼アンカーとして使う。パブリック CA の信頼リストは不要
3	DANE-EE	指定した証明書がサーバー証明書と直接一致すればよい。CA チェーンの検証をスキップする

最も広く使われているのは Usage 3（DANE-EE）です。自己署名証明書でもパブリック CA に依存せずに検証でき、証明書の有効期限チェックも不要です（RFC 7671 Section 5.1）。

Selector と Matching Type

Selector は照合対象を選びます。

値	対象
0	証明書全体（DER エンコード）
1	SubjectPublicKeyInfo（公開鍵部分のみ）

Matching Type は照合データの形式を指定します。

値	形式
0	生データ（ハッシュなし）
1	SHA-256 ハッシュ
2	SHA-512 ハッシュ

実運用では Selector 1（公開鍵）+ Matching Type 1（SHA-256）の組み合わせが推奨されます。証明書を更新しても同じ鍵ペアを使う限り TLSA レコードの変更が不要になるためです。

DANE for SMTP（RFC 7672）

TLSA レコードの最大の導入実績はメールサーバー間通信（SMTP）です。RFC 7672（2015年）では DANE を使って SMTP サーバー間の TLS 接続を検証する仕組みが標準化されています。

STARTTLS による SMTP の暗号化は、通常は日和見暗号化（Opportunistic TLS）であり、中間者攻撃による暗号化のダウングレードを防げません。DANE for SMTP では、送信側 MTA が受信側ドメインの MX レコードを引き、その MX ホストの TLSA レコードを DNSSEC 検証付きで取得します。TLSA レコードが存在し DNSSEC で検証できた場合、TLS 接続が必須になり、証明書も TLSA レコードと照合されます。

設定例

DANE-EE（Usage 3）と公開鍵 SHA-256 の組み合わせが最も広く使われている構成です。

DANE-EE + 公開鍵 SHA-256（推奨構成）

_443._tcp.example.com.  IN  TLSA  3 1 1 (
    2bb183af2b8cb5e15f95b8c3a544f6b3
    07aabdbc2f82ace3b0d2e0e0a7d5c8f1 )

Usage 3（DANE-EE）、Selector 1（公開鍵）、Matching Type 1（SHA-256）の構成です。

SMTP サーバーの TLSA レコード

_25._tcp.mail.example.com.  IN  TLSA  3 1 1 (
    a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6
    e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2 )

ポート 25（SMTP）の TLSA レコードです。MX レコードが mail.example.com を指している場合、このホスト名に対して TLSA レコードを設定します。

証明書ローテーション用の複数 TLSA レコード

証明書を更新する前に、新旧両方の証明書に対応する TLSA レコードを設定しておきます。

_443._tcp.example.com.  IN  TLSA  3 1 1 (
    2bb183af2b8cb5e15f95b8c3a544f6b3
    07aabdbc2f82ace3b0d2e0e0a7d5c8f1 )
_443._tcp.example.com.  IN  TLSA  3 1 1 (
    c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9
    0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5 )

確認方法

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

dig TLSA _443._tcp.example.com

出力の ANSWER SECTION に Certificate Usage、Selector、Matching Type、ハッシュ値が表示されます。

;; ANSWER SECTION:
_443._tcp.example.com.  3600  IN  TLSA  3 1 1 2BB183AF2B8CB5E1...

DNSSEC の署名状態も合わせて確認するには +dnssec オプションを付けます。

dig TLSA _443._tcp.example.com +dnssec

RRSIG が返り、AD（Authentic Data）フラグが設定されていれば DNSSEC 検証が成功しています。

サーバーの実際の証明書から TLSA レコードの値を計算するには openssl を使います。

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256

出力されるハッシュ値が TLSA レコードの Certificate Association Data と一致していれば正しく設定されています。

Labee Dev Toolbox の DNS API は現在 TLSA レコードタイプに対応していないため、dig コマンドで確認します。

よくある問題

TLSA レコードの運用では、DNSSEC の前提条件や証明書ローテーションとの連携が課題になります。

DNSSEC が有効でないドメインに TLSA レコードを設定している

TLSA レコードは DNSSEC による署名を前提としています。DNSSEC が無効なドメインでは、TLSA レコードが DNS 応答に含まれていてもクライアントは検証できません。DANE 対応クライアントは DNSSEC 未署名の TLSA レコードを無視します。TLSA レコードを設定する前に DNSSEC を有効化します。

証明書を更新したが TLSA レコードを更新していない

証明書の更新時に鍵ペアも変更した場合、TLSA レコードのハッシュ値が一致しなくなります。Selector 1（公開鍵）を使っていれば同じ鍵で証明書を再発行する限り問題ありませんが、鍵も更新する場合は TLSA レコードも事前に更新する必要があります。証明書更新前に新しい TLSA レコードを追加し、TTL 分だけ待ってから証明書を切り替え、その後古い TLSA レコードを削除するのが安全な手順です。

MX ホスト名と TLSA レコードのホスト名が一致しない

DANE for SMTP では、TLSA レコードは MX レコードが指すホスト名に対して設定します。example.com ではなく mail.example.com（MX の指す先）に _25._tcp.mail.example.com として設定する点を間違えやすいです。MX レコードのホスト名を dig MX example.com で確認してから TLSA レコードを設定します。

TLSA レコードの TTL が長すぎて証明書ローテーションに失敗する

TLSA レコードの TTL が長いと、新しい TLSA レコードがキャッシュに反映される前に証明書が切り替わり、検証が失敗する期間が発生します。TLSA レコードの TTL は 1 時間（3600 秒）以下 に設定し、証明書切り替えの少なくとも TTL × 2 の時間前に新しい TLSA レコードを追加します。