A DMARC 変更リクエストにより、他の人が何が変更されるか、どのサービスが影響を受けるか、どのように成功するかを正確に判断できるようにする必要があります。目的のポリシーを示すスクリーンショットだけでは十分ではありません。ベースラインと提案された RRset を保存し、承認されたビジネス フローと復旧の決定にそれらを接続します。
ベースラインを正確に捉える
DNSプロバイダーのアカウントまたはテナント、ゾーン、所有者名、レコード タイプ、完全な値、および TTL を記録します。観察の時間と情報源を含めます。影響を受ける作成者ドメインに加えて、承認された送信者と未解決の例外に関する現在のDMARCポリシー検出をキャプチャします。テストをダッシュボードの色に限定するのではなく、認証識別子を保持します。
DMARC 、整列されて成功したものを通過できます。 SPF または DKIM 結果。したがって、メッセージに表示される From ドメインとその認証された識別子は、 SPFが渡す一般的なステートメントよりも重要です。 RFC 9989。ドメイン公開の場合 p=reject, RFC 9989 セクション 7.4 と 8 は、有効なDKIM署名を個別に要求し、 SPFのみに依存することを禁止しています。メッセージレベルの成功は、その展開義務を免除するものではありません。認証パスはビジネス リクエストを認証したり、受信箱の配置を保証したりするものではありません。
意図された違いを説明する
正確な前後の RRset と影響を受ける名前を記載します。なぜ今変更が必要なのか、どのサービスがテストされたのか、どの証拠が不完全なままなのかを説明してください。承認者がより広範な操作を誤って承認しないように、無関係なDNS編集をリクエストの外に残しておきます。技術実装者、ビジネス承認者、エスカレーション連絡先を特定します。
レポートの宛先または委任されたサービスが変更された場合は、情報の流れと依存関係を個別に評価します。目的の監視に必要なレポート取り込み構成を保存します。 集計レポート はカバレッジ制限のある受信機観測であるため、タイムクリティカルな正当なフローに対する唯一の受け入れ信号になることはできません。 RFC 9990.
観察可能な受け入れ基準を作成する
失敗する可能性のある基準を使用します。権限のある RRset が承認された値と等しい。代表的な重要なメッセージは、意図された ID を使用し、期待どおりに認証されます。ビジネスの受信者は期待される結果を確認します。そしてレポートの取り込みは継続します。観察時間を記録し、すぐに利用できるテストと後のレポートレビューを区別します。まだ到着していないレポートはテストに合格したわけではありません。
実装前に回復トリガーを定義します。重要なフローが失敗し、診断によってそのフローが承認された変更に関連付けられている場合は、承認された復旧計画を呼び出します。古い状態を保存し、その限界を説明します。ポリシーを復元しても、キャッシュされたDNSすぐに元に戻されたり、すでに拒否されたメッセージが取り消されたりすることはありません。名目上のメンテナンス期間を超えて観察を計画します。
リクエストが実際にクローズできるかどうかをテストする
架空のリクエストにより、給与計算元ドメインのポリシーのみが変更されるとします。 p=none に p=quarantine レポート宛先と TTL は保持されます。レビューでは、完全なベースラインと提案された RRset、ターゲット アカウントとドメイン、承認された給与範囲、および回復計画をバインドする必要があります。ここでは、実際のペイロード、承認、 DNS変更は提供されません。
承認された変更後の監視が承認されたDNS状態と一致し、代表的な給与メッセージが期待どおりに認証されるが、企業の受信者が受信を確認しておらず、次の集計レポートがまだ利用できないと仮定します。構成と認証のチェックを、保留中の結果とは別に記録します。領収書のフォローアップを給与担当者に割り当て、遅延した摂取レビューを報告担当者に割り当てます。一致するレコードの強さに基づいてすべての合格基準を閉じないでください。これらは仮説上の結果であり、実行されたチェックではありません。
上記の変更ワークフローは運用上の推奨事項であり、プロトコル要件ではありません。 NIST SP 800-53 Rev. 5 コントロール CM-3 および CM-5 は、変更をレビュー、承認、制限するための一般的な基盤を提供します。ここでの正確なペイロード バインディング、ロール、およびハンドオフ フィールドは、提案された実装です。 NIST管理カタログ.