予期せぬ答えと中毒の発見を区別する
DNSキャッシュ ポイズニングは、誤ったデータをキャッシュに置き、後でクライアントに応答を提供します。電子メール認証の場合、受信者が取得するポリシーやキー マテリアルが歪む可能性があります。これは、疑わしいリゾルバーの違いの考えられる説明であり、2 つの一致しないスクリーンショットによって確立された診断ではありません。まず、観察が同じ所有者名、レコード タイプ、ネットワーク ビュー、および時間間隔に関するものであるかどうかを判断します。
有用な調査では、疑わしい回答が解決プロセスのどこに入ったかを尋ねます。権限のない権限のある編集、汚染された再帰的キャッシュ、正当な古いエントリ、およびローカル リゾルバーのオーバーライドは、別の条件です。これらはすべて、オペレーターの期待とは異なる答えをもたらす可能性があります。修理を推奨する前に、仮説とそれを区別するために必要な証拠に名前を付けてください。
攻撃を再現せずにセキュリティ境界を説明する
DNSリゾルバーは、未解決の質問と一致しない応答を拒否し、受信したデータが信頼できるかどうかに関するルールを適用する必要があります。 RFC 5452セクション 9 防御的なマッチング要件と、予測できないクエリ識別子と送信元ポートを指定します。こうした措置により、偽造された回答は受け入れられにくくなります。これらは、サポートされているリゾルバー ソフトウェアを保守し、その実際の構成を確認することに代わるものではありません。
DNSSEC データ発信元の認証と整合性が追加され、検証リゾルバーが必要な信頼チェーンを確立できます。セキュリティ状態は、検証されたデータと、署名されていないまたは検証されていない状況を区別します。 RFC 4033セクション 3 および 5 これらの境界について説明します。ツールに表示される署名済みレコードは、それ自体では、メール受信者がそれを検証したことを証明するものではありません。
リゾルバーへの暗号化されたトランスポートは、独自の認証仮定の下でその接続を保護します。リゾルバーから返されたすべてのデータが信頼できるものであるか、正しく検証されたかどうかは保証されません。トランスポート セキュリティ、 DNSSEC検証、管理制御を 1 つのセキュア DNS バッジに圧縮するのではなく、別個の証拠フィールドとして保持します。
後で解釈できるように比較を保存する
観測ごとに、クエリされた完全修飾名、タイプ、リゾルバーまたは権限のあるエンドポイント、タイムスタンプ、およびネットワーク上の有利なポイントを保持します。応答ステータス、関連フラグ、回答レコード、TTL、権限資料、および拡張診断情報を保存します。検証が要求されたか、ローカルで実行されたか、または単に上流のリゾルバーによって報告されたかを記録します。説明のないアイコンから検証を推測しないでください。
組織がそれらの観察を許可する場合、既知のベースラインを、現在の委任された権限および複数の関連する再帰パスと比較します。さまざまなパブリック リゾルバーは有用な比較ポイントを提供できますが、受信者が実際に使用するパスの代わりとなるものはありません。テーブルに正規化する前に生の結果を保存しておくと、後のレビュー担当者が省略された詳細を検査できます。
受信者の認証結果は、処理時にそのメッセージに対してどのような結論が下されたかという別の質問に答えます。現在のルックアップでは、過去のキャッシュを自動的に再構築することはできません。メッセージ時間、クエリされた ID、および利用可能なリゾルバー テレメトリを関連付けます。テレメトリが存在しない場合は、特定のDNS応答が特定の合格または失敗の原因となったと主張するのではなく、因果関係の説明を未解決としてマークします。
エスカレーションの前に通常の説明をテストする
キャッシュされた肯定的な回答と否定的な回答は、正当な変更後に分岐する可能性があります。 RFC 2308セクション 5 は、否定的な回答を生涯保持することを説明しています。新しく出版された セレクタ したがって、リゾルバが以前の不在を返している間も、当局では表示される可能性があります。この観察はキャッシュと互換性があり、ポイズニングを確立しません。
解決失敗は次の場所にもキャッシュできます。 RFC 9520セクション 3。 SERVFAIL認証レコードの欠落と同等ではなく、即時に繰り返すと、新たに成功した解決策が開始されるのではなく、保持された失敗が再現される可能性があります。これとは別に、以下に基づいて許可されるサーブ・ステイル動作 RFC 8767 つまり、有効期限だけでは、古いデータが表示されないという普遍的な保証はありません。
承認されたスプリット ホライズンの取り決め、一貫性のない権威サーバー、最近の委任の変更、ローカル ネットワーク ポリシーを確認します。これらの説明は、疑わしいデータを無視する理由にはなりません。これらは、インシデント所有者が証拠によって確認または除外できる競合する仮説を提供します。
2 つの異なる答えを実際に実行した架空の例
この架空の比較では、メール所有者はjune._domainkey.example.comに新しいセレクターを期待しています。認証局は 14:10 に新しいキーを提供したと記録されますが、リゾルバー A は 14:12 に以前の否定応答を返し、リゾルバー B は 14:13 にキーを返します。これらの時間と結果は作成されたものであり、クエリのトランスクリプトではありません。
提案されている最初の決定は、以前の否定応答とそのキャッシュ コンテキストを調べることです。リゾルバー A が後でそのコンテキストと一致する方法で予期されたキーを返した場合、このケースはポイズニングなしで説明できる可能性があります。承認された履歴に一度も出現したことのない無関係なキーが返された場合、証拠はより疑わしいものになりますが、チームは原因を特定する前にリゾルバーと承認されたパスを調査する必要があります。
いかなる比較も、発明された例を事件の結果に促進するものであってはなりません。実際のケースでは、疑わしい値とそれを不正と呼ぶ根拠の両方が、証拠を保持し、責任ある所有者を必要とします。
影響を受ける層に応じて回復を選択する
インシデント所有者が再帰的サービスの侵害を確認した場合は、組織の承認された手順を使用して信頼できる操作を復元し、影響を受けるクライアントのリゾルバー パスを確認します。信頼できるコンテンツが変更された場合は、代わりにその管理パスを修復して保護してください。キャッシュのフラッシュだけでは、再挿入を防止したり、侵害された権限を取り消したりすることはできません。また、ラップトップをフラッシュしても、リモート メール プロバイダーのキャッシュはクリアされません。
回復後、新しい観察結果を承認されたベースラインと比較し、代表的なメッセージの結果を検査します。以前の決定と下流のキャッシュに関する残留不確実性を記録します。この原稿の原本証拠の要件は未解決のままです。タイムスタンプ付きのリゾルバーと TTL の比較は行われておらず、応答タイプと権限は収集されておらず、ポイズニング テストやライブ修復は実行されていません。