プロンプトとコンテキスト
自社ドメインの送信において、DNSSECおよびTLSAレコードを公開することで、SMTP STARTTLSのダウングレード攻撃や中間者攻撃（man-in-the-middle）のリスクを軽減したいと考えています。すべての受信者がDANEをサポートしているわけではなく、証明書は定期的にローテーションされます。MXの探索、TLSA検証、互換性のためのフォールバック、ローテーション、モニタリング、およびインシデント時のロールバックを設計してください。
面接官がテストしていること
- SMTP DANEが認証局（CA）だけでなく、DNSSEC、MXターゲット、TLSAに依存していることの理解。
- 日和見的（opportunistic）DANE、強制（enforced）TLSA、MTA-STS、TLSレポートの区別。
- TLSAの生成、TTL、証明書ローテーション、DNSSEC障害処理の設計能力。
- カナリアリリースにおける配信成功率、ダウングレード、検証失敗、受信者の互換性の考慮。
最初に明確にすべき質問
- 送信ドメイン、受信ドメイン、またはその両方を保護していますか？送信MTAはピアを検証しますか？
- DNSSECチェーン、リゾルバー、およびキャッシュの挙動は信頼できますか？
- 受信者のうち、DANE、MTA-STS、またはSTARTTLSのみをサポートしている割合はどのくらいですか？
- 証明書はCA発行ですか、それとも自己署名ですか？また、ローテーションとロールバックの期間はどのくらいですか？
- 失敗時、配信を遅延（キューイング）させてもよいですか、それとも平文（プレーンテキスト）にフォールバックする必要がありますか？
30秒の回答フレームワーク
送信MTAはMXを解決し、DNSSECを介してTLSAを検証した上で、TLSAの使用法（usage）、セレクター、マッチングタイプ、アソシエーションデータを使用してピアの証明書または公開鍵をチェックします。DNSSECの失敗やTLSAの不一致を通常のSTARTTLS成功として扱ってはならず、ポリシーに基づいて配信を遅延または拒否する必要があります。まずは観察モードから開始し、ドメインごとにカナリア検証を行い、MTA-STSとTLSレポートを組み合わせ、レコードを重複させてロールバック期間を設けてローテーションを実施します。
ステップごとの詳細な回答
ステップ 1: プロトコルパスを追跡する
送信者は受信者ドメインのMXレコードからトランスポートホストを取得し、STARTTLSをネゴシエーションします。DANEはDNSSECで保護されたTLSAレコードを使用して、ドメイン、ポート、およびターゲットの証明書または鍵をバインドします。MX名を証明書名としてそのまま扱ったり、TLSハンドシェイクやホスト名検証ルールをバイパスしたりすることはありません。
ステップ 2: TLSAセマンティクスを選択する
TLSAの証明書使用法、セレクター、マッチングタイプによって、何を照合するかが決まります。レコードは完全な証明書、SubjectPublicKeyInfo、またはダイジェストと一致させることができます。緩やかな選択肢はローテーションを容易にし、厳格な選択肢はより強力な制御を提供します。レコードは現在のフィンガープリントを単にコピーするのではなく、実際のデプロイメントチェーンを表し、バックアップ鍵も考慮する必要があります。
ステップ 3: DNSSECとTTLを設計する
親ゾーンからTLSAまでのDNSSECチェーンを検証し、署名の有効期限、DSの変更、解決エラーを監視します。TTLはローテーションの伝播速度と失効速度を制御するため、必要な期間にわたってレコードを重複させます。リゾルバーやキャッシュの障害による誤ったダウングレードを防ぐため、DNSSECの障害、SERVFAIL、NXDOMAINを「TLSAなし」と明確に区別します。
ステップ 4: 互換性ポリシーを構築する
DANE対応の宛先に対してTLSAを検証します。それ以外の宛先には、MTA-STS、通常のSTARTTLS、またはキューイングに関するドメインポリシーを適用します。強制適用（enforcement）時に平文へサイレントフォールバックしてはなりません。単一の一般的な接続エラーにするのではなく、失敗理由、宛先、DNSSECの状態、および再試行時間をキューとTLSレポートに記録します。
ステップ 5: 証明書と鍵をローテーションする
新旧両方のTLSAレコードを公開し、新しい証明書または鍵をデプロイし、TTLと観察期間が経過するのを待ってから古いレコードを削除します。各ステップで複数のリゾルバーおよびMTAからの見え方を確認します。ダイジェストマッチングの場合は、ツール、アルゴリズム、入力を記録しておきます。ローテーションに失敗した場合は、古いレコードと古い証明書の両方を復元します。
ステップ 6: カナリアリリースと観察
観察モードで社内ドメインまたは低リスクな受信者ドメインから開始し、徐々に強制適用へ移行します。配信成功率、TLSA一致、DNSSEC失敗、証明書不一致、キューの滞留時間、平文へのダウングレードを監視します。TLSレポートを集約・マスキングし、受信者のアドレスや完全なメッセージメタデータを第三者に送信しないようにします。
ステップ 7: インシデントと復旧の訓練
DNSSEC署名の期限切れ、不正なTLSAの公開、早期の証明書ローテーション、MXの変更、リゾルバーの障害、DANE非対応ピアなどの訓練を実施します。強制適用を一時停止し、キューの再試行期間を延長し、DNSまたは証明書をロールバックします。独立したMTAと複数のパブリックリゾルバーが復旧を確認した後にのみ一時停止を解除します。
質の高い模範解答
MX、DNSSEC、TLSA、SMTP TLSをそれぞれ個別に観測可能なステップとして構成します。まずMXを解決し、DNSSECを検証し、TLSAの使用法、セレクター、マッチングタイプを使用してピアの証明書または鍵をチェックします。DNSSECの失敗やTLSAの不一致が発生した場合は、ドメインポリシーに基づく拒否またはキューイングを行い、平文へサイレントフォールバックすることは絶対に避けます。導入は観察モードから開始して段階的に強制適用（カナリア）し、MTA-STSとTLSレポートを組み合わせます。新しい証明書を適用する前に重複するTLSAレコードを公開し、TTLの経過を待ってから古いレコードを削除します。DNSと証明書のロールバック手順を維持し、署名の期限切れ、MXの変更、リゾルバー障害の対応訓練を実施します。
よくある間違い
- DANEを単なるCA検証やMXホスト名のチェックとして扱う。
- DNSSEC検証が失敗した後に、通常のSTARTTLSや平文通信を続行してしまう。
- 代替証明書をデプロイする前に古いTLSAレコードを削除してしまう。
- 単一のリゾルバーや送信者のみでテストし、キャッシュの伝播を無視する。
- TLSレポートに受信者アドレスや完全なメッセージメタデータを含めてしまう。
追加の質問と回答
質問 1: DANEとMTA-STSの違いは何ですか？
DANEはDNSSECとTLSAに依存し、DNSSECを検証するMTAに適しています。MTA-STSはHTTPS経由でポリシーを公開し、CA証明書に依存します。これらは共存可能であり、一方を他方の暗黙のフォールバックとして扱うのではなく、ピアの機能と運用上の境界によって選択します。
質問 2: TLSAは公開鍵と証明書のどちらに一致させますか？
セレクターとマッチングタイプによって決まります。公開鍵やダイジェストを使用すると、証明書チェーンの変更に対する影響を抑えることができますが、誤ったダイジェストの生成を防ぐために入力データ、アルゴリズム、ローテーション記録を正確に保持する必要があります。
質問 3: DNSSECがSERVFAILを返した場合、平文配信にフォールバックできますか？
ドメインポリシーでDANEが要求されている場合はできません。遅延（キューイング）または拒否してアラートを発報します。明示的に許可された互換性ポリシーのみが別のパスを選択でき、その場合もダウングレードを記録する必要があります。
質問 4: 不正なTLSAの公開をどのようにロールバックしますか？
古いTLSAと証明書を復元し、権威DNS、TTLキャッシュ、複数の再帰リゾルバーが収束するのを待ってから、キューの一時停止を解除します。監査のために、不正なレコード、影響を受けたドメイン、復旧時間を記録しておきます。
質問 5: 平文へのダウングレードが発生しなかったことをどのように証明しますか？
宛先ドメインごとにTLSネゴシエーション、TLSA状態、ダウングレード数を記録し、独立したMTAから定期的に検証します。平文通信の試行を高優先度のアラートとして扱い、TLSレポートや配信ログと照合します。