警告色ではなく結果を優先順位付けする
DNSヘルス チェッカーは、プロトコルの障害、復元に関する推奨事項、およびオプション機能を 1 つの警告スコアに組み合わせることができます。郵便事業者は、別の順序付けが必要です。つまり、どの決定が、どのルートで、どのような証拠に影響されるのでしょうか?使用できないアクティブな DKIM キーとより低い TTL の推奨事項が自動的に同じインシデント優先度を受け取るべきではありません。
まず、正確な警告、テストされた名前とレコードの種類、時間、リゾルバーまたは有利なポイント、およびツールの説明を取得します。それを観察された障害、考えられるリスク、または勧告として分類します。ツールがラベルのみを提供する場合は、その制限を維持してください。ダッシュボードを緑色にするためだけに別の認証レコードを公開しないでください。
テストされた名前がメール パスに属しているかどうかを確認する
存在しないDKIMレコードは、 セレクタ 調査中のサービスで実際に使用されている署名ドメイン。 RFC 6376セクション3.6.2.1 署名値からルックアップ名を導出します。セレクターを推測するスキャナーは、デプロイされた有効なキーを見逃したり、未使用の名前について警告したりする場合があります。推測された欠席を運用上の失敗として扱う前に、代表的なメッセージの証拠を要求してください。
同じ規律を～に適用する SPF。表示されている From ドメインをチェックするツールは、受信者が評価したSMTP ID をチェックしていない可能性があります。 RFC 7208セクション 2 それらのアイデンティティを区別します。どの所有者が警告を修正する必要があるかを決定する前に、ルートと実際に評価される名前を決定してください。
関連する子ゾーンの委任またはエイリアスを含む、現在委任されている権限を検索します。コントロール パネルは、その権限との関係がわかっている場合にのみ、意図された構成の証拠となります。欠落したレコード、間違った名前の値、間違ったホスティング アカウントでの編集の区別を維持します。
レコードを変更する前に応答を解釈する
NXDOMAIN 、クエリされた名前が存在しないことを示しますが、 NODATA結果は、要求されたデータが既存の名前に存在しないことを示します。で説明されているように、ネガティブ キャッシュでは以前の結果を保持できます。 RFC 2308セクション 2 および 5。したがって、新しく作成されたレコードは、特定の再帰パスがそれを示す前に権威者に現れる可能性があります。
SERVFAIL代わりに、解決の失敗を説明するものであり、ポリシーが存在しないことを証明するものではありません。 RFC 9520セクション 2.1 考えられる多くの原因について説明します。委任、到達可能性、検証の証拠を調査します。解決が壊れているときに重複レコードを追加すると、元の障害が修復された後に 2 番目の問題が残る可能性があります。
TCP サポートに関する警告は、表面的な無視以上の価値があります。 RFC 7766セクション 5 UDP と TCP の両方をサポートするには、汎用DNS実装が必要です。小規模なルックアップが成功しただけでは、より大きな応答や他のパスが正しく動作するかどうかは確立されません。適切なフォローアップは、範囲を限定したトランスポート診断であり、現在のすべてのメッセージがすでに失敗していると主張するものではありません。
当面の影響と潜在的なリスクを区別する
メールに影響を与える即時の検出結果は、観察されたDNS問題をアクティブなルートに結び付けます。たとえば、受信者が検証時に必要としたセレクターのリゾルバー障害などです。潜在的な信頼性の問題により、復元力が低下しながら現在のテストが合格したままになる可能性があります。勧告的な発見は、望ましい機能に関するものであり、その機能がなくても実際に展開されているプロトコルが無効になることはありません。
観察の信頼性と、状態が続いた場合の結果という 2 つの側面で分類します。証拠が不完全で影響力の大きい疑惑の場合は、停止宣言をする必要がなくても、緊急の調査が必要になる場合があります。期限切れの勧告例外は、レポートから静かに消えるのではなく、所有者とレビュー日を受け取る必要があります。
「」のような包括的なラベルは避けてください。DNSSEC 見つからないということは、電子メール認証が壊れていることを意味します。」 DNSSEC認証されたDNSデータを追加できますが、 SPF 、 DKIMおよび DMARC 独自の要件と結果があります。どこ DANE SMTPが展開され、 DNSSECそのトランスポート設計において直接的な役割を果たします。 RFC 7672セクション 2.1。したがって、同じ警告がサービス間で異なる結果をもたらす可能性があります。
3 つの警告が実際に機能した架空の例
example.comの架空のチェッカーは、default と呼ばれる欠落したセレクター、1 つの権威エンドポイントへの失敗した TCP ルックアップ、および TTL 推奨事項を報告します。メール チームが作成したインベントリでは、アクティブな請求書ルートで使用されるセレクターとして june が特定されます。したがって、最初の警告では、即座にレコードを作成するのではなく、セレクターの確認が必要になります。
2 番目の警告は、テストされたエンドポイント、時間、影響を受けた応答の詳細とともにDNS所有者に送信されます。これは、たとえ 1 つの小さな UDP クエリが成功したとしても、トランスポートの問題を表します。 TTL の推奨事項は、変更計画の議論になります。TTL を減らすことは将来の変更に役立つ可能性がありますが、現在の配信失敗を証明したり、古い値で既にキャッシュされているエントリを直ちに短縮したりすることはできません。
このシナリオではクエリやメッセージは実行されませんでした。提案されている優先順位は、混在したダッシュボード スコアを技術的な判断として扱うことを回避する方法を示しています。実際の分類には、信頼できる再帰的な結果と、テストされた記録をサービスに結び付ける証拠を保持する必要があります。
見直し可能な決定を記録する
警告ごとに、影響を受ける依存関係、証拠、信頼度、所有者、次のアクション、および終了条件を記録します。 「後で再確認」は、何が変更されたのか、そして次の観察で何を確立する必要があるのかを特定しなければ不完全です。 「受け入れられたリスク」には、誰がそれを受け入れたのか、またその決定がいつ再検討されるのかを含める必要があります。
承認された修正後は、元のスコアを更新するだけでなく、関連する観察を繰り返し、依存サービスを検証します。権限、再帰パス、メッセージ結果の間の未解決の差異を保持します。オリジナル証拠のゲートは、タイムスタンプ付きの信頼できる再帰的回答によって正確な所有者名とレコード タイプが特定されるまで、開いたままになります。この原稿は、そのような観察を提供したり、ドメインの健全性を保証したりするものではありません。