7. Stub Resolver Considerations (スタブリゾルバに関する考慮事項)

プロトコルによって厳密に要求されているわけではありませんが, ほとんどの DNS クエリはスタブリゾルバから発信されます。定義上, スタブリゾルバは再帰クエリモードを使用して DNS 解決の大部分の作業を再帰ネームサーバにオフロードする最小限の DNS リゾルバです。スタブリゾルバの広範な使用を考えると, DNSSEC アーキテクチャはスタブリゾルバを考慮する必要がありますが, スタブリゾルバに必要なセキュリティ機能は, セキュリティ認識反復リゾルバに必要な機能とはいくつかの点で異なります。

セキュリティ無認識スタブリゾルバでさえ, 使用する再帰ネームサーバがセキュリティ認識である場合は DNSSEC の恩恵を受ける可能性がありますが, スタブリゾルバが DNSSEC サービスに実際に依存するには, スタブリゾルバは問題の再帰ネームサーバとそれら自身とそれらのネームサーバ間の通信チャネルの両方を信頼する必要があります。これらの問題の最初はローカルポリシーの問題です: 本質的に, セキュリティ無認識スタブリゾルバは, 自身で DNSSEC 有効性チェックを実行しないため, 使用する再帰ネームサーバの慈悲に身を委ねる以外に選択肢がありません。2番目の問題には何らかの種類のチャネルセキュリティメカニズムが必要です, SIG(0) ([RFC2931]) や TSIG ([RFC2845]) などの DNS トランザクション認証メカニズムの適切な使用で十分であり, IPsec の適切な使用でも十分です。特定の実装には, オペレーティングシステム固有のプロセス間通信メカニズムなど, 他の選択肢がある場合があります。このチャネルには機密性は必要ありませんが, データ完全性とメッセージ認証が必要です。

再帰ネームサーバとそれらへの通信チャネルの両方を信頼するセキュリティ認識スタブリゾルバは, 受信する応答メッセージのメッセージヘッダー内の認証済みデータ (Authenticated Data, AD) ビットの設定を調べることを選択できます。スタブリゾルバは, このフラグビットをヒントとして使用して, 再帰ネームサーバが応答の Answer および Authority セクション内のすべてのデータの署名を検証できたかどうかを確認できます。

何らかの理由でセキュリティ認識スタブリゾルバが使用する再帰ネームサーバとの有用な信頼関係を確立できない場合, セキュリティ認識スタブリゾルバが取ることができるもう1つのステップがあります: クエリメッセージでチェック無効 (Checking Disabled, CD) ビットを設定することにより, 自身で署名検証を実行できます。したがって, 検証スタブリゾルバは DNSSEC 署名をゾーン管理者とスタブリゾルバ自身との間の信頼関係として扱うことができます。