保存されたDNS変更と失敗したメッセージは両方とも本物である可能性があります。リゾルバーがまだ古い応答を保持している間に、レコードが権威DNSに到達している可能性があります。または、変更はどこにでも表示されますが、送信側アプリケーションが使用する ID とは無関係である可能性があります。
まず、何が変更されたのか、またその変更によって何が達成されると期待されていたのかを正確に特定することから始めます。ポリシーの編集、 SPF 認可と DKIM 公開キーはさまざまな問題を解決します。それらを交換可能なものとして扱うと、因果関係の説明なしに変化が繰り返されることになります。
期待される効果を書き出す
以前の値、新しい値、正確な所有者名、レコード タイプ、タイムスタンプ、および責任のあるオペレーターを保持します。検証可能な仮説を述べます。たとえば、新しいDKIM鍵を使用すると、受信者は特定の d ドメインと s で署名を検証できるようになります。 セレクタ。サービスがこれらの値で署名していない場合、 DNSパブリケーションだけではその結果を生成できません。
変化 p=reject に p=none 要求された処理コンテキストを変更します。調整されていないアイデンティティを調整されたアイデンティティに変えるわけではありません。下 RFC 7208 §2.4 そして RFC 7208 §4.4、 example.comでSPFインクルードを公開しても、ベンダーが使用する無関係なエンベロープ ドメインのSPF修復されません。の アライメントガイド これらのアイデンティティを比較する方法について説明します。
目的のDNSが実際にサービスを提供しているかどうかを確認する
権威者に問い合わせる ネームサーバー 完全な応答を保持しながら、正確な名前とタイプを取得します。期待されるレコードを、関連するすべての信頼できる回答と比較します。権限のあるサービスが依然として古い値を返す場合は、再帰的キャッシュを待つ前に、エディター、ゾーンの選択、委任、およびプロバイダー側のデプロイメントを調査してください。
信頼できる回答が新しい値に一致したら、テスト環境で使用されているリゾルバーと、関連する別の再帰リゾルバーをクエリします。コンテンツだけでなくステータスとTTLも記録します。キャッシュされた不在は、キャッシュされた古い値とは異なります。ネガティブ キャッシュでは、以前のNXDOMAINまたはNODATA応答を残りの有効期間にわたって保存できます。 RFC 2308 §3, RFC 2308 §4 そして RFC 2308 §5.
低下 記録の TTL は、以前の有効期間ですでにキャッシュされたコピーを遡及的に短縮しなくなりました。すべてのDNS変更が一定の分数以内に表示されるようになるという普遍的な約束は避けてください。適格な古いデータを提供する動作では、TTL 有効期限を超えて古いデータを保持して使用することもできます。 RFC 8767 §4。観察された回答とキャッシュされた証拠を使用して、再テストがいつ意味があるかを判断します。
昨日のヘッダーではなく、新しいメッセージをテストします
認証結果は特定の配信に対して記録されます。新しいDNS構成は、すでに受信したメッセージを書き換えません。影響を受けるアプリケーションを通じて新しい制御メッセージを生成し、そのタイムスタンプと受信者が生成した結果を保存します。 RFC 8601 §1.2 そして RFC 8601 §4.
表示される From ドメイン、SPF で評価された ID と結果、および関連する各DKIM署名ドメイン、セレクター、および検証結果を比較します。それから調べてください アライメント 該当するものに基づいて DMARC ポリシー。認証が有効になっているというベンダー ダッシュボードで立ち止まらないでください。実際のメッセージが何を伝えるのかを判断します。
署名セレクターが公開したものと異なる場合は、サービスのアクティブ化または構成を調査してください。署名が無関係なドメインを検証する場合は、サポートされている顧客に合わせた ID 設定を調査してください。ゲートウェイの後でのみ署名が失敗する場合は、その中間の前後のルートを比較します。対象コンテンツの変更は、以下の検証に影響を与える可能性があります。 RFC 6376 §3.7ただし、失敗だけでは原因を特定したり、どのホップがメッセージを変更したかを証明したりすることはできません。これらは異なる診断であり、異なる変化をもたらすはずです。
コンパクトな意思決定記録を使用する
この合成例は、レイヤーが重要な理由を示しています。
- 所見: 権限のあるDKIMキーは新しいです。再帰検索は古いものです。サポート内容: DNS観察は異なります。次の調査: キャッシュの有効期間とリゾルバーのパス
- 所見: どちらのDNSビューも新しいです。メッセージは別のセレクターを使用します。サポート内容: 公開されたキーがこの署名と一致しません。次の調査: 送信者のアクティブな署名構成
- 観察: 一致する署名パス。 d ドメインは From とは無関係です。サポート内容: 署名は機能しますが、位置合わせは提供されません。次の調査: サポートされる調整された送信 ID
- 観察: 新しいダイレクト メッセージ パス。転送されたコピーは失敗します。サポート内容: ルートは認証の存続に影響します。次の調査: 転送とメッセージの変更
これらの観察だけでは、すべての受信者に対する攻撃や機能停止を証明するものではありません。結論は証拠に比例するようにしてください。
症状を隠すためにポリシーを変更しないでください
ビジネスクリティカルな配信の問題には、一時的な軽減策を文書化する必要がある場合があります。技術的な修正とは別に、スコープ、所有者、有効期限、および検証基準を選択します。組織全体のポリシー削減は、無関係なトラフィックに影響を与える可能性があり、単一の未検証のアプリケーション障害に対する反射的な対応であってはなりません。
実際の変更に備えてロールバック計画を保存します。 DNS値の復元自体、キャッシュを通じて表示されるようになるまでに時間がかかる場合があり、古いキーが侵害されている疑いがある場合は、古いキーを復元することは適切ではありません。ロールバックを即時リカバリとして扱う前に、これらの制約を特定してください。
因果関係の説明で締めくくる
どの層が間違っていたのか、何が変更されたのか、そして修正を裏付ける新しい証拠は何かを記録します。受信メッセージの前後の比較と、関連するDNS観察をまとめて保存します。使用 集計レポート 後続の報告されたトラフィックをリアルタイムまたは完全な配信ログとして扱わずに、同じパターンを探す。 RFC 9990 §3.1 集約レポートについて説明します。
目的のワークフローに信頼できる合格調整結果があり、配信の問題が説明されると、問題は解決されます。受信箱の配置は、受信者の個別の決定のままです。 DNS更新の成功はマイルストーンであり、調査が終了するわけではありません。
次の決定を明確にする
変更されたセレクター フィクスチャを使用して、同じ未使用のキーを再発行するのではなく、アクティブな署名構成を修正するかどうかを決定します。終了する前に、影響を受けるワークフローを通じて 1 つの新しいテスト、その信頼できる受信者の結果、正確な d/s 値、および残りのカバレッジ制限を記録します。その証拠が入手できない場合は、関連する申し立てを保留のままにしてください。ここでは、 DNS公開、キーのアクティブ化、配信テストは実行されませんでした。