現在のガイドとその制限から始める
電子メール認証はDNSサービスに依存しており、DNS サービスの障害や不正な変更により、受信者に表示されるポリシーとキーが変更される可能性があります。 NISTレビューは、組織の運用モデルへのこれらの依存関係を追跡するのに役立ちます。認証記録の表示にとどまらず、出版物の引用を認証に変えるものでもありません。タスクは、関連する推奨事項、実際のシステム所有者、および検査可能な動作証拠を結び付けることです。
の NIST出版実績 SP 800-81 リビジョン 3 が最終版であり、2026 年 3 月に発行され、文書履歴には 3 月 19 日が記録されていると特定しています。これはリビジョン 2 に優先します。2026 年 7 月 10 日の計画ノートでは、更新の可能性が示されています。リンクされたスプレッドシートは、この調査中にサポートされていないコンテンツのエラーを返し、再試行されなかったため、その個々のエントリは未検証のままです。以下の分析では、アクセス可能な 3 月の最終テキストを使用していますが、その制限は明らかです。
どのDNS役割が各依存関係を提供するかを特定する
の 最終展開ガイド 権限のあるサービス、再帰的サービス、およびスタブリゾルバーを分離します。オペレーターが予期しない答えを見た場合、この区別が重要になります。権威あるサービスはゾーン データを公開します。再帰的サービスはキャッシュから応答するか、他の場所でデータを取得する可能性があります。アプリケーションのリゾルバー パスによって別のレイヤーが追加される場合があります。コントロール パネルの表示は、受信システムによって使用されるすべてのパスを観察するものではありません。
実際の記録を作成せずに、 notices.exampleの架空の目録を作成します。リストします DMARC ポリシー所有者名とTXTタイプ、実際の DKIMセレクター 既知の依存関係、および選択したトランスポートに関連するメール交換の依存関係。委任されたサービス名とプロバイダー管理のレコード関係を含めます。ドメインのブランドからセレクターを推測しないでください。 DKIM 署名とセレクターの関係を提供します。組織は、関係が設定され運用されていると主張する前に、実際の承認された例をまだ必要としています。
推奨事項をホスティング契約にマッピングする
NISTガイドのセクション 2.3.1 と 2.3.2 では、サービスの役割と復元力について説明しています。その議論では、インターネットからアクセス可能な権限のある役割と再帰的な役割を区別し、内部サービスのさまざまな状況を認識しています。また、分散、バックアップ、リカバリについても説明します。マネージドDNS顧客が管理できない 2 番目のサーバーを規定するのではなく、関連する推奨事項を実際のアーキテクチャに適用します。クラウド プロバイダーのレプリケーション設計は、従来のプライマリ/セカンダリ構成とは異なる場合があります。
それに応じて証拠の境界を記録します。自己ホスト型のオペレーターは、構成、アクセス制限、および回復記録を提供する場合があります。マネージド サービスの顧客は、文書化されたサービス機能、範囲指定されたアカウント構成、および責任あるプロバイダーとの関係を必要とする場合があります。ベンダーのロゴもネームサーバーのラベルの数も、障害が発生したドメインの独立性を証明するものではありません。目録には、どの主張が直接観察されたのか、契約上文書化されたのか、またはまだ証拠を待っているのかを記載する必要があります。このガイドではプロバイダー アカウントは検査されませんでした。
変更パスと公開された回答を保護する
NISTの権威サービスに関するディスカッションでは、ゾーン転送、動的更新、および古い委任が取り上げられています。これらは通常のパブリック クエリとは別のものです。ゾーン転送または更新メカニズムが適用される場合は、承認されたピアまたは送信者と、トランザクションを保護するメカニズムを特定します。共有秘密メカニズムを転送全体の暗号化として説明したり、公開鍵レコードによって誰かがゾーンを変更する権限を与えられると想定したりしないでください。アカウント アクセスとプロバイダー API は、従来のDNS更新フローの外側にある追加の制御パスである場合があります。
架空の認証依存関係の場合、提案された証拠行は、セレクターの変更をその承認者、前後のレコードの意図、出版物の所有者、および回復手順に結び付けることができます。許可された作業によって観察フィールドが生成されるまで、観察フィールドは空のままにしておきます。古いキーまたはサービスが侵害された場合、古いレコードの復元は必ずしも安全なロールバックであるとは限りません。リカバリの決定には、インシデントのコンテキスト、現在の信頼状態、キャッシュが以前のデータの使用を停止するのに必要な時間が必要です。
完全性、機密性、可用性を区別する
セクション 3.8 では次のように説明されています。 DNSSEC DNSデータのソース認証と整合性保護を提供します。クエリの内容が機密になるわけではありません。暗号化されたDNSトランスポートは、別の関係に対処します。どちらのコントロールも、公開された電子メール ポリシーが企業が意図したものであることを証明するものではありません。安全に検証された間違ったレコードは運用上間違ったままになる可能性があり、構成またはライフサイクルの間違いにより署名されたゾーンが使用できなくなる可能性があります。
キャッシュの動作も証拠計画に含まれます。 RFC 2308 ネガティブ キャッシュをカバーしているため、以前に答えが見つからなかった場合、後の観察に影響を与える可能性があります。不一致の伝播をすべて呼び出すのではなく、応答ステータス、有利な地点、および時刻を記録します。 DNSSEC障害については、 NISTのスタブリゾルバーに関する議論で、有用な診断には上流の検証ログが必要になる可能性があると記載されています。これは提案されたトラブルシューティング要件であり、顧客環境で検証エラーが発生したという証拠ではありません。
運用証拠をレビュー可能にする
NISTのロギングに関する議論では、リソースへの影響を認識しながら、 DNS観察をインシデント対応に結び付けています。したがって、証拠計画では、有用なイベント、責任のある所有者、保護された保存場所、およびアクセス境界を指定する必要があります。ログから運用上の関係が明らかになる場合があります。目的なしにデータを収集しても、自動的に制御が改善されるわけではありません。提案されたモニタリングでは、解決の失敗、不正な変更、およびDNS応答が正常であるにもかかわらず発生する認証の失敗を区別する必要があります。
正確なカタログ要件は次のとおりです。「最新のNISTテキストを使用し、該当するDNS構成と運用証拠を実証する」。現在の最終テキストと架空の依存関係の演習は保持されますが、このパッケージには該当する顧客設定や操作デモは存在しません。この要件は、技術レビュー、ソース更新レビュー、視覚的な受け入れ、所有者のリリースと並行して未解決のままです。クエリ、 DNS変更、資格情報の処理、およびサードパーティの開示は実行されていないため、適切な承認が必要です。成果物は管理から証拠への計画であり、 NIST準拠の実装を主張するものではありません。