メインコンテンツまでスキップ

4. Resolving (解決)

本セクションでは、セキュリティ対応リゾルバ機能を含むエンティティの動作について説明します。多くの場合、このような機能はセキュリティ対応再帰的ネームサーバーの一部になります。

4.1. EDNS Support (EDNSサポート)​

セキュリティ対応リゾルバの実装は、EDNS0メッセージサイズ拡張をサポートしなければならず (MUST)、少なくとも1220オクテットのメッセージサイズをサポートしなければならず (MUST)、4000オクテットのメッセージサイズをサポートすべきです (SHOULD)。

4.2. Signature Verification Support (署名検証サポート)​

セキュリティ対応リゾルバは、セクション5で説明されている署名検証メカニズムをサポートしなければならず (MUST)、次の場合を除いて、受信したすべての応答にそれらを適用しなければなりません (MUST)：

  • セキュリティ対応リゾルバがセキュリティ対応再帰的ネームサーバーの一部であり、応答がCDビットが設定されたクエリに代わって再帰の結果である場合
  • 応答が、このクエリの検証を実行しないようにセキュリティ対応リゾルバに指示した何らかの形式のアプリケーションインターフェイスを介して直接生成されたクエリの結果である場合
  • このクエリの検証がローカルポリシーによって無効化されている場合

セキュリティ対応リゾルバの署名検証サポートには、ワイルドカード所有者名 (Wildcard Owner Names) の検証のサポートを含めなければなりません (MUST)。

セキュリティ対応リゾルバは、検証を実行しようとして欠落しているセキュリティRRをクエリしてもかまいません (MAY)。ゾーンカットの親側に存在する欠落しているNSEC RRを取得しようとする場合、セキュリティ対応反復モードリゾルバは、子ゾーンではなく親ゾーンのネームサーバーにクエリしなければなりません (MUST)。

欠落しているDSを取得しようとする場合、セキュリティ対応反復モードリゾルバは、子ゾーンではなく親ゾーンのネームサーバーにクエリしなければなりません (MUST)。

4.3. Determining Security Status of Data (データのセキュリティステータスの決定)​

セキュリティ対応リゾルバは、特定のRRsetが署名されることを期待すべきかどうかを判断できなければなりません (MUST)。セキュリティ対応リゾルバは、4つのケースを区別できなければなりません：

Secure (セキュア): リゾルバが信頼されたセキュリティアンカーからRRsetまでの署名済みDNSKEYおよびDS RRのチェーンを構築できるRRset。この場合、RRsetは署名されているべきであり、署名検証の対象となります。

Insecure (非セキュア): リゾルバが、信頼された開始点からRRsetまでの署名済みDNSKEYおよびDS RRのチェーンがないことを知っているRRset。これは、ターゲットRRsetが未署名ゾーンまたは未署名ゾーンの子孫にある場合に発生する可能性があります。この場合、RRsetは署名されている場合とされていない場合がありますが、リゾルバは署名を検証できません。

Bogus (不正): リゾルバが信頼チェーンを確立できるはずだと信じているが、何らかの理由で検証に失敗する署名、または関連するDNSSEC RRが存在すべきであることを示している欠落データのいずれかにより、確立できないRRset。このケースは攻撃を示している可能性がありますが、設定エラーまたは何らかの形式のデータ破損を示している可能性もあります。

Indeterminate (不確定): リゾルバが必要なDNSSEC RRを取得できないため、RRsetが署名されるべきかどうかを判断できないRRset。これは、セキュリティ対応リゾルバが関連するゾーンのセキュリティ対応ネームサーバーに接続できない場合に発生する可能性があります。

4.4. Configured Trust Anchors (設定済みトラストアンカー)​

セキュリティ対応リゾルバは、少なくとも1つの信頼された公開鍵またはDS RRで設定できなければならず (MUST)、複数の信頼された公開鍵またはDS RRで設定できるべきです (SHOULD)。

セキュリティ対応リゾルバは、このような設定されたトラストアンカーなしでは署名を検証できないため、リゾルバは起動時にそのような鍵を取得するための合理的に堅牢なメカニズムを持つべきです (SHOULD)。

4.5. Response Caching (応答のキャッシング)​

セキュリティ対応リゾルバは、応答のセキュリティステータスに関係なく、名前付きRRsetおよびそれに関連するRRSIG RRとNSEC RRを含む全体の回答を含む単一のアトミックエントリとして各応答をキャッシュすべきです (SHOULD)。

セキュリティ対応リゾルバは、署名するRRsetとは独立してRRSIG RRをキャッシュしてはなりません (MUST NOT)。これにより、攻撃者が古いRRSIGを新しいデータでリプレイできる可能性があります。

4.6. Handling of the CD and AD Bits (CDビットとADビットの処理)​

CDビットは、セキュリティ対応リゾルバが特定のクエリの検証を実行するかどうかを制御します。セキュリティ対応リゾルバは、応答のAnswerおよびAuthorityセクションのすべてのRRsetが認証済みであるとリゾルバが考える場合に限り、応答でADビットを設定しなければなりません (MUST)。

セキュリティ対応でないリゾルバは、応答でADビットを設定してはなりません (MUST NOT)。セキュリティ対応リゾルバは、この仕様で説明されている規則に従ってデータを検証していない限り、ADビットを設定してはなりません (MUST NOT)。

4.7. Caching BAD Data (不正データのキャッシング)​

リゾルバは、「不正」なセキュリティステータスを持つデータを、「良好」なセキュリティステータスを持つデータとは異なる方法でキャッシュしてもかまいません (MAY)。ただし、リゾルバは、次の場合を除いて、不正なセキュリティステータスを持つキャッシュされたデータを使用してはなりません (MUST NOT)：

  • リゾルバがCDビットが設定されたクエリに応答している場合
  • 不正なデータがCDビットが設定されたクエリの結果だった場合
  • ローカルポリシーが明示的に不正なデータの使用を承認している場合

4.8. Synthesized CNAMEs (合成CNAME)​

セキュリティ対応リゾルバは、[RFC2672]で説明されているように合成CNAME RRを処理する際に特別な処理規則を適用しなければなりません (MUST)。リゾルバは、合成CNAMEが署名されることを期待してはなりませんが (MUST NOT)、CNAMEが合成されたDNAME RRを検証しなければなりません (MUST)。

4.9. Stub Resolvers (スタブリゾルバ)​

セキュリティ対応スタブリゾルバは、DNSリゾルバとして機能し、署名検証を実行する能力を持つが、完全なセキュリティ対応再帰的ネームサーバーとして機能しないエンティティです。スタブリゾルバは通常、ほとんどのDNS操作を代わりに実行するために再帰的ネームサーバーに依存します。

4.9.1. Handling of the DO Bit (DOビットの処理)​

セキュリティ対応スタブリゾルバは、応答でDNSSEC RRを受信したいことを示すために、クエリでDOビットを設定すべきです (SHOULD)。

4.9.2. Handling of the CD Bit (CDビットの処理)​

セキュリティ対応スタブリゾルバは、クエリを送信しているネームサーバーに代わって検証を実行させるのではなく、自分自身で検証を実行する意思があることを示すために、クエリでCDビットを設定してもかまいません (MAY)。

4.9.3. Handling of the AD Bit (ADビットの処理)​

セキュリティ対応スタブリゾルバは、応答を送信したネームサーバーがスタブリゾルバに代わってデータを検証したかどうかを示すために、応答のADビットの設定を使用してもかまいません (MAY)。

クエリでCDビットを設定するセキュリティ対応スタブリゾルバは、応答のADビットを無視しなければなりません (MUST)。これは、ネームサーバーがスタブリゾルバに代わって検証を実行しないように明示的に指示されたためです。

に最終更新