緑色のチェッカー結果と失敗メッセージはどちらも正確である可能性があります。チェッカーは 1 つの名前について現在のDNSポリシーを検査した一方で、受信者は別の From ドメインを評価したり、以前にキャッシュされた回答を使用したり、意図した調整された署名のないメッセージを受信したりした可能性があります。
まず 2 つの観察を比較することから始めます。構成を変更する前に、元の結果を保存してください。次に、各システムがいつ何を検査したかを正確に尋ねます。
チェッカーが実際にチェックした内容を書き留める
入力したドメイン、正確なクエリ名、クエリ タイプ、タイムスタンプ、リゾルバー、および返されたレコード セットを記録します。表示された説明と結果の色を保存します。ツールがDNSのみを検査したのか、それとも提供されたメッセージを実際に評価したのかを判断します。
_dmarc.example.comで公開されたポリシーの場合、ポジティブ ルックアップにより、その名前で監視されるポリシーが確立されます。を確立するものではありません。 SPF または DKIM アプリケーションのメッセージ上の ID。また、ツールが受信側と同じ検出ルールに従っていたことも証明されません。
仕様の前提条件を見えるようにしておきます。現在 RFC 9989 §4.10 検出ドメインと組織ドメインにDNSツリーウォーク ルールを使用します。従来の実装では、特に緩和された場合に、異なる仮定を使用することができます。 アライメント。比較によってその結論が裏付けられるまで、不一致をDNSエラーとして説明しないでください。
メッセージから受信者の調査を開始します
配信された例では、元の受信メッセージを保持し、信頼できる受信システムのメッセージを特定します。 Authentication-Results。表示されている From ドメイン、評価されたSPF ID、各DKIM d および s 値、認証結果、調整および適用可能なポリシーを記録します。
下 RFC 8601 §7.1、信頼できない認証アサーションを、受信側システムの作業の代替としてではなく、メッセージ コンテンツとして扱います。また、ヘッダー内のプロバイダー名は、組織がそのプロバイダー名を使用するアカウントを承認したことを証明するものではありません。
拒否の場合、検査する配信メッセージが存在しない可能性があります。返された完全なSMTPテキスト、メッセージまたはトランザクション参照、送信アカウント、受信者のドメイン、およびタイムスタンプを保持します。これらを、送信側システムのイベント レコードおよび送信された利用可能な元のメッセージと組み合わせます。
コンテキストを含むDNS比較を収集する
調査パケットには以下を含める必要があります。
- 観察: 正確な所有者名に対する完全な信頼できる回答。保持する理由: 収集時にサービス提供ゾーンのデータを表示します
- 観察: ステータスと TTL を含む、関連する再帰的回答。保持する理由: リゾルバー ビューとキャッシュされた状態の可能性を示します。
- 観察: 任意のエイリアスまたは委任パス。保持する理由: どの権限と名前が関与したかを説明します
- 観察: フル TXTレコード 境界線。保持する理由: 1 つの複数文字列レコードを複数のポリシー候補から区別するため
- 観察: UTC 収集時間と最近の変更履歴。保持する理由: 現在のデータをメッセージの評価時間に関連付けます。
応答コード、権限情報、または欠席が重要な場合は、+short 出力のみを保持することは避けてください。使用 失われたレコードガイド 名前と権限を追跡します。
現在の信頼できる回答は貴重な証拠ですが、リモート受信機の履歴キャッシュを再構築することはできません。受信者が今日の答えを使用したに違いないと宣言するのではなく、そのギャップを述べます。
総合的な不一致を克服する
この架空のケースは、スコープの一致が重要である理由を示しています。
- アイテム: 14:10 UTC のチェッカー。キャプチャされた観察: example.comの有効なポリシー
- 項目: 14:04 UTC の失敗したメッセージ。キャプチャされた観察: 送信者はalerts@notices.example.comです
- 項目: 送信者の署名;キャプチャされた観察: d=mailer.example.netが検証します
- 項目: ソースポリシーの証拠。キャプチャされた観察: アプリケーションはプロバイダーによって制御されるエンベロープ ドメインを使用します
- 項目: サブドメイン構成。キャプチャされた観察: notices.example.comには明示的なポリシーが存在します
ルート ドメイン チェッカーは、そのメッセージのポリシーまたは調整を確立していません。この例では、受け渡すプロバイダーの署名も From ドメインとは無関係です。サブドメイン ポリシーとアプリケーションでサポートされている調整された構成を調査します。
別のケースでは、正しい ID が調整されているにもかかわらず、必要なポリシー検索がタイムアウトしたことが判明する可能性があります。 RFC 9989 §5.3.6 は、不完全なチェックを合格または不合格として分類しません。同じチェッカーの色でも、異なる修理が必要になります。
DNS応答カテゴリを区別する
関連データを含む成功応答は、 NXDOMAIN 、完全なデータなし応答、 SERVFAIL 、 REFUSED 、およびタイムアウトとは異なります。これらの観察はすべて「ノー」を意味するわけではありません。 DMARCレコード”. RFC 1035 §4.1.1 DNS応答コードを定義します。 RFC 2308 §2.1 そして RFC 2308 §2.2 NXDOMAINとNODATAを区別してください。
不在を解釈する前に、クエリされた名前を確認してください。 _dmarc.example.comのNXDOMAIN 、エイリアスを複雑にすることなく、クエリされた所有者名を記述します。それ自体では、 example.com存在しないことを証明するものではありません。
下 RFC 2308 §5、ネガティブ キャッシュは、その後の以前の不在を保存できます。 記録 が追加されます。ポジティブ キャッシュでは、編集後に以前の値を保存できます。説明を評価できるように、応答コンテキストと収集時間を保持します。
一致した証拠から修理を選択してください
ツールと受信者が異なる名前で調査した場合は、調査範囲を修正してください。メッセージに調整されたパスがない場合は、サポートされている送信構成を修正します。権威サーバー間で答えが異なる場合は、ゾーンの一貫性を調査してください。再帰的な解決が失敗した場合は、リゾルバー、委任、検証、およびトランスポート パスを検査します。
ポリシーの編集は、すべての不一致を自動的に修復するものではありません。関連する最小の構成を変更し、その理由を保持します。使用 アライメントガイド 一致しないドメインに対して raw 認証が合格した場合。
管理されたテストを繰り返し、比較を終了します
修復後、同じアプリケーション アカウントとルートを通じて、新しいDNS観察と代表的なメッセージをキャプチャします。新しい結果を以前のパケットと比較し、変更された証拠を説明します。
1 回の再試行が成功すると、その試みが示されます。インシデントに複数のルートまたは受信者が関係する場合は、定義されたサービス レベル チェックを続行します。
有用な結論は、不一致の一致した説明です。つまり、何がチェックされたか、受信者が何を評価したか、どの相違点が重要で、どの修復が結果を変えたかなどです。
次の決定を明確にする
14:10 チェッカーと 14:04 メッセージ フィクスチャの場合、まずクエリされた作成者ドメインを調整し、メッセージの ID を再構築します。証拠がない限り、6 分の違いをキャッシュのせいだと考えないでください。必要なDNSエラーと整合性の欠如は別の結果です。条件を満たす古い回答は、TTL の有効期限を超えて延長される可能性があります。 RFC 8767 §4。図示された観察は架空のものであり、記録されたログではありません。