承認する前に DKIM 委任の場合は、正確なDNS変更と、それによって有効になる署名 ID を要求します。 「 DNSレコードを追加する」という指示は、セキュリティ レビューとしては広範すぎます。あ セレクタ CNAME、NS の委任とDNSアカウント全体へのアクセスにより、さまざまな形式の制御が付与されます。
承認する前に境界線を引いてください
1 つのセレクター所有者名のCNAME 、そのターゲットを通じて解決を指示します。そのターゲットを制御するプロバイダーは、エイリアスを通じて到達した検証データを変更できます。それ自体では、ゾーン内の任意の名前を編集する権限が付与されるわけではありません。 NS 委任はゾーン境界を確立し、委任された権威サーバーに、 DNS階層に従ってその下の名前に対する責任を与えます。アカウント全体の管理アクセスはさらに広範囲に及ぶ可能性があります。 RFC 1034 §3.6.2 そして RFC 1034 §4.2 これらのDNSメカニズムについて説明します。
所有者名と影響を受けるサブツリーを承認に書き込みます。のリクエスト service1._domainkey.example.com 全体の制御とは異なります _domainkey.example.com サブツリー。自動化が簡単に見えるという理由だけで、プロバイダーがサポートする狭いレコードを広範な委任に置き換えないでください。
DNSスコープと署名の影響を区別する
DKIM検証では、署名のセレクターと署名ドメインを使用してキーを取得します。使用可能なセレクターの検証データを制御し、一致する秘密署名キーと組み合わせることで、その署名ドメインの有効な署名を有効にすることができます。したがって、1 つのDNS名が明らかに狭いからといって、電子メールの信頼性への影響が無視できるというわけではありません。
合成例でその違いを説明します。プロバイダーは次の場所でCNAMEを受け取ります。 invoices._domainkey.example.com 一致する署名者を操作します d=example.com。そのDNSアクセスはエイリアス ターゲットに限定されますが、その署名者は、エイリアス ターゲットからの責任を主張する署名を作成できます。 example.com。 invoices という名前のセレクター自体は、署名を請求書、特定の受信者、または承認されたキャンペーンに制限しません。アプリケーションとアカウントの制御には、これらの制限を課す必要があります。
送信専用のサブドメインを使用する場合は、該当するサブドメインを評価してください。 DMARC アライメント ルールも。サブドメインの分離によって、緩和された配置が自動的に分離されるわけではありません。 RFC 9989 §4.4 認証された識別子が作成者ドメインとどのように比較されるかを説明します。ポリシーと組織ドメインの決定が重要です。
承認の質問に答える証拠を収集する
プロバイダーの現在の指示、生成された名前、アカウント識別子、サポートされている署名ドメイン、およびローテーション モデルをリクエストします。プロバイダー アカウント内でこれらの値を変更できるのは誰か、および役割の分離が利用可能かどうかを確認します。提供されていない契約上の保証を前提とせずに、アカウントの閉鎖や古い DNS の処理について質問してください。
コンパクトなレジスタを構築します: DNS所有者、レコード タイプ、宛先、または ネームサーバー、サービス所有者、対象 d= ID、特権プロバイダー ユーザー、更新日、退職手続き。提案された NS 委任の場合、承認する前に、影響を受けるサブツリー全体で既存のセレクターを検査します。アカウント アクセス リクエストの場合、レコードごとの指示やより狭いサポートされるロールでは不十分な理由に疑問を呈してください。
オンボーディングのテストと終了の計画
変更が承認された後、権威 DNS 観察と再帰DNS観察を比較し、目的のサービスを通じて送信します。信頼できる受信者のDKIM結果とアライメントを検査します。テストでは、単に署名が合格したことを示すだけでなく、付与された ID を実証する必要があります。
終了時には、アプリケーションのアクセスを停止し、古い送信資格情報を削除し、セレクターの廃止を配信キューおよびプロバイダーのプロセスと調整します。プロバイダーに侵害の疑いがある場合は、ルーチンの重複を自動的に維持するのではなく、インシデント対応を呼び出します。調達記録で非アクティブとマークされたサービスは、依然として実際の技術的依存関係を表す可能性があります。
残留信頼を明示的に文書化します。プロバイダーが署名できる内容、管理できる人、組織が依存関係をどれだけ早く削除できるかなどです。このレコードにより、後の更新では、元のDNSチケットの繰り返しではなく、実際の権限が確認されます。
3 つの仮想的な承認リクエストを比較する
範囲と結果を一緒に使用します。
- 1 つのセレクターCNAME : その正確な所有者とターゲット、意図された ID、およびプロバイダー アカウント制御を確認します。任意のゾーン編集アクセスは許可されませんが、そのキー マッピングにより、その ID の署名が可能になります。
- _domainkey.example.comの下の NS 委任: その委任されたゾーンの下のセレクターと、その権限のあるサーバーを誰が制御しているかをインベントリします。そこにある既存または将来のセレクターは、さらなるゾーン削減の対象となり、影響を受ける可能性があります。
- 完全なDNSアカウント アクセス: 明示的なニーズを要求し、アカウントの実際の権限を検査します。無関係なメールや Web 記録に到達する可能性があります。これは、1 つのセレクター エイリアスを公開することと同じではありません。
これらはレビュー シナリオであり、実際のゾーンに対する承認や変更ではありません。正確な範囲や所有権が不明な場合は、承認前にそのギャップを解決してください。
関連書籍
DKIM TXTおよびCNAME発行: プロバイダーのキー管理モデルに従います。 · DKIMキーを取り消し、失効とDNSレコードの欠落を区別する.