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

3. Serving (サービス提供)

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

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

EDNS OPT疑似RRを含まない、またはDOビットがクリアされているDNSクエリを受信したセキュリティ対応ネームサーバーは、RRSIG、DNSKEY、およびNSEC RRを他のRRsetと同様に扱わなければならず (MUST)、以下で説明する追加の処理を実行してはなりません (MUST NOT)。

DNSSECは、DNSメッセージヘッダーに2つの新しいビットを割り当てます：

  • CDビット (Checking Disabled): リゾルバによって制御される
  • ADビット (Authentic Data): ネームサーバーによって制御される

セキュリティ対応ネームサーバーは、クエリからCDビットを対応する応答にコピーしなければなりません (MUST)。セキュリティ対応ネームサーバーは、クエリ内のADビットの設定を無視しなければなりません (MUST)。

3.1. Authoritative Name Servers (権威ネームサーバー)​

EDNS OPT疑似RR DOビットが設定された関連するクエリを受信すると、署名済みゾーンのセキュリティ対応権威ネームサーバーは、次の規則に従って追加のRRSIG、NSEC、およびDS RRを含めなければなりません (MUST)：

  • 応答の認証に使用できるRRSIG RRは、セクション3.1.1の規則に従って応答に含めなければならない (MUST)
  • 認証された非存在証明を提供するために使用できるNSEC RRは、セクション3.1.3の規則に従って自動的に応答に含めなければならない (MUST)
  • DS RRsetまたはDS RRが存在しないことを証明するNSEC RRのいずれかは、セクション3.1.4の規則に従って自動的に委任に含めなければならない (MUST)

3.1.1. Including RRSIG RRs in a Response (レスポンスへのRRSIG RRの追加)​

DOビットが設定されたクエリに応答する場合、セキュリティ対応権威ネームサーバーは、セキュリティ対応リゾルバが応答内のRRsetを認証するために使用できるRRSIG RRを送信しようと試みるべきです (SHOULD)。

規則：

  • 署名されたRRsetをAnswerセクションに配置する場合、ネームサーバーはそのRRSIG RRもAnswerセクションに配置しなければならない (MUST)
  • 署名されたRRsetをAuthorityセクションに配置する場合、ネームサーバーはそのRRSIG RRもAuthorityセクションに配置しなければならない (MUST)
  • 署名されたRRsetをAdditionalセクションに配置する場合、ネームサーバーはそのRRSIG RRもAdditionalセクションに配置しなければならない (MUST)
  • AnswerまたはAuthorityセクションにRRSIG RRを含めるスペースがない場合、ネームサーバーはTCビットを設定しなければならない (MUST)

3.1.2. Including DNSKEY RRs in a Response (レスポンスへのDNSKEY RRの追加)​

DOビットが設定され、署名済みゾーンの頂点 (Apex) でSOAまたはNS RRを要求するクエリに応答する場合、そのゾーンのセキュリティ対応権威ネームサーバーは、Additionalセクションでゾーン頂点DNSKEY RRsetを返してもかまいません (MAY)。

DNSKEY RRsetおよび関連するRRSIG RRは、Additionalセクションに配置される他の情報よりも優先度が低くなります。

3.1.3. Including NSEC RRs in a Response (レスポンスへのNSEC RRの追加)​

DOビットが設定されたクエリに応答する場合、署名済みゾーンのセキュリティ対応権威ネームサーバーは、次の各ケースでNSEC RRを含めなければなりません (MUST)：

No Data (データなし): ゾーンには <SNAME, SCLASS> と完全に一致するRRsetが含まれますが、<SNAME, SCLASS, STYPE> と完全に一致するRRsetは含まれません。

Name Error (名前エラー): ゾーンには、完全一致またはワイルドカード名展開を介して <SNAME, SCLASS> と一致するRRsetが含まれていません。

Wildcard Answer (ワイルドカード回答): ゾーンには <SNAME, SCLASS> と完全に一致するRRsetは含まれませんが、ワイルドカード名展開を介して <SNAME, SCLASS, STYPE> と一致するRRsetが含まれます。

Wildcard No Data (ワイルドカードデータなし): ゾーンには <SNAME, SCLASS> と完全に一致するRRsetは含まれず、ワイルドカード名展開を介して <SNAME, SCLASS> と一致する1つ以上のRRsetが含まれますが、ワイルドカード名展開を介して <SNAME, SCLASS, STYPE> と一致するRRsetは含まれません。

3.1.3.1. Including NSEC RRs: No Data Response (NSEC RRの追加: データなし応答)​

ゾーンに <SNAME, SCLASS> と一致するRRsetが含まれているが、<SNAME, SCLASS, STYPE> と一致するRRsetが含まれていない場合、ネームサーバーは、関連するRRSIG RRと共に <SNAME, SCLASS> のNSEC RRをAuthorityセクションに含めなければなりません (MUST)。

3.1.3.2. Including NSEC RRs: Name Error Response (NSEC RRの追加: 名前エラー応答)​

ゾーンに完全一致またはワイルドカード名展開を介して <SNAME, SCLASS> と一致するRRsetが含まれていない場合、ネームサーバーはAuthorityセクションに次のNSEC RRを含めなければなりません (MUST)：

  • <SNAME, SCLASS> の完全一致が存在しないことを証明するNSEC RR
  • ワイルドカード名展開を介して <SNAME, SCLASS> と一致するRRsetがゾーンに含まれていないことを証明するNSEC RR

3.1.3.3. Including NSEC RRs: Wildcard Answer Response (NSEC RRの追加: ワイルドカード回答応答)​

ゾーンに <SNAME, SCLASS> と完全に一致するRRsetが含まれていないが、ワイルドカード名展開を介して <SNAME, SCLASS, STYPE> と一致するRRsetが含まれている場合、ネームサーバーは、Answerセクションにワイルドカード展開された回答と対応するワイルドカード展開されたRRSIG RRを含めなければならず (MUST)、Authorityセクションに、ゾーンにより近い一致が含まれていないことを証明するNSEC RRを含めなければなりません (MUST)。

3.1.3.4. Including NSEC RRs: Wildcard No Data Response (NSEC RRの追加: ワイルドカードデータなし応答)​

ネームサーバーは、Authorityセクションに次のNSEC RRを含めなければなりません (MUST)：

  • ワイルドカード所有者名でSTYPEと一致するRRsetが存在しないことを証明するNSEC RR
  • より近い一致となるRRsetがゾーンに存在しないことを証明するNSEC RR

3.1.4. Including DS RRs in a Response (レスポンスへのDS RRの追加)​

DS RRは委任ポイントにのみ存在します。委任ポイントのDS RRは、子ゾーンへの認証チェーンを確立します。委任を返すセキュリティ対応ネームサーバーは、関連するRRSIG RRと共にDS RRsetをAuthorityセクションで返そうと試みなければなりません (MUST)。

委任ポイントにDS RRsetが存在しない場合、ネームサーバーは、DS RRsetが存在しないことを証明するNSEC RRを返さなければなりません (MUST)。

3.1.5. Responding to Queries for Type AXFR or IXFR (AXFR/IXFRタイプのクエリへの応答)​

DNSSECは、DNSゾーン転送プロトコルを変更しません。セキュリティ対応権威ネームサーバーは、ゾーン転送に適切なDNSSEC RR（RRSIG、NSEC、DS、およびDNSKEY RR）を含めなければなりません (MUST)。

3.1.6. The AD and CD Bits in an Authoritative Response (権威応答におけるADビットとCDビット)​

セキュリティ対応権威ネームサーバーは、ネームサーバーがAnswerおよびAuthorityセクションのすべてのRRsetを含むゾーンに対して権威があり、すべての必要なRRSIGおよびNSEC RRが含まれている場合を除き、応答のADビットをクリアしなければなりません (MUST)。

セキュリティ対応権威ネームサーバーは、クエリからCDビットを応答にコピーしなければなりません (MUST)。

3.2. Recursive Name Servers (再帰的ネームサーバー)​

セキュリティ対応再帰的ネームサーバーは、セキュリティ対応リゾルバ（セクション4を参照）として機能し、他のリゾルバまたはスタブリゾルバにセキュリティ対応クエリサービスを提供するエンティティです。

3.2.1. The DO Bit (DOビット)​

セキュリティ対応再帰的ネームサーバーは、受信したクエリでDOビットが設定されていた場合、権威ネームサーバーに送信するクエリでDOビットを設定しなければなりません (MUST)。

3.2.2. The CD Bit (CDビット)​

CDビット (Checking Disabled) は、セキュリティ対応再帰的ネームサーバーがDNSSEC検証を実行するかどうかを制御します。CDビットが設定されている場合、セキュリティ対応再帰的ネームサーバーはDNSSEC検証を実行すべきではありません (SHOULD NOT) が、DNSSEC RRはフェッチすべきです (SHOULD)。

3.2.3. The AD Bit (ADビット)​

ADビット (Authentic Data) は、AnswerおよびAuthorityセクションのデータが、そのリゾルバのローカルセキュリティポリシーに従ってセキュリティ対応リゾルバによって検証されたかどうかを示します。

セキュリティ対応再帰的ネームサーバーは、次の場合に応答でADビットを設定しなければなりません (MUST)：

  • AnswerおよびAuthorityセクションのRRsetが正常に検証された
  • または信頼されている上流サーバーからADビットが設定された応答を受信した

3.3. Example DNSSEC Responses (DNSSEC応答の例)​

付録Bには、以下を含むさまざまなシナリオのDNSSEC応答の詳細な例が含まれています：

  • 肯定的な回答
  • 名前エラー
  • データなしエラー
  • 署名済みおよび未署名ゾーンへの委任
  • ワイルドカード展開
に最終更新