A TLSAレコード TLSサービスを証明書または公開鍵データに関連付けます。それはではありません TXTレコード、の代替品 MXレコード またはすべての送信者が使用している証拠 DANE。 SMTPの場合、関連する検出と強制の動作はRFC 7672で定義されています。
MXサービスのホスト名から始めます
参考文献: RFC 7672 §2.2, RFC 7672 §3.1.1, RFC 6698 §2.1.
TCP ポート 25 上のサービスの場合、 mx.example.com、従来の TLSA 所有者は _25._tcp.mx.example.com。表示されている From ドメインまたはゾーンの頂点から自動的に名前を取得するのではなく、実際のSMTP交換ホスト名から名前を取得します。導入で保護する予定のすべてのMXエンドポイントと、 DNSSEC 検出パスに沿ったステータス。
TLSA データ フィールドは証明書の使用法です。 セレクタ、一致するタイプと関連付けデータ。この単純な非エイリアスルートの場合、表示されている所有者で十分です。エイリアスには、 RFC 7672 §2.2 の認証された TLSA ベースドメインの処理が必要です。一般的に推奨されるSMTP DANEプロファイルは次のとおりです。 3 1 1: DANE-EE の使用法、SubjectPublicKeyInfo の選択、および SHA-256 の照合。これらの番号は意味のあるプロトコルの選択であり、任意の証明書テキストの一般的なプレフィックスではありません。 RFC 7672およびRFC 7671では、サポートされる使用法と運用上の考慮事項について説明します。サポートされていない組み合わせを展開レシピから除外します。
正確なバイトを導き出す
参考文献: RFC 6698 §2.1.2, RFC 6698 §2.1.3.
ローカル PEM 証明書ファイルの場合 証明書.pem、Bash シェルで最初に有効にします set -o パイプ失敗;再現可能な SPKI ダイジェスト パイプラインが作成されます。 openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256。すべての段階を成功させる必要があります。セレクター 1 が意図されている場合は、PEM テキスト、表示されたフィンガープリント、または証明書全体ではなく、DER 公開キー表現をハッシュします。
構築する _25._tcp.mx.example.com. 300 IN TLSA 3 1 1 HEXDIGEST、HEXDIGEST を実際のダイジェストに置き換えます。これはテンプレートであり、公開可能なレコードではありません。制御されたネットワークを通じて、目的のSMTPエンドポイントによって提示された証明書を取得します。 STARTTLS 選択されたバイトを検査して比較します。ローカル ファイルは、サーバーが実際に提供する証明書とは異なる場合があります。
古い関連付けを廃止する前にキーの変更をテストする
参考文献: RFC 7672 §4, RFC 7671 §8.
合成フィクスチャ A は、キー A と A から派生した TLSA アソシエーションを持つテスト証明書を使用します。予期されたバイト比較は一致します。フィクスチャ B は、A の関連付けのみを保持しながら、キー B を持つ証明書を提供します。予想される比較は不一致です。フィクスチャ C は、計画された移行に対して許容可能な関連付けを両方公開し、A をリタイアする前に、意図したエンドポイントを B に対して検証します。
タイミングは、キャッシュされた TLSA データとすべてのアクティブなサーバー インスタンスを考慮する必要があります。同じ公開鍵を使用して更新された証明書は同じ状態を維持できます 3 1 1 新しいキーによって関連付けが変更されます。ダイジェスト比較の成功はローカル暗号化チェックであり、 SMTP DANE相互運用性の結果ではありません。ライブDNSSECとSMTPテストは依然として別個の証拠要件のままです。
ダッシュボードのラベルではなくトランスポートを確認する
参考文献: RFC 7672 §2.2, RFC 7672 §3.
DNSSEC 検証パスを使用して使用可能な TLSA データを確立し、実際のSMTPハンドシェイクと DANE 対応実装との関連付けをテストします。 DNS応答、検証トレース、証明書チェーン、選択した関連付け、送信者の結果を保存します。サポートする送信者は、失敗した必要なDANE認証を安全な配信の成功として黙って処理すべきではありません。ユニバーサルトランスポート保護を主張しないでください。送信者のサポートと正確な認証された検出結果が重要です。
観察された関連付けと検出のチェック
参考文献: RFC 4035 §5.
保持されている 2026 年 11 月 7 日の署名付きフィクスチャは、検査はされましたが、このレビューでは再実行されず、固定された親、認証された DS、および子 DNSKEY を通じて TLSA RRset を検証します。実際には、別のループバックTLSサービスがテスト証明書 A、次に B を提示しました。受信した各ハンドシェイク証明書から SPKI を抽出すると、A と A の一致、B と A 単独の不一致、A/B オーバーラップ中の B との一致、および A のリタイア後の B との一致が生成されました。トランスクリプトには、タイムスタンプ、ループバック エンドポイント、 TLSプロトコル、およびダイジェストが記録されます。これにより、個別の暗号要素が検証されます。サービスはSMTP STARTTLSではなく通常のTLSであり、統合されたDANEメール クライアントやライブDNSリゾルバー テストは要求されていません。