## page was renamed from DNSSEC/スタブリゾルバ
## page was renamed from DNS/DNSSEC/スタブリゾルバ
## page was renamed from DNS/DNSSEC/スタブリゾルバー
DNS/DNSSEC/スタブリゾルバーについて、ここに記述してください。

== RFC4033 日本語訳より ==

7.  スタブリゾルバに関する考慮点

プロトコルで厳密に要求されているわけではないのだが、ほとんどのDNS問合わせはスタブリゾルバで生成される。

定義によれば、
   スタブリゾルバとはDNS名前解決処理の大半を再帰ネームサーバに
   委託するために再帰問合わせモードを使用する、最小限のDNSリゾルバである。

スタブリゾルバは広範囲で使用されているため、DNSSECアーキテクチャはスタブリゾルバを考慮しなければならない。
しかし、スタブリゾルバで必要とされるDNSSEC機能は、DNSSEC対応の反復検索を行うリゾルバ
(フルリゾルバ)で必要とされる機能と幾つかの点で異なる。

スタブリゾルバがDNSSEC非対応であったとしても、
そのスタブリゾルバが使用する再帰ネームサーバがDNSSEC対応であれば、
DNSSECの恩恵を受けられるかもしれない。
  しかしDNSSECサービスを実際にあてにするのであれば、
  スタブリゾルバは使用する再帰ネームサーバとネームサーバへの通信チャネルの
  両方を信頼しなければならない。

再帰ネームサーバを信頼する問題はローカルポリシーに関するものである。
   DNSSEC非対応スタブリゾルバは自分ではDNSSECのデータ検証を行わないため、
   使用する再帰ネームサーバを信じる以外に選択肢は存在しない。

通信チャネルを信頼する問題は、何らかのチャネルセキュリティの仕組みを必要とする。
  SIG(0)([RFC2931])やTSIG([RFC2845])のようなDNSトランザクション
  認証の仕組みを適切に使用したり、IPsecを適切に使用すれば充分だろう。
  特定の実装では、OS固有のプロセス間通信の仕組みのような別の選択肢も利用可能かもしれない。
  このチャネルに秘匿性は必要ないが、データの完全性保護とメッセージ認証は必要である。

再帰ネームサーバと通信チャネルの両方を信頼するDNSSEC対応スタブリゾルバは、
  受信した応答メッセージのメッセージヘッダ内にあるAD(Authenticated Data)ビットが設定されているかを調査してもよい。
  再帰ネームサーバが応答の回答部(Answer section)と権威部(Authority section)の
  データ全てについて署名を検証できたのかを判断するヒントとして、スタブリゾルバはこのフラグビットを利用することができる。

何らかの理由により、DNSSEC対応スタブリゾルバと、スタブリゾルバが使用する再帰ネームサーバとの間に信頼関係を築けない場合、
スタブリゾルバが選択可能な方法がもう1つある。
  問合わせメッセージ内のCD (Checking Disabled)ビットを設定することにより、
  自分自身で署名の検証を行えるようにすることである。
  このようにすることで、署名検証を行うスタブリゾルバは、DNSSEC署名の処理を
  通してゾーン管理者と信頼関係を築くことができるようになる。