ネットワークワーキンググループ R. Arends Request for Comments: 4035 Telematica Instituut 廃止(Obsoletes): 2535, 3008, 3090, 3445, 3655, 3658, R. Austein 3755, 3757, 3845 ISC 更新(Updates): 1034, 1035, 2136, 2181, 2308, 3225, M. Larson 3007, 3597, 3226 VeriSign 分類: 標準化過程(Standards Track) D. Massey Colorado State University S. Rose NIST 2005年3月 DNSセキュリティ拡張のためのプロトコル修正 本文書の位置づけ 本文書はインターネットコミュニティーのためにインターネット標準化過程に あるプロトコルを規定し、その向上のために議論と提案を求めるものである。 このプロトコルの標準化の状況については"Internet Official Protocol Standards"(STD 1)の最新版を参照のこと。本文書の配布は制限されない。 著作権表示 Copyright (C) The Internet Society (2005). 要旨 本文書はDNSセキュリティ拡張(DNSSEC)について記述する文書群の1つである。 DNSセキュリティ拡張は、データ生成元の認証をDNSに提供するリソース レコードと、プロトコル変更を集めたものである。本文書はDNSSECプロトコルの 変更を規定する。本文書は署名付きゾーンの概念と、DNSSECを使用した 名前解決におけるサーバ側およびリゾルバ側の処理の要件を定義する。 これらの手法により、セキュリティ対応リゾルバはDNSリソースレコードと 権威を持つDNSエラー表示の両方を認証可能になる。 本文書はRFC 2535を廃止し、RFC 2535以後の更新全てを取り込んでいる。 Arends, et al. Standards Track [Page 1] RFC 4035 DNSSEC Protocol Modifications March 2005 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. 背景および関連文書 . . . . . . . . . . . . . . . . . . . 4 1.2. 予約語 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. ゾーン署名 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. ゾーンへのDNSKEY RR付加. . . . . . . . . . . . . . . . . 5 2.2. ゾーンへのRRSIG RR付加 . . . . . . . . . . . . . . . . . 5 2.3. ゾーンへのNSEC RR付加. . . . . . . . . . . . . . . . . . 6 2.4. ゾーンへのDS RR付加. . . . . . . . . . . . . . . . . . . 7 2.5. CNAMEリソースレコードの仕様変更. . . . . . . . . . . . . 7 2.6. ゾーンカットに存在するDNSSEC RRタイプ. . . . . . . . . . 8 2.7. 安全なゾーンの例 . . . . . . . . . . . . . . . . . . . . 8 3. サーバ側処理 . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. 権威ネームサーバ . . . . . . . . . . . . . . . . . . . . 9 3.1.1. 応答へのRRSIG RR付加 . . . . . . . . . . . . . . 10 3.1.2. 応答へのDNSKEY RR付加. . . . . . . . . . . . . . 11 3.1.3. 応答へのNSEC RR付加. . . . . . . . . . . . . . . 11 3.1.4. 応答へのDS RR付加. . . . . . . . . . . . . . . . 14 3.1.5. タイプAXFRまたはIXFRへの問合わせに対する応答 . . 15 3.1.6. 権威を持つ応答におけるADビットとCDビット . . . . 16 3.2. 再帰ネームサーバ . . . . . . . . . . . . . . . . . . . . 17 3.2.1. DOビット . . . . . . . . . . . . . . . . . . . . 17 3.2.2. CDビット . . . . . . . . . . . . . . . . . . . . 17 3.2.3. ADビット . . . . . . . . . . . . . . . . . . . . 18 3.3. DNSSEC応答の例 . . . . . . . . . . . . . . . . . . . . . 19 4. リゾルバ側処理 . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1. EDNSのサポート . . . . . . . . . . . . . . . . . . . . . 19 4.2. 署名検証のサポート . . . . . . . . . . . . . . . . . . . 19 4.3. データのセキュリティ状態の判定 . . . . . . . . . . . . . 20 4.4. 信頼のアンカーの設定 . . . . . . . . . . . . . . . . . . 21 4.5. 応答のキャッシュ . . . . . . . . . . . . . . . . . . . . 21 4.6. CDビットおよびADビットの処理 . . . . . . . . . . . . . . 22 4.7. 不良キャッシュ . . . . . . . . . . . . . . . . . . . . . 22 4.8. 合成されたCNAMEの処理. . . . . . . . . . . . . . . . . . 23 4.9. スタブリゾルバ . . . . . . . . . . . . . . . . . . . . . 23 4.9.1. DOビットの処理 . . . . . . . . . . . . . . . . . 24 4.9.2. CDビットの処理 . . . . . . . . . . . . . . . . . 24 4.9.3. ADビットの処理 . . . . . . . . . . . . . . . . . 24 5. DNS応答の認証. . . . . . . . . . . . . . . . . . . . . . . . . 25 5.1. セキュリティの島に関する特別な考慮点 . . . . . . . . . . 26 5.2. 参照の認証 . . . . . . . . . . . . . . . . . . . . . . . 26 5.3. RRSIG RRを使用したRRsetの認証. . . . . . . . . . . . . . 28 5.3.1. RRSIG RRの有効性検査 . . . . . . . . . . . . . . 28 5.3.2. 署名付きデータの再構成 . . . . . . . . . . . . . 29 5.3.3. 署名の検査 . . . . . . . . . . . . . . . . . . . 31 5.3.4. ワイルドカード展開されたRRsetを含む 肯定応答の認証 . . . . . . . . . . . . . . . . . 32 Arends, et al. Standards Track [Page 2] RFC 4035 DNSSEC Protocol Modifications March 2005 5.4. 不在証明 . . . . . . . . . . . . . . . . . . . . . . . . 32 5.5. 署名が検証できない場合のリゾルバの振る舞い . . . . . . . 33 5.6. 認証の例 . . . . . . . . . . . . . . . . . . . . . . . . 33 6. IANAに関する考慮点 . . . . . . . . . . . . . . . . . . . . . . 33 7. セキュリティに関する考慮点 . . . . . . . . . . . . . . . . . . 33 8. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 9. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.1. 必須の参考文献 . . . . . . . . . . . . . . . . . . . . . 34 9.2. 有用な参考文献 . . . . . . . . . . . . . . . . . . . . . 35 A. 署名付きゾーンの例 . . . . . . . . . . . . . . . . . . . . . . 36 B. 応答の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 B.1. 正常な回答 . . . . . . . . . . . . . . . . . . . . . . . 41 B.2. 名前エラー . . . . . . . . . . . . . . . . . . . . . . . 43 B.3. 該当データ無しエラー . . . . . . . . . . . . . . . . . . 44 B.4. 署名付きゾーンへの参照 . . . . . . . . . . . . . . . . . 44 B.5. 署名無しゾーンへの参照 . . . . . . . . . . . . . . . . . 45 B.6. ワイルドカード展開 . . . . . . . . . . . . . . . . . . . 46 B.7. ワイルドカードによる該当データ無しエラー . . . . . . . . 47 B.8. 子ゾーンにおけるDSの該当データ無しエラー . . . . . . . . 48 C. 認証の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 C.1. 回答の認証 . . . . . . . . . . . . . . . . . . . . . . . 49 C.1.1. 例示したDNSKEY RRの認証. . . . . . . . . . . . . 49 C.2. 名前エラー . . . . . . . . . . . . . . . . . . . . . . . 50 C.3. 該当データ無しエラー . . . . . . . . . . . . . . . . . . 50 C.4. 署名付きゾーンへの参照 . . . . . . . . . . . . . . . . . 50 C.5. 署名無しゾーンへの参照 . . . . . . . . . . . . . . . . . 51 C.6. ワイルドカード展開 . . . . . . . . . . . . . . . . . . . 51 C.7. ワイルドカードによる該当データ無しエラー . . . . . . . . 51 1. はじめに 本文書はDNSセキュリティ拡張(DNSSEC)について規定する文書群の1つである。 DNSセキュリティ拡張は、データ生成元の認証をDNSに提供するリソース レコードと、プロトコル変更を集めたものである。本文書はDNSSECプロトコルの 変更を定義する。セクション2で署名付きゾーンを定義し、ゾーン署名の要件を 列挙する。セクション3で署名付きゾーンを処理するために必要な権威ネーム サーバの振る舞いの変更を規定する。セクション4でセキュリティ対応リゾルバ 機能を持つものの振る舞いを規定する。最後にセクション5でDNSSEC RRを 使用して応答を認証する方法を定義する。 Arends, et al. Standards Track [Page 3] RFC 4035 DNSSEC Protocol Modifications March 2005 1.1. 背景および関連文書 本文書はDNSSECを定義する一連の文書群の一部であるから、読者は他の文書も 併せて読むべきである。 [RFC4033]はDNSSECを紹介し、DNSSECで共通に使用される用語を定義する。 読者はこの文書を理解しているものとする。[RFC4033]は本文書と関連文書 によって更新または廃止される文書の一覧も提供する。 [RFC4034]はDNSSECリソースレコードを定義する。 また読者は[RFC1034]、[RFC1035]が規定する基本的なDNSの概念と、その後それを 更新した文書群、特に[RFC2181]と[RFC2308]を理解しているものとする。 本文書はDNSSECプロトコル処理を定義する。 1.2. 予約語 本文書におけるキーワード"しなければならない(MUST)"、"してはならない (MUST NOT)"、"要求される(REQUIRED)"、"するものとする(SHALL)"、"しな いものとする(SHALL NOT)"、"すべきである(SHOULD)"、"すべきでない (SHOULD NOT)"、"推奨される(RECOMMENDED)"、"してもよい/することがで きる(MAY)"、"任意である(OPTIONAL)"は、[RFC2119]に記述されているとお りに解釈される。 2. ゾーン署名 DNSSECは署名付きゾーンの概念を導入する。署名付きゾーンは、それぞれ セクション2.1、2.2、2.3および2.4で規定する規則に従い、DNSKEY(DNS Public Key)、 RRSIG(Resource Record Signature)、NSEC(Next Secure)および (任意で)DS(Delegation Signer)レコードをゾーンに加える。本セクションで 規定する規則に従うレコードを持たないゾーンは署名無しゾーンである。 DNSSECはCNAMEリソースレコード([RFC1035])の定義変更を必要とする。 セクション2.5でCNAME RRの仕様変更を定義しており、これによりCNAME RRと 同じ所有者名のRRSIGおよびNSEC RRが存在できるようになる。 DNSSECは新しいRRタイプであるNSECおよびDSの使用について規定する。 この2つのRRはゾーンカットの親側(すなわち委任点)で使用することができる。 これはゾーンカットの親側にデータを置くことを禁止した一般的な規則の 例外である。セクション2.6でこの変更について規定する。 Arends, et al. Standards Track [Page 4] RFC 4035 DNSSEC Protocol Modifications March 2005 2.1. ゾーンへのDNSKEY RR付加 ゾーン管理者は、ゾーンに署名するために1つ以上の公開/秘密鍵ペアを生成し、 秘密鍵(複数も可)を使用してゾーン内の権威を持つRRsetに署名する。 ゾーンは、ゾーン内のRRSIG RR生成に使用した秘密鍵それぞれについて、 対応する公開鍵を保存したDNSKEY RRを持つべきである(SHOULD)。ゾーン鍵に なっているDNSKEY RRは、RDATAフィールドのゾーン鍵フラグに対応する ビットを設定しなければならない(MUST)([RFC4034]のセクション2.1.1参照)。 他のDNS処理で使用する公開鍵をゾーン鍵フラグを設定しないDNSKEY RRに 保存してもよい(MAY)が、RRSIGの検証に使用してはならない(MUST NOT)。 ゾーン管理者が署名付きゾーンをセキュリティの島以外の形で使用したい 場合は、安全なエントリー地点の役割を果たすDNSKEY RRをゾーン頂点に 最低1つ持たなければならない(MUST)。この安全なエントリー地点は、 親側にある対応するDS RR([RFC4034]参照)により、安全な委任先として 使用することができる。 2.2. ゾーンへのRRSIG RR付加 署名付きゾーン内にある権威を持つRRsetそれぞれについて、以下の要件を満たす RRSIGレコードが最低1つは存在しなければならない(MUST)。 ・所有者名がRRsetと等しい。 ・クラスがRRsetのクラスと等しい。 ・署名対象タイプフィールドの内容がRRsetタイプと等しい。 ・オリジナルTTLフィールドの値がRRsetのTTLと等しい。 ・TTLがRRsetのTTLと等しい。 ・ラベルフィールドの値がRRsetの所有者名のラベル数と等しい。ただし ヌルルート(null root)ラベルと、もし最も左側のラベルがワイルドカードで あった場合、それは勘定に含めない。 ・署名者名フィールドの内容がRRsetを持つゾーン名と等しい。 ・アルゴリズムフィールド、署名者名フィールド、鍵タグフィールドの 内容がゾーン頂点にある一つのゾーン鍵のDNSKEYレコードを特定している。 あるRRsetに関するRRSIG RRを生成する処理は[RFC4034]で規定する。 1つのRRsetが複数のRRSIG RRを持ってもよい(MAY)。RRSIG RRは署名対象のRRsetと 強く結びついているため、他のDNS RRタイプと異なりRRsetを形成しないことに 注意してもらいたい。特に同じ所有者名を持つ複数のRRSIG RRのTTL値は [RFC2181]が規定する規則に従わない。 Arends, et al. Standards Track [Page 5] RFC 4035 DNSSEC Protocol Modifications March 2005 RRSIG RRへの署名は何ら価値を付加しないし、処理で無限ループが発生する ので、RRSIG RR自身は署名されてはならない(MUST NOT)。 ゾーン頂点にあるNS RRsetは署名付きでなければならない(MUST)が、 委任点にあるNS RRset(親ゾーン側にある、子ゾーンのネームサーバに名前を 委任するNS RRset)は署名されてはならない(MUST NOT)。委任に伴う グルーアドレスRRsetは署名されてはならない(MUST NOT)。 各RRsetに対して、ゾーン頂点にあるDNSKEY RRsetに含まれるそれぞれの アルゴリズムのDNSKEYのうち、少なくとも1つを使用して生成したRRSIGが 存在しなければならない(MUST)。ゾーン頂点にあるDNSKEY RRset自身は、 (もしあれば)親側の委任点に存在するDS RRsetが指定するそれぞれの アルゴリズムによって署名されなければならない(MUST)。 2.3. ゾーンへのNSEC RR付加 ゾーン内において、権威を持つデータまたは委任点のNS RRsetを持つ各所有者名は NSECリソースレコードを持たなければならない(MUST)。NSEC RRの書式と、 与えられた名前に対するNSEC RRの生成処理は[RFC4034]で規定される。 NSEC RRのTTL値は、ゾーンのSOA RRの最小TTL値フィールドの値と同じである べき(SHOULD)である。 特定の所有者名に対してNSECレコード(と対応するRRSIG RRset)だけしか 存在しない状態があってはならない(MUST NOT)。すなわち、ゾーン署名前は RRsetの所有者名ではなかった名前ノードに対して、署名処理でNSECまたは RRSIG RRを生成してはならない(MUST NOT)。この主な理由は、同じゾーンに 署名がある場合と無い場合で名前空間の一貫性を持たせたいという要望と、 セキュリティ非対応再帰ネームサーバで応答の不整合が生じるリスクを 減らしたいという要望のためである。 署名付きゾーンにある各NSECリソースレコードのタイプビットマップは、 NSECレコード自身と対応するRRSIGレコードの存在を示さなければならない (MUST)。 RRSIGレコードを必要とする所有者名の集合と、NSECレコードを必要とする 所有者名の集合の違いはわずかなものであり、また強調すべきところでもある。 RRSIGレコードは権威を持つRRset全ての所有者名に対して存在する。 NSECレコードは、署名付きゾーンが権威を持つ全ての名前の所有者名、および 署名付きゾーンから子ゾーンへの委任を行う所有者名に対して存在する。 (親ゾーンにある)グルーアドレスRRsetの所有者名に対しては、NSECレコードも RRSIGレコードも存在しない。しかし、この違いが明らかになるのはゾーン署名 処理の間だけであることに注意してもらいたい。NSEC RRsetは権威を持つ データであるため署名されるからである。したがって、署名付き ゾーンにおいてはNSEC RRsetを持つ所有者名は同様にRRSIG RRを持つ。 Arends, et al. Standards Track [Page 6] RFC 4035 DNSSEC Protocol Modifications March 2005 委任点におけるNSEC RRのビットマップには特別な注意が必要である。 委任を行うNS RRsetと、親ゾーンが権威を持つデータを保持する全RRsetに 対応するビットが設定されなければならない(MUST)。また親ゾーンが 権威を持たないNS RRset以外のRRsetに対応するビットはクリアされなければ ならない(MUST)。 2.4. ゾーンへのDS RR付加 DSリソースレコードはDNSゾーン間に認証の連鎖を構築する。子ゾーンが署名付き である場合、委任点にDS RRsetが存在すべき(SHOULD)である。DS RRsetは複数の レコードを持ってもよく(MAY)、各レコードはそれぞれ子ゾーンの公開鍵を 参照し、その公開鍵を使用して子ゾーン内のRRSIGを検証する。ゾーン内の 全てのDS RRsetは署名付きでなければならず(MUST)、またDS RRsetはゾーン頂点に 存在してはならない(MUST NOT)。 DS RRは子ゾーンの頂点にあるDNSKEY RRsetに含まれるDNSKEY RRを参照すべき (SHOULD)であり、また子ゾーンの頂点にあるDNSKEY RRsetは対応する秘密鍵で 署名されるべき(SHOULD)である。この条件を満たさないDS RRは検証には使用 できない。ただしDS RRと対応するDNSKEY RRは異なるゾーンに存在すること、 またDNSは緩やかにしか一貫性を持たないことから、一時的な不整合は 発生し得る。 DS RRsetのTTLは委任を行うNS RRset(すなわち、DS RRsetを持つゾーン内にある NS RRset)のTTLと一致すべき(SHOULD)である。 DS RRを生成するためには、子ゾーンにある対応するDNSKEY RRの識別が必要 である。これは親ゾーンと子ゾーン間でやりとりが発生することを意味する。 このやりとりは運用上の問題であり、本文書の対象範囲ではない。 2.5. CNAMEリソースレコードの仕様変更 署名付きゾーンにCNAME RRsetが存在する場合、CNAMEを持つ名前に対して 適切なRRSIGおよびNSEC RRsetが要求される(REQUIRED)。同じ名前に対して 安全な動的更新([RFC3007])を行うKEY RRsetを設定することもできる。 しかし同じ名前に対してそれ以外のタイプが存在してはならない(MUST NOT)。 これは[RFC1034]が規定するオリジナルのCNAMEの定義を変更するものである。 オリジナルのCNAME RRの定義では、CNAMEレコードと他のタイプが共に存在する ことは禁止されていた。しかし署名付きゾーンは権威を持つ名前全てについて NSECおよびRRSIG RRを必要とする。この矛盾を解決するために、本仕様でCNAME リソースレコードの定義を変更し、CNAMEとNSECおよびRRSIG RRが共存できる ようにする。 Arends, et al. Standards Track [Page 7] RFC 4035 DNSSEC Protocol Modifications March 2005 2.6. ゾーンカットに存在するDNSSEC RRタイプ DNSSECは、ゾーンカットの親側に存在できるという点で例外的な、新しい 2つのRRタイプを導入した。ゾーンカットの親側(委任点)では、所有者名に対して NSEC RRが要求される(REQUIRED)。委任するゾーンが署名付きであり、また 親側との認証の連鎖を形成したい場合にはDS RRが存在する場合もある。 オリジナルのDNS仕様([RFC1034])では、ゾーンカットの親側に存在できるのは NS RRsetだけだと規定しているが、これらは例外である。 ゾーンカットの親側にNSECおよびDS RRタイプが存在できるように、本仕様は オリジナルのDNS仕様を更新する。NSECおよびDS RRsetがゾーンカットの親側に 存在する場合、これらのRRsetは親が権威を持つ。 2.7. 安全なゾーンの例 付録Aに小規模な署名付きゾーン一式の例を示す。 3. サーバ側処理 本セクションでは、セキュリティ対応ネームサーバ機能を持つものの 振る舞いを規定する。多くの場合、その機能はセキュリティ対応再帰ネーム サーバの一部だが、セキュリティ対応権威ネームサーバも幾つか同じ要件を持つ。 セキュリティ対応再帰ネームサーバ固有の機能についてはセクション3.2で 規定する。またセキュリティ対応権威サーバ固有の機能については セクション3.1で規定する。 以下の記述において、[RFC1034]と同様に、用語"SNAME"、"SCLASS"および "STYPE"を使用する。 セキュリティ対応ネームサーバはEDNS0([RFC2671])メッセージサイズ拡張を サポートしなければならない(MUST)。少なくとも1220オクテットのメッセージ サイズをサポートしなければならず(MUST)、4000オクテットのメッセージ サイズをサポートすべき(SHOULD)である。IPv6パケットは発信元ホストだけが フラグメント化できるので、セキュリティ対応ネームサーバはパスMTUが 既知でない場合に、IPv6で転送されるUDPデータグラムが必要に応じて最小の IPv6 MTUでフラグメント化されることを保証する処理手順をふむべき(SHOULD) である。パケットサイズとフラグメンテーションに関する詳細な検討については [RFC1222]、[RFC2460]および[RFC3226]を参照のこと。 Arends, et al. Standards Track [Page 8] RFC 4035 DNSSEC Protocol Modifications March 2005 EDNS OPT擬似RRを持たない、またはDOビットがクリアされたDNS問合わせを 受信したセキュリティ対応ネームサーバは、RRSIG、DNSKEYおよびNSEC RRを DNSSEC RRset以外のRRsetのように扱わなければならず(MUST)、以下に規定する 付加的な処理を実行してはならない(MUST NOT)。DS RRタイプは委任点の 親ゾーンにしか存在しないという特殊な性質があるため、DS RRは常に セクション3.1.4.1で規定する特別な処理を必要とする。 セキュリティ対応ネームサーバが明示的なセキュリティRRの問合わせを 受信し、その問合わせ内容と自身が管理する複数のゾーンの内容が一致 する場合(例えば、サーバがゾーンの親側と子側両方で権威を持つ場合に、 委任点の上、下両方に存在するNSECおよびRRSIG RRの問合わせを受けた 場合)、サーバは一貫性をもって振る舞うべきである。 ネームサーバへの問合わせに対して応答が常に一貫しているならば、 ネームサーバは以下のうち1つを返してもよい(MAY)。 ・委任点の上に存在するRRset ・委任点の下に存在するRRset ・委任点の上、下にあるRRset両方 ・回答部を空(レコードなし)にして返す ・それ以外の応答 ・エラー DNSSECはDNSメッセージヘッダー内に2つの新しいビットを割り当てる。 CD(Checking Disabled)ビットとAD(Authentic Data)ビットである。 CDビットはリゾルバが制御する。セキュリティ対応ネームサーバは 問合わせのCDビットを対応する応答にコピーしなければならない(MUST)。 ADビットはネームサーバが制御する。セキュリティ対応ネームサーバは 問合わせに含まれるADビットを無視しなければならない(MUST)。 これらのビットに関する振る舞いの詳細については、セクション 3.1.6、3.2.2、3.2.3、4および4.9を参照のこと。 セキュリティ対応ネームサーバが[RFC2672]の規定にしたがってDNAMEから CNAME RRを合成する場合、合成したCNAME RRに対して署名を生成すべきでは ない(SHOULD NOT)。 3.1. 権威ネームサーバ EDNS([RFC2671])のOPT擬似RR DOビット([RFC3225])が設定された適切な問合わせを 署名付きゾーンのセキュリティ対応権威ネームサーバが受信したら、以下の規則に 従って追加のRRSIG、NSECおよびDS RRを応答に付加しなければならない(MUST)。 ・応答を認証可能なRRSIG RRをセクション3.1.1の規則に従って応答に 付加しなければならない(MUST)。 Arends, et al. Standards Track [Page 9] RFC 4035 DNSSEC Protocol Modifications March 2005 ・不在証明を提供可能なNSEC RRをセクション3.1.3の規則に従って自動的に 応答に付加しなければならない(MUST)。 ・DS RRまたはDS RRが存在しないことを証明するNSEC RRをセクション3.1.4の 規則にしたがって自動的に参照(referral)に付加しなければならない(MUST)。 これらの規則は、リソースレコードの存在または不在に関する情報を伝える 応答にだけ適用される。すなわち、これらの規則はRCODE 4("Not Implemented")や RCODE 5("Refused")を禁止するものではない。 DNSSECはDNSゾーン転送プロトコルを変更しない。セクション3.1.5で ゾーン転送に関する要件について論じる。 3.1.1. 応答へのRRSIG RR付加 セキュリティ対応権威ネームサーバがDOビットが設定された問合わせに応答 する場合、セキュリティ対応リゾルバが応答に含まれるRRsetの認証に使用 できるように、RRSIG RRの送信を試みるべき(SHOULD)である。ネームサーバは、 応答にRRsetとそのRRsetのRRSIGを一緒に付加するためにあらゆる試みをすべき である(SHOULD)。応答へのRRSIG RR付加は以下の規則に従う。 ・回答部(Answer section)に署名付きRRsetを付加する場合、ネームサーバは そのRRSetのRRSIG RRも回答部に付加しなければならない(MUST)。他に付加され なければならないRRsetよりも、RRSIG RRの方が優先度が高い。容量的に RRSIG RRを付加できない場合、ネームサーバはTCビットを設定しなければ ならない(MUST)。 ・権威部(Authority section)に署名付きRRsetを付加する場合、ネーム サーバはそのRRSetのRRSIG RRも権威部に付加しなければならない(MUST)。 他に付加されなければならないRRsetよりも、RRSIG RRの方が優先度が高い。 容量的にRRSIG RRを付加できない場合、ネームサーバはTCビットを設定 しなければならない(MUST)。 ・付加情報部(Additional section)に署名付きRRsetを付加する場合、 ネームサーバはそのRRSetのRRSIG RRも付加情報部に付加しなければならない (MUST)。容量的にRRsetとそのRRSetのRRSIG RR両方が付加できない場合、 ネームサーバはRRsetだけを残してRRSIG RRを除外してもよい(MAY)。 この場合、ネームサーバはRRSIG RRが入らなかったというだけの理由で TCビットを設定してはならない(MUST NOT)。 Arends, et al. Standards Track [Page 10] RFC 4035 DNSSEC Protocol Modifications March 2005 3.1.2. 応答へのDNSKEY RR付加 セキュリティ対応権威ネームサーバが、署名付きゾーンの頂点にあるSOAまたは NS RRに対する、DOビットが設定された問合わせに応答する場合、ゾーン頂点に あるDNSKEY RRsetを付加情報部に入れて返してもよい(MAY)。この場合、 DNSKEY RRsetとRRSIG RRは付加情報部に入れられるべき他の情報よりも優先度は 低い。DNSKEY RRsetとそのRRsetのRRSIG RRの付加に充分な容量が応答 メッセージに無い場合、ネームサーバはDNSKEY RRsetを応答に付加すべきではない (SHOULD NOT)。DNSKEYとそのDNSKEYのRRSIG RRの付加に充分な容量が無い場合、 ネームサーバは両RRを除外しなければならない(MUST)。また、これらのRRが 入らなかったという理由だけでTCビットを設定してはならない(MUST NOT) (セクション3.1.1参照)。 3.1.3. 応答へのNSEC RR付加 署名付きゾーンのセキュリティ対応権威ネームサーバが、DOビットが設定された 問合わせに応答する場合、以下の場合それぞれについてNSEC RRを付加 しなければならない(MUST)。 該当データ無し(No Data): ゾーンはに完全一致するRRsetを 持つが、に完全一致するRRsetは存在しない。 名前エラー(Name Error): ゾーンにはに完全一致するRRsetも ワイルドカード展開により一致するRRsetも存在しない。 ワイルドカードによる回答(Wildcard Answer): ゾーンにに 完全一致するRRsetは存在しないが、ワイルドカード展開により に一致するRRsetが存在する。 ワイルドカードによる該当データ無し(Wildcard No Data): ゾーンにはに完全一致するRRsetが存在しない。ワイルド カード展開をするとに一致する1つ以上のRRsetが存在するが、 に一致するRRsetは存在しない。 それぞれの場合について、ネームサーバはゾーン内にに 完全一致するものが存在しないこと、またネームサーバが返した応答が(NSECに より)与えられたゾーンデータにより正しいことを証明するため、NSEC RRを応答 に付加する。 Arends, et al. Standards Track [Page 11] RFC 4035 DNSSEC Protocol Modifications March 2005 3.1.3.1. NSEC RRの付加: "該当データ無し"応答の場合 ゾーン内にに一致するRRsetは存在するが、 に一致するRRsetは存在しない場合、ネームサーバは 応答の権威部にに関するNSEC RRとそのRRのRRSIG RRを共に 付加しなければならない(MUST)(セクション3.1.1参照)。容量的にNSEC RR またはそのRRのRRSIG RRが付加できない場合、ネームサーバはTCビットを 設定しなければならない(MUST)(セクション3.1.1参照)。 問合わせ対象の名前は存在しているので、この問合わせに対してワイルドカード 展開は行われない。また問合わされたRRタイプが存在しないことを証明 するためには単一の署名付きNSEC RRがあれば充分である。 3.1.3.2. NSEC RRの付加: "名前エラー"応答の場合 ゾーンにに完全一致するRRsetもワイルドカード展開により 一致するRRsetも存在しない場合、ネームサーバは以下のNSEC RRとそのRRの RRSIG RRを権威部に付加しなければならない(MUST)。 ・に完全一致するRRsetが存在しないことを証明するNSEC RR。 ・ワイルドカード展開によりに一致するRRsetが存在しない ことを証明するNSEC RR。 場合によっては単一のNSEC RRが上記2つの内容を証明することもある。 その場合、ネームサーバはNSEC RRとそのRRのRRSIG RRをそれぞれ1つだけ 権威部に付加すべきである(SHOULD)。 容量的にNSEC RRとRRSIG RRが付加できない場合、ネームサーバはTCビットを 設定しなければならない(MUST)(セクション3.1.1参照)。 NSEC RRとRRSIG RRを応答の権威部に付加する際に、これらの所有者名は ワイルドカード展開されない。 この形態の応答をする場合、SNAMEがゾーン内における空の非終端名(RRsetの 所有者名になっていないが、1つ以上のRRsetの親になっている名前)に対応する 場合もあることに注意してもらいたい。 3.1.3.3. NSEC RRの付加: "ワイルドカードによる回答"応答の場合 ゾーンにに完全一致するRRsetは存在しないが、ワイルドカード 展開によりに一致するRRsetが存在する場合、 ネームサーバは応答の回答部にワイルドカード展開後の回答とRRSIG RRを 付加しなければならず(MUST)、また権威部にはゾーン内にに より良く一致するRRsetが無いことを証明するNSRC RRとそのRRのRRSIG RRを 付加しなければならない(MUST)。容量的にNSEC RRとそのRRのRRSIG RRが 付加できない場合、ネームサーバはTCビットを設定しなければならない (MUST)(セクション3.1.1参照)。 Arends, et al. Standards Track [Page 12] RFC 4035 DNSSEC Protocol Modifications March 2005 3.1.3.4. NSEC RRの付加: "ワイルドカードによる該当データ無し"応答の場合 これは先に説明した状況の組み合わせである。すなわち、ゾーンには に完全一致するRRsetが存在しないが、ワイルドカード展開を するとに一致する1つ以上のRRsetが存在する。しかしそれでも STYPEに一致するRRsetは存在しないという場合である。この場合、ネーム サーバは応答の権威部に以下の条件を満たすNSEC RRとそのRRのRRSIG RRを 共に付加しなければならない(MUST)。 ・ワイルドカードによりに一致するワイルドカード所有者名 を持つRRsetの中でSTYPEに一致するものは無いことを証明するNSEC RR。 ・ゾーン内ににより良く一致するRRsetは存在しないことを 証明するNSEC RR。 場合によっては単一のNSEC RRが上記2つの内容を証明することもある。 その場合、ネームサーバはNSECC RRとRRSIG RRをそれぞれ1つだけ権威部に 含めるべきである(SHOULD)。 NSEC RRとRRSIG RRを応答の権威部に付加する際に、これらの所有者名は ワイルドカード展開されない。 容量的にNSEC RRとRRSIG RRが付加できない場合、ネームサーバはTCビットを 設定しなければならない(MUST)(セクション3.1.1参照)。 3.1.3.5. 適切なNSEC RRの発見 先に説明したように、特定のSNAMEに一致するRRsetが存在しないことを証明する NSEC RRを、セキュリティ対応ネームサーバが付加しなければならない幾つかの 状況が存在する。権威を持つゾーン内でそのようなNSEC RRを発見する処理は、 少なくとも概念的には簡単である。以下の議論において、ネームサーバはSNAMEに 一致するRRsetが存在しないゾーンに対して権威を持つものとする。以下に示す アルゴリズムは、内容を明確にするために書かれたものであり、効率よく処理 することを目的に書かれたものではない。 名前Nに一致するRRsetがゾーンZに存在しないことを証明するNSECを発見する には、まずZ内の全RRsetの所有者名から重複する名前を除外した上で、所有者名の 並びSを構築し、それを正規順序([RFC4034])で並べ替える。次にSの中にNが 存在していたらその直前に順序づけられていたであろう名前Mを発見する。 このMが、所有者名Nを持つRRsetが存在しないことを証明するNSEC RRの所有者名 になる。 Arends, et al. Standards Track [Page 13] RFC 4035 DNSSEC Protocol Modifications March 2005 展開可能なワイルドカードの範囲に与えられた名前が含まれないことを証明する NSEC RRを発見するアルゴリズムは先のアルゴリズムと似ているが、追加の 処理を必要とする。より正確に書くと、展開可能なワイルドカード名の中に 一致するRRsetが存在しないことを証明するNSECを発見するアルゴリズムは、 他の特定の所有者名を持つRRsetが存在しないことを証明するNSEC RRを発見する アルゴリズムと全く同じである。存在しないのは、適用可能なワイルドカードが 存在しないことを判定する方法である。実際にはこの判定は容易である。 権威ネームサーバは[RFC1034]のセクション4.3.2で規定する通常の名前解決 (lookup)アルゴリズムの(1)(c)の処理で、展開すれば一致するワイルドカードが 存在するかどうかを既に検査済みだからである。 3.1.4. 応答へのDS RR付加 セキュリティ対応権威ネームサーバがDOビットが設定された問合わせに対して 参照を返す場合、NS RRsetに加えてDNSSECデータを付加する。 委任点にDS RRsetが存在する場合、ネームサーバはNS RRsetに加えて、 DS RRsetとそのRRsetのRRSIG RRを共に権威部に付加しなければならない(MUST)。 委任点にDS RRsetが存在しない場合、ネームサーバはNS RRsetに加えて、 DS RRsetが存在しないことを証明するNSEC RRとそのRRのRRSIG RRを共に 返さなければならない(MUST)。ネームサーバはまずNS RRsetを付加し、 その後にNSEC RRsetとそのRRsetのRRSIG RRを付加しなければならない(MUST)。 DS、NSECおよびRRSIG RRを付加することにより、参照メッセージのサイズは大きく なるため、幾つかまたは全てのグルーRRが省略されてしまう場合がある。 容量的にDS RRまたはNSEC RRとそのRRのRRSIG RRが付加できない場合、ネーム サーバはTCビットを設定しなければならない(MUST)(セクション3.1.1参照)。 3.1.4.1. DS RRへの問合わせに対する応答 DSリソースレコードタイプは、ゾーンカットの親ゾーン側にしか存在しない 点で特殊である。例えば"foo.example"の委任に関するDS RRsetは、 "foo.example"ゾーンではなく"example"ゾーンに保存される。 この特殊性により、ネームサーバとリゾルバの双方がDS RRを処理する際に 特別な処理規則を必要とする。通常のDNS規則では子ゾーンのネームサーバは ゾーンカットで権威を持つ名前だが、その子ゾーンはDS RRsetを持たないから である。 Arends, et al. Standards Track [Page 14] RFC 4035 DNSSEC Protocol Modifications March 2005 セキュリティ対応リゾルバが委任点にあるDS RRを必要に応じて検索する場合、 親ゾーンに問合わせを送信する(セクション4.2参照)。しかし、その処理に セキュリティ非対応リゾルバが関与する場合(例えば、ネットワーク環境のために セキュリティ対応リゾルバがセキュリティ非対応再帰ネームサーバを通して 問合わせを送信しなければならない場合が考えられる)に混乱が生じるのを 避けるために、特別な規則が必要である。本セクションの残りで、この問題を 避けるためにセキュリティ対応ネームサーバがDSの問合わせをどう処理するかを 規定する。 セキュリティ対応ネームサーバが特別な処理を必要とするのは、以下の条件が 全て満たされた場合だけである。 ・ネームサーバがゾーンカットにあるDS RRsetの問合わせを受信した。 ・ネームサーバは子ゾーンに対して権威を持つ。 ・ネームサーバは親ゾーンに対して権威を持たない。 ・ネームサーバは再帰検索を行わない。 他の場合は全て、ネームサーバが別の手段でDS RRsetを得られるか、 DNSSEC処理規則以前の段階でDS RRsetが得られないことがわかっているかの どちらかである。したがってネームサーバはDS RRsetか通常の処理規則に 従ったエラー応答を返すことができる。 しかし上記の条件が全て満たされた場合、ネームサーバはSNAMEに対して権威を 持つが、問い合わされたRRsetを提供することができない。この場合、 ネームサーバは子ゾーンの頂点にDS RRsetが存在しないことを示す権威を持つ "データ無し"応答を返さなければならない(MUST)。そのような応答の例については 付録B.8を参照のこと。 3.1.5. タイプAXFRまたはIXFRへの問合わせに対する応答 DNSSECはDNSゾーン転送処理を変更しない。署名付きゾーンはRRSIG、DNSKEY、 NSECおよびDSリソースレコードを持つが、これらのレコードはゾーン転送処理の 中では特別な意味を持たない。 権威ネームサーバは、ゾーン転送送信前またはゾーン転送受信後に、ゾーンが 適切に署名されているかを検証しなくてもよい。しかし、セクション2で規定する 署名の要件をゾーンが満たさない場合、権威ネームサーバはゾーン転送処理全てを 拒否してもよい(MAY)。ゾーン転送の主要な目的は、全ての権威ネームサーバが 同一のゾーンコピーを持つことを保証することである。ゾーン検証の実行を 選択した権威ネームサーバは、RRへの問合わせを選択的に拒否したり受容したり してはならない(MUST NOT)。 Arends, et al. Standards Track [Page 15] RFC 4035 DNSSEC Protocol Modifications March 2005 DS RRsetはゾーンカットの親側にしか存在せず、親ゾーンが権威を持つデータ である。他の権威を持つRRsetと同様に、DS RRsetが権威を持つゾーンの転送時 には、DS RRsetを付加しなければならない(MUST)。DS RRsetの場合、 これは親ゾーンにあたる。 NSEC RRはゾーンカットの親側、子側両方に存在し、親ゾーン、子ゾーン それぞれで権威を持つデータになっている。ゾーンカットの親側、子側の NSEC RRは絶対に同一にはならない。子ゾーンの頂点にあるNSEC RRは 常に子ゾーンのSOA RRが存在することを示すのに対し、ゾーンカットの 親側にあるNSEC RRはSOA RRの存在を示すことはないからである。 他の権威を持つRRと同様に、NSEC RRが権威を持つゾーンの転送時には、 NSEC RRを付加しなければならない(MUST)。ゾーンカットの親側にある NSEC RRは親ゾーンの転送時に必ず付加されなければならず(MUST)、 また子ゾーンの頂点にあるNSECは子ゾーンの転送時に付加されなければ ならない(MUST)。 RRSIG RRはゾーンカットの親側、子側両方に存在し、RRSIG RRが署名を持つ 権威を持つRRsetが存在するゾーンでは常にRRSIG RRは権威を持つ。つまり、 DS RRsetやゾーンカットの親側にあるNSEC RRに関するRRSIG RRは親ゾーンで 権威を持ち、子ゾーンの頂点にあるRRsetに関するRRSIGは子ゾーンで 権威を持つということである。ゾーンカットの親側、子側にあるRRSIG RRは 絶対に同一にはならない。子ゾーンの頂点にあるRRSIG RRの署名者名 フィールドが子ゾーンの頂点にあるDNSKEY RRを指し示すのに対し、 ゾーンカットの親側にあるRRSIG RRの署名者名フィールドは親ゾーンの 頂点にあるDNSKEY RRを指し示すからである。他の権威を持つRRと同様に、 RRSIG RRが権威を持つゾーンの転送時にはRRSIG RRを付加しなければ ならない(MUST)。 3.1.6. 権威を持つ応答におけるADビットとCDビット CDビットとADビットは、セキュリティ対応リゾルバとセキュリティ対応再帰 ネームサーバ間のやりとりで使用するよう設計された。これらのビットは ほとんどの場合、セキュリティ対応権威ネームサーバが行う問合わせ 処理とは関係がない。 セキュリティ対応ネームサーバは、たとえCDビットがクリアされていたとしても 問合わせ処理の際に権威を持つデータの署名検証を行わない。セキュリティ対応 ネームサーバは権威を持つ応答を生成する際にCDビットをクリアすべき(SHOULD) である。 Arends, et al. Standards Track [Page 16] RFC 4035 DNSSEC Protocol Modifications March 2005 応答の回答部および権威部に入れられたRRsetが全て信頼できない限り、 セキュリティ対応ネームサーバは応答にADビットを設定してはならない (MUST NOT)。セキュリティ対応ネームサーバのローカルポリシーは、権威を 持つゾーンから得たデータを付加的検証無しで信頼してもよい(MAY)。 ただし、ネームサーバが権威を持つゾーンを安全な手段(安全なゾーン転送の 仕組みのような)で入手できない限り、付加的検証無しの信頼をしては ならない(MUST NOT)。また、明示的に設定されていない限り、このような 振る舞いをしてはならない(MUST NOT)。 再帰検索をサポートするセキュリティ対応ネームサーバは、再帰検索を経て得た データを含む応答を生成する際に、セクション3.2で規定するCDビットとADビット に関する規則に従わなければならない(MUST)。 3.2. 再帰ネームサーバ [RFC4033]で規定するように、セキュリティ対応再帰ネームサーバとは セキュリティ対応ネームサーバおよびセキュリティ対応リゾルバの両方の役割を 担うものである。したがって本セクションでは、セキュリティ対応再帰 ネームサーバのコードの中でセキュリティ対応ネームサーバ機能を実装した 部分を"ネームサーバサイド"、セキュリティ対応リゾルバ機能を実装した部分を "リゾルバサイド"と呼ぶことにする。 リゾルバサイドは、任意のセキュリティ対応リゾルバに適用される通常の キャッシュ処理、ネガティブキャッシュ処理に関する規則に従う。 3.2.1. DOビット セキュリティ対応再帰ネームサーバのリゾルバサイドは、ネームサーバサイドで 受信した、反復検索のきっかけとなる検索要求にDOビットが設定されているかに 拘わらず、問合わせ送信時にはDOビットを設定しなければならない(MUST)。 きっかけとなる問合わせのDOビットが設定されていない場合、ネームサーバサイドは 応答に含まれる全ての認証用DNSSEC RRを取り除かなければならない(MUST)。 しかしきっかけとなる問合わせで明示的に要求されたDNSSEC RRタイプを 取り除いてはならない(MUST NOT)。 3.2.2. CDビット CDビットを使用することにより、セキュリティ対応リゾルバはセキュリティ対応 ネームサーバの特定の問合わせにおいて署名検証を無効にさせることができる。 ネームサーバサイドは問合わせに対応する応答にCDビットの設定をコピー しなければならない(MUST)。 Arends, et al. Standards Track [Page 17] RFC 4035 DNSSEC Protocol Modifications March 2005 セキュリティ対応再帰ネームサーバのネームサーバサイドは、きっかけとなる 問合わせの部分と共に、CDビットの状態をリゾルバサイドに渡さなければ ならない(MUST)。これにより、リゾルバサイドはネームサーバサイドに返された 応答データの検証が必要であるかがわかる。CDビットが設定されている場合、 きっかけとなる問合わせを生成したリゾルバでローカルポリシーが要求する 認証を実行することを意味する。したがって、再帰ネームサーバのリゾルバ サイドで応答に含まれるRRsetの認証を実行する必要はない。CDビットが設定 されている場合、再帰ネームサーバのローカルな認証ポリシーがきっかけとなる 問合わせを生成したリゾルバが要求するレコードの提供を拒否しているとしても、 可能ならばそのデータを返すべき(SHOULD)である。すなわち、CDビットを 設定することにより、きっかけとなる問合わせを生成したリゾルバは自分自身で 認証を実行する責任を負うため、再帰ネームサーバは干渉すべきでないことを 明示するのである。 リゾルバサイドが不良キャッシュ(BAD cache)(セクション4.7参照)を実装しており、 ネームサーバサイドがリゾルバサイドの不良キャッシュに一致する問合わせを受信 した場合、ネームサーバサイドの応答は受信した問合わせのCDビットの設定状況に 依存する。CDビットが設定されている場合、ネームサーバサイドは不良キャッシュ からデータを返すべき(SHOULD)である。CDビットが設定されていない場合、ネーム サーバはRCODE 2(server failure)を返さなければならない(MUST)。 上記のような規則の意図は、自分で署名検証を実行できるクライアントには 生データ(raw data)を提供し、一方でセキュリティ対応再帰ネームサーバの リゾルバサイドに署名検証を依存するクライアントは保護することにある。 署名検証が失敗する原因として、署名検証を行う条件が再帰ネームサーバと クライアントで異なる場合があることが挙げられる。例えば、再帰ネームサーバの 時計が正確に設定されていなかったり、クライアント側に再帰ネームサーバが 共有していない適切なセキュリティの島に関する情報があることがあり得る。 このような場合、自ら署名検証を行えるクライアントを"不良"データから "保護"することはクライアントの助けにはならない。 3.2.3. ADビット セキュリティ対応再帰ネームサーバのネームサーバサイドは、応答の回答部および 権威部に入れられた全てのRRsetが信頼できない限り、応答にADビットを設定しては ならない(MUST NOT)。ネームサーバサイドは、回答部の全てのRRsetが信頼でき、 また権威部における任意の適切な否定応答を示すRRが信頼できる場合にだけ ADビットを設定すべき(SHOULD)である。リゾルバサイドは、RRが信頼できるかを 判断する際にセクション5で規定する手続きに従わなければならない(MUST)。 しかし、後方互換性を維持するために、ある応答に含まれる署名無しのCNAME RRが 信頼できるDNAME RRから合成されたことが明らかであり、そのDNAME RRが [RFC2672]で規定する合成規則にしたがって同様に応答に含まれている場合、 再帰ネームサーバはADビットを設定してもよい(MAY)。 Arends, et al. Standards Track [Page 18] RFC 4035 DNSSEC Protocol Modifications March 2005 3.3. DNSSEC応答の例 応答パケットの例については付録Bを参照のこと。 4. リゾルバ側処理 本セクションではセキュリティ対応リゾルバ機能を持つものの振る舞いを 規定する。多くの場合、この機能はセキュリティ対応再帰ネームサーバの 一部であるが、単独で動作する(stand-alone)セキュリティ対応リゾルバも 多くの同じ要件を持つ。セキュリティ対応再帰ネームサーバ固有の機能に ついてはセクション3.2で規定する。 4.1. EDNSのサポート セキュリティ対応リゾルバは、問合わせ送信時にDOビット([RFC3225])が 設定されたEDNS([RFC2671]) OPT擬似RRを入れなければならない(MUST)。 セキュリティ対応リゾルバは少なくとも1220オクテットのメッセージサイズを サポートしなければならず(MUST)、4000オクテットのメッセージサイズを サポートすべき(SHOULD)である。また、EDNS OPT擬似RR内の "sender's UDP payload size"フィールドを使用して受信できるメッセージサイズを 広報しなければならない(MUST)。セキュリティ対応リゾルバのIP層は、 受信したパケットがIPv4かIPv6であるかに拘わらず、フラグメントされた UDPパケットを正しく処理できなければならない(MUST)。これらの要件に関する 議論については[RFC1122]、[RFC2460]および[RFC3226]を参照のこと。 4.2. 署名検証のサポート セキュリティ対応リゾルバはセクション5で規定する署名検証の仕組みを サポートしなければならず(MUST)、また受信した応答全てに対してその仕組みを 適用すべき(SHOULD)である。ただし以下の場合は例外とする。 ・セキュリティ対応リゾルバがセキュリティ対応再帰ネームサーバの一部で あり、かつ応答がCDビットを設定された再帰問合わせ要求の結果 得られたものである場合。 ・何らかの形態のアプリケーションインターフェースを通してセキュリティ対応 リゾルバに検証を行わないよう指示した問合わせに対する応答である場合。 ・ローカルポリシーにより、問合わせに対する検証が無効にされている場合。 Arends, et al. Standards Track [Page 19] RFC 4035 DNSSEC Protocol Modifications March 2005 セキュリティ対応リゾルバの署名検証サポートには、ワイルドカード所有者名の 検証も含まれなければならない(MUST)。 セキュリティ対応リゾルバが検証を実行するために、不足している セキュリティRRの問合わせを行ってもよい(MAY)。この問合わせ実行を選択した 実装は、得られた応答がオリジナルの応答を検証するには不十分であることを 認識していなければならない。例えばオリジナルの問合わせとその後の問合わせの 間に発生したゾーン更新により、求めている情報が変更(または削除)されてしまう 可能性もある。 ゾーンカットの親側にあるNSEC RRが不足していてそれを取得しようと試みる 場合、セキュリティ対応反復型リゾルバは子ゾーンではなく親ゾーンの ネームサーバに問合わせをしなければならない(MUST)。 DSが不足していてそれを取得しようと試みる場合、セキュリティ対応反復型 リゾルバは子ゾーンではなく親ゾーンのネームサーバに問合わせをしなければ ならない(MUST)。セクション3.1.4.1で規定したように、セキュリティ対応 ネームサーバはDS RRの処理に特別な処理規則を適用する必要がある。 リゾルバもまた、親側のNS RRsetを保持していなければ、親ゾーンのネーム サーバを特定するために特別な処理規則を適用しなければならない場合がある。 親のNS RRsetを特定するために、リゾルバは委任名から処理を開始できる。 一番左側のラベルを取り除いた上でその名前のNS RRsetを問い合わせる。 その名前に対してNS RRsetが存在しない場合、リゾルバは残されたラベルから 一番左のラベルを取り除き、その名前に対する問合わせを行う。この木構造を 上に登っていく処理をNS RRsetが見つかるかラベルが無くなるまで繰り返す。 4.3. データのセキュリティ状態の判定 セキュリティ対応リゾルバは、特定のRRsetが署名付きであると期待すべきか どうかを判定できなければならない(MUST)。より厳密には、セキュリティ対応 リゾルバは以下の4つの場合を識別できなければならない。 安全(Secure): 信頼のアンカーからそのRRsetまで署名付きDNSKEY RRおよび DS RRの連鎖を構築できる。この場合、そのRRsetは署名付きだから、先に 規定したような署名検証を行うことができる。 安全でない(Insecure): 信頼できる開始地点からそのRRsetまでの署名付き DNSKEY RRおよびDS RRの連鎖が存在しないことをリゾルバがわかっている。 特定のRRsetが署名無しゾーン内に存在する場合や、署名無しゾーンの下位に RRsetが存在する場合このような状況が生じ得る。この場合、RRsetは 署名付きであるかもしれないし署名が無いかもしれないが、いずれにせよ リゾルバは署名を検証できない。 Arends, et al. Standards Track [Page 20] RFC 4035 DNSSEC Protocol Modifications March 2005 不適正(Bogus): リゾルバはそのRRsetまで信頼の連鎖を構築できると想定して いたが、何らかの理由で署名検証に失敗したか、存在すべき適切なDNSSEC RRが 無いために信頼の連鎖が構築できない。このような状況は攻撃を示唆している かもしれないが、設定エラーや何らかのデータ改変を示す場合もある。 不確定(Indeterminate): リゾルバが必要なDNSSEC RRを得られなかったため、 そのRRsetが署名付きであるかを判断できない。セキュリティ対応リゾルバが 適切なゾーンのセキュリティ対応ネームサーバにアクセスできない場合に このような状況が生じ得る。 4.4. 信頼のアンカーの設定 セキュリティ対応リゾルバは、少なくとも1つの信頼できる公開鍵またはDS RRを 設定に組み込める機能を持たなければならず(MUST)、また複数の信頼できる 公開鍵またはDS RRを設定に組み込めるようにすべき(SHOULD)である。 セキュリティ対応リゾルバは信頼のアンカーの設定無しでは署名検証が行えない ので、リゾルバ起動時にこの種の鍵を得られる適度に強固な仕組みを幾つか 持つべき(SHOULD)である。例えば(ディスクドライブのような)揮発しない 記憶装置のようなものや、信頼できるローカルネットワーク設定の仕組みの ようなものが考えられる。 信頼のアンカーは安全な方法で更新される鍵素材も扱うことに注意して もらいたい。この安全な方法としては物理的メディアを介するものや、 鍵交換プロトコル、他の帯域外(out-of-band)の手段等が考えられる。 4.5. 応答のキャッシュ セキュリティ対応リゾルバは、原子性(atomic)を持つ単一のエントリーとして 各応答をキャッシュすべき(SHOULD)である。各エントリーは所有者名を持つ RRsetとそのRRsetのDNSSEC RRを含む回答全体である。エントリーが持つRRの中で、 どれか1つでも有効期限が来た時点で、原子性を持つエントリーをリゾルバは全て 破棄すべき(SHOULD)である。ほとんどの場合、原子性を持つエントリーの適切な キャッシュインデックスはという3項構成だが、 セクション3.1.3.2で規定した応答のような場合には適切なキャッシュ インデックスはの2項構成になる。 この推奨の理由は、最初の問合わせからデータをキャッシュから破棄するまでの 間に、権威を持つデータが変更される(例えば動的更新によって)可能性があるから である。 Arends, et al. Standards Track [Page 21] RFC 4035 DNSSEC Protocol Modifications March 2005 以下の2つの場合にこれが適切になる。 1. RRSIGレコードを使用することにより、回答がワイルドカードから合成 されたことが推測できる。セキュリティ対応再帰ネームサーバは、最初 に受信したオリジナルの回答による名前以外の問い合わせに対して肯定 応答を生成するために、このワイルドカードデータを保存し、それを使 うことができる。 2. 名前の不在を証明するNSEC RRを受信した場合、セキュリティ対応リゾルバは その名前の範囲内にある名前全てが存在しないことを証明するために、その NSEC RRを再利用することができる。 理論的には、リゾルバはTTLやレコードの署名が期限切れになるまでワイルド カードまたはNSEC RRを使用して肯定および否定応答を(それぞれ)生成する ことができる。しかしリゾルバが新しい権威を持つデータを得たり、リゾルバが 保持するデータから新しいデータを合成したりすることを阻害しない方が 賢明に思われる。この推奨に従うリゾルバはより一貫性のある名前空間の 構成情報を得られるだろう。 4.6. CDビットおよびADビットの処理 セキュリティ対応リゾルバは、ローカルポリシーが要求する何らかの認証処理を 自分が応答のRRsetに対して実行する責任を負うことを示すために、問合わせの CDビットを設定してもよい(MAY)。セキュリティ対応再帰ネームサーバの振る舞いに 対してこのビットの設定が与える影響についてはセクション3.2を参照のこと。 自分が理解できないヘッダービットを問合わせメッセージから応答メッセージに 無分別にコピーしてしまうような不適当な動作をするネームサーバの影響を 避けるために、セキュリティ対応リゾルバは問合わせメッセージ生成時に ADビットをクリアしなければならない(MUST)。 応答メッセージが安全なチャネルから得られたか、安全なチャネルから応答を 得られなくてもメッセージヘッダーに注意するような設定が特にされていない 限り、リゾルバは応答に含まれるCDおよびADビットを無視しなければならない (MUST)。 4.7. 不良キャッシュ 多くの認証エラーが一時的に発生することがあるが、その中の幾つかのもの、 例えば管理上のエラーによって引き起こされるもの(ゾーンへの再署名失敗、 時刻のずれ等)は永続的になることがある。そのような場合、再問合わせは 役に立たないので、検証を行うリゾルバが認証の失敗が継続しているRRsetへの 問合わせを繰り返すと、不要なDNSトラヒックを大量に発生させる結果と なってしまう。 そのような不要なDNSトラヒックを抑制するために、セキュリティ対応リゾルバは 署名が無効なデータを制限付きでキャッシュしてもよい(MAY)。 Arends, et al. Standards Track [Page 22] RFC 4035 DNSSEC Protocol Modifications March 2005 概念的には、そのようなデータのキャッシュはネガティブキャッシュ([RFC2308]) と同様である。違いは有効な否定応答をキャッシュするのではなく、特定の 回答の検証に失敗したという事実をキャッシュすることにある。本文書では、 この署名が無効なデータのキャッシュを"不良キャッシュ"と呼ぶ。 不良キャッシュを実装しているリゾルバは、そのキャッシュを利用した サービス不能攻撃を抑制するために、幾つかの処理を行わなければならない (MUST)。具体的には以下のとおりである。 ・検証に失敗したRRsetは信頼できるTTLを持たないので、実装はTTLを自分で 割り当てなければならない(MUST)。攻撃の結果をキャッシュした影響を軽減 するために、このTTLは小さくすべき(SHOULD)である。 ・一時的な認証失敗(この失敗も攻撃の影響である可能性がある)をキャッシュして しまわないように、認証が失敗した問合わせを追跡記録すべき(SHOULD)であり、 その上で一定のしきい値を越えて認証に失敗した特定の への問合わせに対してだけ不良キャッシュを使用して応答すべき(SHOULD) である。 本文書のセクション4.2で規定する規則に従った特定のRRsetの署名検証が 求められていない限り、リゾルバはRRsetへの問合わせに対して不良キャッシュを 使用して応答を返してはならない(MUST NOT)。セキュリティ対応再帰ネーム サーバがどのように不良キャッシュと相互に連携して応答を返すかに関する議論は セクション3.2.2を参照のこと。 4.8. 合成されたCNAMEの処理 検証を行うセキュリティ対応リゾルバは、有効な署名付きDNAME RRから [RFC2672]の規定にしたがって署名無しCNAME RRが合成された場合に、 DNAME RRの署名が署名無しCNAME RRも対象としているものとして処理 しなければならない(MUST)。少なくとも、署名が無いCNAME RRが存在する という理由で応答メッセージを拒否してはならない。リゾルバはこのような CNAME RRをキャッシュに保存したり応答に入れたりしてもよい(MAY)が、 特にそうすることを要求するものではない。 4.9. スタブリゾルバ セキュリティ対応スタブリゾルバはDNSSEC RRタイプをサポートしなければ ならない(MUST)。少なくとも応答にDNSSEC RRが含まれているだけの理由で 誤った処理をしてはならない。 Arends, et al. Standards Track [Page 23] RFC 4035 DNSSEC Protocol Modifications March 2005 4.9.1. DOビットの処理 検証機能無しセキュリティ対応スタブリゾルバは、スタブリゾルバを起動した アプリケーションへの応答に、セキュリティ対応再帰ネームサーバから返された DNSSEC RRを含めてもよい(MAY)が、特にそうすることを要求するものではない。 アプリケーションにDNSSEC RRを含めた応答を返そうとする検証機能無し スタブリゾルバは、再帰ネームサーバからDNSSEC RRを受信するためにDOビットを 設定する必要がある。 検証機能付きセキュリティ対応スタブリゾルバはDOビットを設定しなければ ならない(MUST)。そうしなければ署名検証に必要なDNSSEC RRを受信できない からである。 4.9.2. CDビットの処理 検証機能無しスタブリゾルバは、アプリケーション層から要求されない限り 送信時にCDビットを設定すべきではない(SHOULD NOT)。定義によれば、 検証機能無しスタブリゾルバはセキュリティ対応再帰ネームサーバに検証実行を 依存するものだからである。 検証機能付きセキュリティ対応スタブリゾルバはCDビットを設定すべき(SHOULD) である。そうしなければセキュリティ対応再帰ネームサーバはネームサーバの ローカルポリシーを使用して問合わせに応答するため、スタブリゾルバの ローカルポリシーが許容できるデータを受信できないかもしれないからである。 4.9.3. ADビットの処理 検証機能無しセキュリティ対応スタブリゾルバは、応答を返した セキュリティ対応再帰ネームサーバが応答メッセージの回答部および権威部に 含まれるデータを暗号技術で検証したことを明示しているかを判断 するために、ADビットが設定されているか調査してもよい(MAY)。 ただし、セキュリティ対応スタブリゾルバが受信した応答はセキュリティ対応 再帰ネームサーバのローカルポリシーに強く依存していることに注意して もらいたい。したがって、デバッグの手がかりとするような例外を除けば、 ADビットの状態を検査する実際的な価値はわずかであろう。セキュリティ対応 スタブリゾルバが信頼できるセキュリティ対応再帰ネームサーバから安全な チャネルを通してデータを得た場合を除き、どのような場合でもセキュリティ対応 スタブリゾルバは自分の代わりに行ったとされる署名検証を信頼しては ならない(MUST NOT)。 検証機能付きスタブリゾルバは、応答メッセージにADビットが設定されているかを 検査すべきではない(SHOULD NOT)。定義により、検証機能付きスタブリゾルバは ADビットが設定されているかどうかに拘わらず署名検証を行うからである。 Arends, et al. Standards Track [Page 24] RFC 4035 DNSSEC Protocol Modifications March 2005 5. DNS応答の認証 DNSSEC RRの認証に使用するために、セキュリティ対応リゾルバは認証された 少なくとも一つのDNSKEYまたはDS RRを設定情報として必要とする。 この起点となる信頼のアンカーの取得および認証は、DNSSEC以外の外的な仕組みに よって行われる。例えば、リゾルバは認証されたオフラインのやりとりを通して、 ゾーンのDNSKEY RRあるいはゾーンのDNSKEY RRを特定し認証するDS RRを取得 できるかもしれない。本セクションの残りでは、リゾルバは何らかの手段に よって信頼のアンカーの初期集合を得ているものとする。 起点となるDNSKEY RRを使用してゾーン頂点にあるDNSKEY RRsetを認証する ことができる。起点の鍵を使用してゾーン頂点にあるDNSKEY RRsetを認証する ために、リゾルバは以下の処理を行わなければならない(MUST)。 1. ゾーン頂点にあるDNSKEY RRset内に起点となるDNSKEY RRが存在するか、 およびそのDNSKEY RRのゾーン鍵フラグ(DNSKEY RDATAのビット7)が設定 されているかを検証する。 2. 次にゾーン頂点にあるDNSKEY RRsetの署名を持つRRSIG RRが存在するか、 およびRRSIG RRと起点となるDNSKEY RRの組み合わせによってDNSKEY RRsetを 認証できるか検証する。RRSIG RRを使用したRRsetの認証処理については セクション5.3で規定する。 リゾルバが起点となるDNSKEY RRを使用してゾーン頂点のDNSKEY RRsetを 一旦認証したならば、DS RRを使用してそのゾーンからの委任を認証する ことができる。これにより、リゾルバは起点となる鍵から認証を開始し、他の ゾーン頂点にあるDNSKEY RRsetの取得とDS RRsetの使用により、下方に向けて 再帰的にDNS木構造を認証し続けることが可能になる。リゾルバがルートの DNSKEY RRの設定を保持しており、かつ委任それぞれが対応するDS RRを 持っている場合、リゾルバはあらゆるゾーン頂点にあるDNSKEY RRsetを取得し 検証できるだろう。DS RRを使用した参照の認証処理についてはセクション5.2で 規定する。 セクション5.3では、リゾルバが一旦ゾーンの頂点にあるDNSKEY RRsetを認証 した後で、そのDNSKEY RRsetに含まれるDNSKEY RRとRRSIG RRを使用して リゾルバが同じゾーン内の他のRRsetを認証する方法を示す。 セクション5.4では、リゾルバが認証されたNSEC RRsetを使用して、あるRRsetが ゾーン内に存在しないことを証明する方法を示す。 リゾルバが(DOビットを設定することにより)DNSSECサポートを提示した場合、 セキュリティ対応ネームサーバは必要なDNSKEY、RRSIG、NSECおよびDS RRsetを 応答で提供しようと試みるべきである(セクション3参照)。しかし、 上流にあるセキュリティ非対応再帰ネームサーバが偶然DNSSEC RRを抑制したり、 意図的な攻撃による応答の改ざんでDNSSEC RRが消去される、あるいは問合わせを 一部変更されてDNSSEC RRを要求できないなどの理由により、セキュリティ対応 リゾルバは依然として適切なDNSSEC RRを欠いた応答を受信する場合がある。 リゾルバは自身の応答の中にDNSSECデータが存在しないという事実から、認証情報が 存在しないと解釈してはならない(MUST NOT)。 Arends, et al. Standards Track [Page 25] RFC 4035 DNSSEC Protocol Modifications March 2005 リゾルバは署名付きゾーンから認証情報が得られると予想すべき(SHOULD) である。リゾルバはあるゾーンに関する公開鍵が設定されているか、または あるゾーンの親が署名付きでその親からの委任にDS RRsetが設定されて いる場合、そのゾーンは署名付きであると見なすべき(SHOULD)である。 5.1. セキュリティの島に関する特別な考慮点 セキュリティの島([RFC4003]参照)は、その親からの認証の連鎖を構築できない 署名付きゾーンである。セキュリティの島内部にある署名を検証するためには、 検証者が起点となる認証されたゾーン鍵をセキュリティの島からDNSSEC以外の手段で 取得する必要がある。検証者がそのような鍵を得られなかった場合、 セキュリティの島にあるゾーンは署名無しとみなした運用に切り替えるべき (SHOULD)である。 応答を検証する通常の処理全てがセキュリティの島にも適用される。 通常の検証とセキュリティの島内部の検証の違いは、認証の連鎖を形成する 信頼のアンカーを検証者が入手する手段だけである。 5.2. 参照の認証 署名付きゾーンの頂点にあるDNSKEY RRsetが一旦認証されたならば、 DS RRsetを使用して署名付き子ゾーンの委任を認証することができる。 DS RRは、子ゾーンの頂点にあるDNSKEY RRset内のDNSKEY RRを特定し、また 子ゾーンのDNSKEY RRの暗号ダイジェストを含む。強力な暗号ダイジェスト アルゴリズムを使用することにより、悪意を持った第三者がそのダイジェストと 一致するDNSKEY RRを生成することが計算上不可能であることを保証する。 したがって、ダイジェストを認証することにより、リゾルバはそのダイジェストに 一致するDNSKEY RRを認証することができる。次に、リゾルバは子ゾーンの DNSKEY RRを使用して、子ゾーンの頂点にあるDNSKEY RRset全てを認証する ことができる。 委任に関するDS RRが与えられた場合、以下の条件が全て満たされれば 子ゾーンの頂点にあるDNSKEY RRsetを認証することができる。 ・DS RRは、親ゾーンの頂点にあるDNSKEY RRsetに含まれるDNSKEY RRによって 既に認証済みである(セクション5.3参照)。 Arends, et al. Standards Track [Page 26] RFC 4035 DNSSEC Protocol Modifications March 2005 ・DS RR内のアルゴリズムおよび鍵タグは、それぞれ子ゾーンの頂点にある DNSKEY RRset内のDNSKEY RRのアルゴリズムフィールドと鍵タグに一致 する。DNSKEY RRの所有者名とRDATAがDS RRのダイジェストタイプ フィールドで指定されるダイジェストアルゴリズムでハッシュされている 場合、得られたダイジェスト値はDS RRのダイジェストフィールドと 一致する。 ・子ゾーンにあるダイジェストが一致したDNSKEY RRはゾーンフラグビットが 設定されており、対応する秘密鍵によって子ゾーンの頂点にあるDNSKEY RRsetに署名している。署名の結果得られたRRSIG RRが子ゾーンの頂点にある DNSKEY RRsetを認証している。 親ゾーンから得られた参照がDS RRsetを含まない場合、委任された名前に関する DS RRsetが存在しないことを証明する署名付きNSEC RRsetを、応答に含めるべき である(セクション3.1.4参照)。セキュリティ対応リゾルバは、参照にDS RRsetも DS RRsetの不在証明をするNSEC RRsetも含まれていない場合、その親ゾーンの ネームサーバに対してDS RRsetに関する問合わせをしなければならない(MUST) (セクション4参照)。 ゾーンにDS RRsetが存在しないことを証明するNSEC RRsetを検証者が認証した 場合、親から子に至る認証の経路は存在しない。リゾルバが子ゾーン内あるいは 子ゾーンの下位ゾーンにある起点となるDNSKEYまたはDS RRを持っている場合、 その起点となるDNSKEYまたはDS RRを使用して認証経路を再構築してもよい(MAY)。 そのような起点となるDNSKEYまたはDS RRが存在しなければ、検証者は子ゾーン内 または子ゾーンよりも下位のゾーンにあるRRsetを認証できない。 検証者が認証済みのDS RRset内に列挙されたアルゴリズムをどれもサポートして いない場合、リゾルバは親から子に至るサポートされた認証経路を持たない。 このような場合、リゾルバは先に説明したようなDS RRsetの不在証明をする NSEC RRを認証した場合と同様に処理すべきである。 署名付き委任の場合、委任された名前に関して2つのNSEC RRが存在することに 注意してもらいたい。1つ目のNSEC RRは親ゾーンに存在し、それを使用して 委任された名前に関するDS RRsetが存在することを証明することができる。 2つ目のNSEC RRは子ゾーンに存在し、子ゾーンの頂点に存在するRRsetを特定 する。親ゾーンのNSEC RRと子ゾーンのNSEC RRは常に識別可能である。なぜなら、 子ゾーンのNSEC RRにはSOAビットが設定されており、親ゾーンのNSEC RRでは そのビットはクリアされているからである。セキュリティ対応リゾルバが DS RRsetの不在を証明しようとする場合、親ゾーンのNSEC RRを使用しなければ ならない(MUST)。 Arends, et al. Standards Track [Page 27] RFC 4035 DNSSEC Protocol Modifications March 2005 リゾルバが認証済みのDS RRset内に列挙されたアルゴリズムをどれもサポート していない場合、リゾルバは子ゾーンへの認証経路を検証できない。 この場合、リゾルバは子ゾーンを署名無しと見なして処理すべき(SHOULD)である。 5.3. RRSIG RRを使用したRRsetの認証 検証者は、RRSIG RRと対応するDNSKEY RRを使用してRRsetの認証を試みる ことができる。検証者は初めにRRSIG RRを検査し、RRsetの署名を持っているか、 署名の有効期限を過ぎていないか、有効なDNSKEY RRを特定しているか等を 検証する。次に、検証者は(署名フィールドを除く)RRSIG RDATAを署名対象の RRsetの正規形式に付け加えることにより、正規形式の署名付きデータを 形成する。最後に、検証者は公開鍵と署名を使用して署名付きデータを 認証する。セクション5.3.1、5.3.2および5.3.3で各段階の処理を詳細に 規定する。 5.3.1. RRSIG RRの有効性検査 以下の条件が全て満たされていれば、セキュリティ対応リゾルバはRRSIG RRを 使用してRRsetを認証することができる。 ・RRSIG RRとRRsetは同じ所有者名を持ち、同じクラスでなければならない (MUST)。 ・RRSIG RRの署名者名フィールドはRRsetを含むゾーンの名前でなければ ならない(MUST)。 ・RRSIG RRの署名対象フィールドはRRsetのタイプと同じでなければならない (MUST)。 ・RRsetの所有者名のラベル数は、RRSIG RRのラベルフィールドの値と同じか それよりも大きくなければならない(MUST)。 ・検証者の現在時刻を表現する値は、RRSIG RRの有効期間終了フィールドに 列挙された時間と同じかそれよりも小さくなければならない(MUST)。 ・検証者の現在時刻を表現する値は、RRSIG RRの有効期間開始フィールドに 列挙された時間と同じかそれよりも大きくなければならない(MUST)。 ・RRSIG RRの署名者名、アルゴリズムおよび鍵タグフィールドは、ゾーン頂点に あるDNSKEY RRsetに含まれるDNSKEY RRの所有者名、アルゴリズムおよび鍵タグ フィールドに一致しなければならない(MUST)。 ・先のフィールドが一致するDNSKEY RRはゾーン頂点にあるDNSKEY RRsetに 含まれていなければならず(MUST)、またゾーンフラグビット(DNSKEY RDATA のフラグビット7)が設定されていなければならない(MUST)。 Arends, et al. Standards Track [Page 28] RFC 4035 DNSSEC Protocol Modifications March 2005 2つ以上のDNSKEY RRが上記の条件に一致することもあり得る。その場合、 検証者は署名の認証に使用するDNSKEY RRを事前に決定することはできない ので、検証者は署名が認証されるか、一致する公開鍵が無くなるまで DNSKEY RRを試し続けなければならない(MUST)。 この認証処理は、検証者が署名認証に使用する前にDNSKEY RRを認証する 場合にだけ意味がを持つ。以下の条件が満たされれば、一致するDNSKEY RRは 信頼できると見なされる。 ・頂点にあるDNSKEY RRsetが信頼できると見なされるDNSKEY RRを含んで いる。 ・または、RRSIG RRが署名を持つRRsetがゾーン頂点にあるDNSKEY RRset自身 であり、DNSKEY RRは親ゾーンにある認証済みのDS RRあるいは信頼の アンカーのどちらかに一致する。 5.3.2. 署名付きデータの再構成 RRSIG RRがセクション5.3.1で規定した認証要件を一旦満たしたならば、検証者は オリジナルの署名付きデータを再構成しなければならない。オリジナルの 署名付きデータは(署名フィールドを除く)RRSIG RDATAとRRsetの正規形式を 含む。順番どおりになっているかどうかは別としても、RRsetの正規形式は、 DNS名前圧縮、TTLのデクリメントあるいはワイルドカード展開により、受信した RRsetとは異なる場合がある。検証者はオリジナルの署名付きデータを再構成 するために以下の手続きを使用すべきである。 署名付きデータ = RRSIG_RDATA | RR(1) | RR(2)... ここで"|"は連結(concatenation)を表す。 RRSIG_RDATAはRRSIG RDATAフィールドから署名フィールドを除き、 署名者名を正規形式にしたもののワイヤーフォーマットである。 RR(i) = 名前 | タイプ | クラス | オリジナルTTL | RDATA長 | RDATA 名前は以下の関数によって計算される。 クラスはRRsetのクラスである。 タイプはRRsetのタイプであり、全てのRRは上述のクラス内にある。 オリジナルTTLはRRSIGオリジナルTTLフィールドから得られた値 である。 RDATAフィールド内の名前は全て正規形式である。 Arends, et al. Standards Track [Page 29] RFC 4035 DNSSEC Protocol Modifications March 2005 全てのRR(i)は正規順序で順序づけされる。 名前を計算する手順: let rrsig_labels = RRSIGのラベルフィールド値 let fqdn = 正規形式のRRsetの完全修飾ドメイン名 let fqdn_labels = 先に定義したfqdnのラベル数 if rrsig_labels = fqdn_labels, name = fqdn if rrsig_labels < fqdn_labels, name = "*." | rrsig_labelに含まれるfqdnラベルの一番右側 if rrsig_labels > fqdn_labels RRSIG RRは必須の検証を通過しなかったので、このRRsetを 認証するために使用してはならない(MUST NOT)。 名前およびRRsetの正規形式は[RFC4034]で定義される。 委任境界にあるNSEC RRsetは特別な処理を必要とする。署名付き委任名に関して、 2つの異なるNSEC RRsetが存在する。1つ目のNSEC RRsetは親ゾーンに存在し、 親ゾーンに存在するRRsetを指定する。2つ目のNSEC RRsetは子ゾーンに存在し、 子ゾーンの頂点にあるRRsetを特定する。子ゾーン側のNSEC RRだけが名前に 対するSOA RRsetが存在することを示すので、親ゾーン側のNSEC RRsetと 子ゾーン側のNSEC RRsetは常に識別可能である。親ゾーンから得られた委任に 関するオリジナルのNSEC RRsetを再構成する際に、親側のNSEC RRを子側の NSEC RRと混同してはならない(MUST NOT)。子ゾーンの頂点にあるオリジナル NSEC RRsetを再構成する際に、子側のNSEC RRを親ゾーンのNSEC RRと混同しては ならない(MUST NOT)。 委任点にある2つのNSEC RRsetは、それぞれ対応するRRSIG RRを持つ。RRSIG RRは 委任された名前に一致する所有者名を持ち、対応するNSEC RRsetが存在するゾーン において権威を持つデータである。リゾルバは、必要であればRRSIG RRの署名者名 フィールドを検査することにより、これらのRRSIG RRを区別することができる。 Arends, et al. Standards Track [Page 30] RFC 4035 DNSSEC Protocol Modifications March 2005 5.3.3. 署名の検査 セクション5.3.1に記載した手順でリゾルバが一旦RRSIG RRを認証し、また セクション5.3.2に記載した手順でオリジナルの署名付きデータを再構成 したならば、検証者は暗号化された署名を使用して署名付きデータを認証 することができる。その結果(ようやく！)RRsetを認証することができる。 RRSIG RRのアルゴリズムフィールドは署名生成に使用したアルゴリズムを 特定する。署名そのものはRRSIG RDATAの署名フィールドに保存され、 署名の検証に使用する公開鍵は対応するDNSKEY RRの公開鍵フィールドに 保存される(セクション5.3.1参照のこと)。[RFC4034]でアルゴリズムタイプ の一覧と、各アルゴリズムの使用法を定義した文書へのポインタを提供 している。 セクション5.3.1の条件に一致するDNSKEY RRが2つ以上になることもあり得る ことに注意してもらいたい。その場合、検証者は条件に一致した公開鍵を 一つずつ試していき、署名認証に成功するか、試すべき鍵が無くなるまで 繰り返すことによってのみ正当なDNSKEY RRを決定することができる。 RRSIG RRのラベルフィールドがRRsetの完全修飾所有者名のラベル数と一致 しない場合、そのRRsetは無効なものか、ワイルドカード展開によって得られた ものかのどちらかである。リゾルバはRRsetを信頼できると見なす前に、ワイルド カード展開が適切に行われたかを検証しなければならない(MUST)。 セクション5.3.4でワイルドカードが適切に適用されたかを判断する方法を示す。 もしこのRRsetが他のRRSIGによる署名もあわせ持つ場合、リゾルバがこれらの RRSIG RRを検査しなければならないか、また複数のRRSIG RRが異なる結果を 出した場合に、その衝突をどのように解決するかについては、ローカルリゾルバの セキュリティポリシーが決定する。 リゾルバがRRsetを信頼できると判断した場合、検証者はRRSIG RRと認証された RRsetに含まれる各RRのTTLを、以下に示す値の最小値を超えないように設定 しなければならない(MUST)。 ・応答を受信した際のRRsetのTTL ・応答を受信した際のRRSIG RRのTTL ・RRSIG RRのオリジナルTTLフィールドに含まれる値 ・RRSIG RRの署名有効期間終了時刻と現在時刻との差 Arends, et al. Standards Track [Page 31] RFC 4035 DNSSEC Protocol Modifications March 2005 5.3.4. ワイルドカード展開されたRRsetを含む肯定応答の認証 あるRRsetの所有者名のラベル数の方が署名を持つRRSIG RRのラベルフィールドの 値よりも大きい場合、そのRRsetとその署名を持つRRSIG RRはワイルドカード展開 の結果生成されたものである。セクション5.3で規定する手順で検証者が一旦 署名を検証したならば、問合わせに完全一致するか、あるいはより良いワイルド カード一致するRRsetの不在を検証するために付加的な手順を取らなければ ならない。 リゾルバが受信した応答は、応答を認証するために必要なNSEC RRを全て 含むべきであることに注意してもらいたい(セクション3.1.3参照)。 5.4. 不在証明 リゾルバは認証済みのNSEC RRを使用して、署名付きゾーン内に特定のRRsetが 存在しないことを証明することができる。セキュリティ対応ネームサーバは、 セキュリティ対応リゾルバへの応答の中に署名付きゾーンに関し、必要な NSEC RRを自動的に入れるべきである。 不在は以下の規則によって決定される。 ・問合わされたRR名が認証済みNSEC RRの所有者名と一致する場合、NSEC RRの タイプビットマップフィールドには所有者名に対して存在する全てのRRタイプ が列挙されるので、リゾルバはRRタイプビットマップを検査することにより、 問合わされたRRタイプが存在しないことを証明することができる。 NSEC RRの所有者名のラベル数が署名を持つRRSIG RRのラベルフィールドの値と 等しい場合、そのNSEC RRの存在によってワイルドカード展開をしても 問合わされたタイプと一致するものは存在しないことを証明する。 ・問合わされたRR名が認証済みNSEC RRの所有者名の後ろに存在するはずの もので、また[RFC4034]で定義されるDNS正規名順序に従うNSEC RRの 次ドメインフィールドに列挙された名前の前に存在するはずである場合、 問合わされた名前を持つRRsetはゾーン内に存在しない。 しかし、問合わされたRR所有者名およびタイプに一致するワイルドカードは 存在するかもしれないので、問い合わされたRRsetの不在を証明するためには 肯定応答可能なワイルドカードRRsetの不在も証明する必要がある。 更に、セキュリティ対応リゾルバはセクション5.3に記載する不在証明を含む NSEC RRsetを認証しなければならない(MUST)。 あるRRsetの不在を証明するためには、リゾルバは問合わされたRRsetが 存在しないことおよび適切なワイルドカードRRsetが存在しないことの両方を 検証できなければならない。これを証明するためには、ゾーン内のNSEC RRsetが 2つ以上必要かもしれない。必要なNSEC RRsetが応答に全て含まれていない場合 (おそらくはメッセージ切り詰めによって)、セキュリティ対応リゾルバは 問合わされたRRsetの不在検証に必要なNSEC RRを全て取得するために、 問合わせを再送しなければならない(MUST)。 しかし、他の全DNS処理と同様に、リゾルバは特定の問合わせへの回答だけに 労力を注ぐことを抑制しなければならない(MUST)。 認証済みNSEC RRは自分自身と対応するRRSIG RRの存在を証明するので、 検証者はNSEC RR内のNSECおよびRRSIGビットを無視しなければならない(MUST)。 5.5. 署名が検証できない場合のリゾルバの振る舞い 何らかの理由でRRSIG RRを検証できなかった場合、応答は不良(BAD)と見なされる べき(SHOULD)である。再帰検索サービスを提供するために検証をしている 最中である場合は、ネームサーバは問合わせを生成したクライアントにRCODE 2を 返さなければならない(MUST)。しかし、オリジナルの問合わせにCDビットが 設定されている場合に限り、完全な応答を返さなければならない。 認証できなかった応答のキャッシュについてはセクション4.7を参照のこと。 5.6. 認証の例 付録Cに認証処理の例を示す。 6. IANAに関する考慮点 [RFC4034]はDNSSECによって導入されたIANAに関する考慮点について再検討 した内容を含む。以下は本文書で議論された、付加的なIANAに関する考慮点 である。 [RFC2535]はメッセージヘッダーのCDおよびADビットを予約している。 ADビットの意味を[RFC3655]で再定義し、CDおよびADビットの意味を 本文書で再度規定している。本文書で定義した新しいDNSメッセージヘッダー は無い。 [RFC2671]はEDNSを導入し、[RFC3225]でDNSSEC OKビットを予約し、その使用法を 定義した。この使用法は本文書で再度規定されているが、変更はない。 7. セキュリティに関する考慮点 本文書はDNSセキュリティ拡張が公開鍵暗号を使用してDNSリソースレコード セットに署名する方法、リソースレコードセットを認証する方法を規定して いる。用語およびDNSSECに関連するセキュリティに関する考慮点については [RFC4033]を参照のこと。またDNSSECリソースレコードセット固有の考慮点に ついては[RFC4034]を参照のこと。 Arends, et al. Standards Track [Page 33] RFC 4035 DNSSEC Protocol Modifications March 2005 DNS問合わせメッセージのCDビットが設定できる、あるいはDNS応答メッセージの ADビットを設定できるやり手の攻撃者は、これらのビット設定を使用して、 DNSSECがセキュリティ非対応再帰型リゾルバに提供する保護の仕組みを突破する ことができる。この理由により、セキュリティ対応再帰型リゾルバがこれらの 制御ビットを使用する場合は安全なチャネルが必要となる。詳細な議論に ついてはセクション3.2.2および4.9参照のこと。 本文書で規定するプロトコルは、セキュリティ非対応スタブリゾルバに対しても DNSSECで得られる利益を拡大しようと試みるものである。しかし、認証失敗後の 復旧手続きはアプリケーション固有になる可能性が高いので、DNSSECがスタブ リゾルバに利便性を提供するのは不適当であるかもしれない。セキュリティ対応 再帰ネームサーバの運用者は、ローカルな認証ポリシーを選択する際には、 サービスを利用するアプリケーションの振る舞いに充分な注意を払わなければ ならないだろう。さもないと、再帰ネームサーバが本来クライアントに向けて サポートしようとしていたサービスを誤って拒否してしまう結果になりかねない。 8. 謝辞 本文書はDNS拡張ワーキンググループおよびグループメーリングリストのメンバの アイディアとインプットによって作成された。一連のセキュリティ拡張の仕様を 改訂している間にもらったコメントと提案に感謝の意を表したい。DNSSECが 開発途上であった10年間に貢献してくれた全員を列挙することはできないが、 [RFC4033]で一連の文書群に対して充分なコメントをくれた人たちの一覧を提示 している。 9. 参考文献 9.1. 必須の参考文献 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. Arends, et al. Standards Track [Page 34] RFC 4035 DNSSEC Protocol Modifications March 2005 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999. [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001. [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for DNS Security Extensions", RFC 4034, March 2005. 9.2. 有用な参考文献 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS Authenticated Data (AD) bit", RFC 3655, November 2003. Arends, et al. Standards Track [Page 35] RFC 4035 DNSSEC Protocol Modifications March 2005 付録A. 署名付きゾーンの例 以下の例で(小規模な)署名付きゾーンを示す。 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1081539377 3600 300 3600000 3600 ) 3600 RRSIG SOA 5 1 3600 20040509183619 ( 20040409183619 38519 example. ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) 3600 NS ns1.example. 3600 NS ns2.example. 3600 RRSIG NS 5 1 3600 20040509183619 ( 20040409183619 38519 example. gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) 3600 MX 1 xx.example. 3600 RRSIG MX 5 1 3600 20040509183619 ( 20040409183619 38519 example. HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM W6OISukd1EQt7a0kygkg+PEDxdI= ) 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY 3600 RRSIG NSEC 5 1 3600 20040509183619 ( 20040409183619 38519 example. O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm jfFJ5arXf4nPxp/kEowGgBRzY/U= ) 3600 DNSKEY 256 3 5 ( AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI Arends, et al. Standards Track [Page 36] RFC 4035 DNSSEC Protocol Modifications March 2005 ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== ) 3600 DNSKEY 257 3 5 ( AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== ) 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( 20040409183619 9465 example. ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( 20040409183619 38519 example. eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk 7z5OXogYVaFzHKillDt3HRxHIZM= ) a.example. 3600 IN NS ns1.a.example. 3600 IN NS ns2.a.example. 3600 DS 57855 5 1 ( B6DCD485719ADCA18E5F3D48A2331627FDD3 636B ) 3600 RRSIG DS 5 2 3600 20040509183619 ( 20040409183619 38519 example. oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) 3600 NSEC ai.example. NS DS RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) ns1.a.example. 3600 IN A 192.0.2.5 ns2.a.example. 3600 IN A 192.0.2.6 ai.example. 3600 IN A 192.0.2.9 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. Arends, et al. Standards Track [Page 37] RFC 4035 DNSSEC Protocol Modifications March 2005 pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) 3600 HINFO "KLH-10" "ITS" 3600 RRSIG HINFO 5 2 3600 20040509183619 ( 20040409183619 38519 example. Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7 AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw FvL8sqlS5QS6FY/ijFEDnI4RkZA= ) 3600 AAAA 2001:db8::f00:baa9 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 20040409183619 38519 example. nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 sZM6QjBBLmukH30+w1z3h8PUP2o= ) 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL AhS+JOVfDI/79QtyTI0SaDWcg8U= ) b.example. 3600 IN NS ns1.b.example. 3600 IN NS ns2.b.example. 3600 NSEC ns1.example. NS RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ vhRXgWT7OuFXldoCG6TfVFMs9xE= ) ns1.b.example. 3600 IN A 192.0.2.7 ns2.b.example. 3600 IN A 192.0.2.8 ns1.example. 3600 IN A 192.0.2.1 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK Arends, et al. Standards Track [Page 38] RFC 4035 DNSSEC Protocol Modifications March 2005 v/iVXSYC0b7mPSU+EOlknFpVECs= ) 3600 NSEC ns2.example. A RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) ns2.example. 3600 IN A 192.0.2.2 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) 3600 NSEC *.w.example. A RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw Ymx28EtgIpo9A0qmP08rMBqs1Jw= ) *.w.example. 3600 IN MX 1 ai.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( 20040409183619 38519 example. OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw 4kX18MMR34i8lC36SR5xBni8vHI= ) 3600 NSEC x.w.example. MX RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 s1InQ2UoIv6tJEaaKkP701j8OLA= ) x.w.example. 3600 IN MX 1 xx.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( 20040409183619 38519 example. Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 Arends, et al. Standards Track [Page 39] RFC 4035 DNSSEC Protocol Modifications March 2005 jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) 3600 NSEC x.y.w.example. MX RRSIG NSEC 3600 RRSIG NSEC 5 3 3600 20040509183619 ( 20040409183619 38519 example. aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e IjgiM8PXkBQtxPq37wDKALkyn7Q= ) x.y.w.example. 3600 IN MX 1 xx.example. 3600 RRSIG MX 5 4 3600 20040509183619 ( 20040409183619 38519 example. k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb +gLcMZBnHJ326nb/TOOmrqNmQQE= ) 3600 NSEC xx.example. MX RRSIG NSEC 3600 RRSIG NSEC 5 4 3600 20040509183619 ( 20040409183619 38519 example. OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) xx.example. 3600 IN A 192.0.2.10 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx kbIDV6GPPSZVusnZU6OMgdgzHV4= ) 3600 HINFO "KLH-10" "TOPS-20" 3600 RRSIG HINFO 5 2 3600 20040509183619 ( 20040409183619 38519 example. GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0 t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+ RgNvuwbioFSEuv2pNlkq0goYxNY= ) 3600 AAAA 2001:db8::f00:baaa 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 20040409183619 38519 example. Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ Arends, et al. Standards Track [Page 40] RFC 4035 DNSSEC Protocol Modifications March 2005 xS9cL2QgW7FChw16mzlkH6/vsfs= ) 3600 NSEC example. A HINFO AAAA RRSIG NSEC 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W GghLahumFIpg4MO3LS/prgzVVWo= ) 頂点にあるDNSKEY RRsetは2つのDNSKEY RRを含み、DNSKEY RDATAフラグは これらのDNSKEY RRそれぞれがゾーン鍵であることを示す。2つのDNSKEY RRの うちの1つにはSEPフラグが設定されており、頂点のDNSKEY RRsetに署名する ために使用されている。これは、親ゾーンに入れられるDSレコードを生成する ためにハッシュされているべきである。もう1つのDNSKEYはゾーン内の他のRRset 全てに署名するために使用される。 ゾーンはワイルドカードエントリー、"*.w.example"を含む。"*.w.example" という名前はNSECの連鎖を構築する際に使用されていること、および "*.w.example"のMX RRsetの署名を持つRRSIGのラベル数が2であることに 注意してもらいたい。 また、ゾーンには委任が2つある。"b.example"への委任はNS RRset、グルー アドレスレコードおよびNSEC RRを含む。ここでNSEC RRsetだけが署名付きである ことに注意してもらいたい。"a.example"への委任はDS RRを持ち、NSECおよび DS RRsetだけが署名付きであることに注意してもらいたい。 付録B. 応答の例 本セクションでは付録Aで示した署名付きゾーン例を使用した、応答メッセージの 例を示す。 B.1. 正常な回答 権威サーバへの問合わせが成功した場合。 ;; Header: QR AA DO RCODE=0 ;; ;; Question x.w.example. IN MX ;; Answer x.w.example. 3600 IN MX 1 xx.example. x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( 20040409183619 38519 example. Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I Arends, et al. Standards Track [Page 41] RFC 4035 DNSSEC Protocol Modifications March 2005 kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) ;; Authority example. 3600 NS ns1.example. example. 3600 NS ns2.example. example. 3600 RRSIG NS 5 1 3600 20040509183619 ( 20040409183619 38519 example. gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) ;; Additional xx.example. 3600 IN A 192.0.2.10 xx.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx kbIDV6GPPSZVusnZU6OMgdgzHV4= ) xx.example. 3600 AAAA 2001:db8::f00:baaa xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 20040409183619 38519 example. Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ xS9cL2QgW7FChw16mzlkH6/vsfs= ) ns1.example. 3600 IN A 192.0.2.1 ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK v/iVXSYC0b7mPSU+EOlknFpVECs= ) ns2.example. 3600 IN A 192.0.2.2 ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) Arends, et al. Standards Track [Page 42] RFC 4035 DNSSEC Protocol Modifications March 2005 B.2. 名前エラー 権威を持つ名前エラー。NSEC RRにより、その名前が存在しないことおよび 適用されるワイルドカードが存在しないことを証明している。 ;; Header: QR AA DO RCODE=3 ;; ;; Question ml.example. IN A ;; Answer ;; (empty) ;; Authority example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1081539377 3600 300 3600000 3600 ) example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 20040409183619 38519 example. ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) b.example. 3600 NSEC ns1.example. NS RRSIG NSEC b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ vhRXgWT7OuFXldoCG6TfVFMs9xE= ) example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( 20040409183619 38519 example. O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm jfFJ5arXf4nPxp/kEowGgBRzY/U= ) ;; Additional ;; (empty) Arends, et al. Standards Track [Page 43] RFC 4035 DNSSEC Protocol Modifications March 2005 B.3. 該当データ無しエラー "該当データ無し"応答。NSEC RRにより、その名前が存在しないことおよび 問合わされたRRタイプが存在しないことを証明している。 ;; Header: QR AA DO RCODE=0 ;; ;; Question ns1.example. IN MX ;; Answer ;; (empty) ;; Authority example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1081539377 3600 300 3600000 3600 ) example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 20040409183619 38519 example. ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) ;; Additional ;; (empty) B.4. 署名付きゾーンへの参照 署名付きゾーンへの参照。DS RRは、リゾルバが検証しなければならない、 子ゾーンの頂点にある対応するDNSKEY RRに関するデータを持つ。 ;; Header: QR DO RCODE=0 ;; Arends, et al. Standards Track [Page 44] RFC 4035 DNSSEC Protocol Modifications March 2005 ;; Question mc.a.example. IN MX ;; Answer ;; (empty) ;; Authority a.example. 3600 IN NS ns1.a.example. a.example. 3600 IN NS ns2.a.example. a.example. 3600 DS 57855 5 1 ( B6DCD485719ADCA18E5F3D48A2331627FDD3 636B ) a.example. 3600 RRSIG DS 5 2 3600 20040509183619 ( 20040409183619 38519 example. oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) ;; Additional ns1.a.example. 3600 IN A 192.0.2.5 ns2.a.example. 3600 IN A 192.0.2.6 B.5. 署名無しゾーンへの参照 署名無しゾーンへの参照。NSEC RRは、この委任に関するDS RRは親ゾーン側に 存在しないことを証明している。 ;; Header: QR DO RCODE=0 ;; ;; Question mc.b.example. IN MX ;; Answer ;; (empty) ;; Authority b.example. 3600 IN NS ns1.b.example. b.example. 3600 IN NS ns2.b.example. b.example. 3600 NSEC ns1.example. NS RRSIG NSEC b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ vhRXgWT7OuFXldoCG6TfVFMs9xE= ) Arends, et al. Standards Track [Page 45] RFC 4035 DNSSEC Protocol Modifications March 2005 ;; Additional ns1.b.example. 3600 IN A 192.0.2.7 ns2.b.example. 3600 IN A 192.0.2.8 B.6. ワイルドカード展開 ワイルドカード展開により回答を得た、成功した問合わせ。回答に含まれる RRSIG RRのラベル数は、この応答を生成するためにワイルドカードRRを 展開したことを示す。またNSEC RRはゾーン内により良く一致するものは 存在しないことを証明している。 ;; Header: QR AA DO RCODE=0 ;; ;; Question a.z.w.example. IN MX ;; Answer a.z.w.example. 3600 IN MX 1 ai.example. a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( 20040409183619 38519 example. OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw 4kX18MMR34i8lC36SR5xBni8vHI= ) ;; Authority example. 3600 NS ns1.example. example. 3600 NS ns2.example. example. 3600 RRSIG NS 5 1 3600 20040509183619 ( 20040409183619 38519 example. gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( 20040409183619 38519 example. OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) ;; Additional ai.example. 3600 IN A 192.0.2.9 ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( Arends, et al. Standards Track [Page 46] RFC 4035 DNSSEC Protocol Modifications March 2005 20040409183619 38519 example. pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) ai.example. 3600 AAAA 2001:db8::f00:baa9 ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 20040409183619 38519 example. nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 sZM6QjBBLmukH30+w1z3h8PUP2o= ) B.7. ワイルドカードによる該当データ無しエラー ワイルドカードの範囲にある名前の"該当データ無し"応答。NSEC RRは、 一致するワイルドカード名は問合わせを受けたタイプを持たず、また ゾーン内により良く一致するものも存在しないことを証明している。 ;; Header: QR AA DO RCODE=0 ;; ;; Question a.z.w.example. IN AAAA ;; Answer ;; (empty) ;; Authority example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1081539377 3600 300 3600000 3600 ) example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 20040409183619 38519 example. ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( 20040409183619 38519 example. OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp Arends, et al. Standards Track [Page 47] RFC 4035 DNSSEC Protocol Modifications March 2005 ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( 20040409183619 38519 example. r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 s1InQ2UoIv6tJEaaKkP701j8OLA= ) ;; Additional ;; (empty) B.8. 子ゾーンにおけるDSの該当データ無しエラー 誤って子ゾーンのネームサーバに送信されたQTYPE=DSの問合わせに対する "該当データ無し"応答。 ;; Header: QR AA DO RCODE=0 ;; ;; Question example. IN DS ;; Answer ;; (empty) ;; Authority example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1081539377 3600 300 3600000 3600 ) example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 20040409183619 38519 example. ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( 20040409183619 38519 example. O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm Arends, et al. Standards Track [Page 48] RFC 4035 DNSSEC Protocol Modifications March 2005 FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm jfFJ5arXf4nPxp/kEowGgBRzY/U= ) ;; Additional ;; (empty) 付録C. 認証の例 本セクションでは、付録Bに示した応答メッセージがどのように認証されるかを 示す。 C.1. 回答の認証 付録B.1の問合わせに対して、"x.w.example.com"のMX RRsetが返されている。 対応するRRSIGにより、MX RRsetはアルゴリズムが5、鍵タグが38519の "example"のDNSKEYによって署名されていることを示している。 この回答を認証するために、リゾルバは対応するDNSKEY RRを必要とする。 以下に、リゾルバがこのDNSKEY RRを取得する方法を記述する。 RRSIGは、MX RRsetのオリジナルTTLが3600だったことを示しているため、 認証を行うために現在のTTLを3600に置き換える。RRSIGのラベル フィールド値3は、回答がワイルドカード展開を経ずに得られた結果で あることを示している。"x.w.example.com"のMX RRsetを正規形式に変換し、 現在時刻は署名有効期間の開始日と終了日の間であるとみなすことにより、 署名は認証される。 C.1.1. 例示したDNSKEY RRの認証 本セクションでは、設定されたルートDNSKEY(またはDS RR)からDNS木構造を 下方に認証していき、目的とする"example" DNSKEY RRを認証するまでの 論理的手順を示す。この論理的手順は明確性のための提示である ことに注意してもらいたい。実装では、参照を受信した段階で認証の連鎖を 構築しても良いし、全てのRRsetを取得した後で認証の連鎖を構築しても よい。あるいはこれらの考え方を任意に組み合わせても構わない。 ここで示す例は、論理的な処理手順のみを明示するものであり、具体的な 実装規則を指示するものではない。 ここでは、リゾルバはあらかじめ設定されたルートゾーンのDNSKEY RR(または あらかじめ設定されたルートゾーンのDS RR)から処理を開始すると仮定する。 リゾルバは設定されたDNSKEY RRがルートのDNSKEY RRset内に存在するかどうか (または設定されたDS RRと一致するDNSKEY RRがルートのDNSKEY RRset内に 存在するかどうか)、DNSKEY RRがルートのDNSKEY RRsetに署名しているかどうか、 および署名が有効期間内であるかを検査する。全ての条件が満たされたならば、 DNSKEY RRset内の全ての鍵は認証されたと見なされる。次に、リゾルバは ルートのDNSKEY RRの中の1つ(あるいはより多く)を使用して、"example"DS RRsetを 認証する。リゾルバは、ルートのDNSKEY RRsetまたは"example" DS RRsetを 得るためにルートゾーンに問合わせをしなければならないかもしれないことに 注意してもらいたい。 Arends, et al. Standards Track [Page 49] RFC 4035 DNSSEC Protocol Modifications March 2005 DS RRsetがルートDNSKEYで一旦認証されたならば、認証された"example" DS RRの1つと一致する"example"DNSKEY RRを持つDNSKEY RRsetを検証する。 そのような"example" DNSKEYが見つかったならば、リゾルバはその DNSKEY RRが"example" DNSKEY RRsetに署名したかどうか、および署名が 有効期間内であるかを検査する。全ての条件が満たされたならば、 "example" DNSKEY RRset内の全ての鍵は認証されたと見なされる。 最後に、リゾルバは"example" DNSKEY RRset内にある、アルゴリズムが5で 鍵タグが38519のDNSKEY RRを検証する。このDNSKEYを使用して、応答に 含まれるRRSIGを認証する。複数の"example" DNSKEY RRのアルゴリズム、 鍵タグが一致した場合、各DNSKEY RRを試し、一致したDNSKEY RRのどれかが 先に記述したように署名を検証できたら、回答は認証される。 C.2. 名前エラー 付録B.2に示した問合わせは、問い合わせたデータは存在せずまた適用可能な ワイルドカードも存在しないことを証明するNSEC RRを返されている。 この否定応答は、両方のNSEC RRを検証することによって認証される。 NSEC RRは先に示したMX RRsetの認証手順と同様な手順で認証される。 C.3. 該当データ無しエラー 付録B.3に示した問合わせは、問い合わせたデータは存在するが一致する RRタイプは存在しないことを証明するNSEC RRを返されている。 この否定応答は、NSEC RRを検証することによって認証される。 NSEC RRは先に示したMX RRsetの認証手順と同様な手順で認証される。 C.4. 署名付きゾーンへの参照 付録B.4に示した問合わせは、署名付き"a.example."ゾーンへの参照を 返されている。DS RRは先に示したMX RRsetの認証手順と同様な手順で 認証される。DS RRを使用して"a.example" DNSKEY RRsetを認証する。 "example" DNSKEYを使用して、"a.example" DS RRsetが一旦認証されたならば、 リゾルバはDS RRと一致する"a.example" DNSKEY RRを持つ"a.example" DNSKEY RRsetを検証する。一致する"a.example" DNSKEYが見つかったならば、 リゾルバはそのDNSKEY RRが"a.example" DNSKEY RRsetに署名したかどうか、 および署名が有効期間内かどうかを検証する。全ての条件が満たされたならば、 "a.example" DNSKEY RRset内の全ての鍵は認証されたと見なされる。 Arends, et al. Standards Track [Page 50] RFC 4035 DNSSEC Protocol Modifications March 2005 C.5. 署名無しゾーンへの参照 付録B.5に示した問合わせは、署名無し"b.example"ゾーンへの参照を返されて いる。NSECは"example"から"b.example"への認証が存在しないことを証明して いる。NSEC RRは先に示したMX RRsetの認証手順と同様な手順で認証される。 C.6. ワイルドカード展開 付録B.6に示す問合わせはワイルドカード展開の結果生成された回答を返されて いる。回答部は、従来の応答と同様にワイルドカードRRsetが含まれる。また 対応するRRSIGは、展開されたワイルドカードMX RRsetはアルゴリズム5、 鍵タグ38519の"example" DNSKEYによって署名されたことを示す。 RRSIGはMX RRsetのオリジナルTTLが3600だったことを示しているので、認証を 行うために現在のTTLを3600に置き換える。"a.z.w.example"という名前は 4つのラベルを持つので、RRSIGのラベルフィールド値2は、回答はワイルド カード展開の結果であることを示している。"a.z.w.w.example"という名前は "*.w.example"に置き換えられ、MX RRsetは正規形式に変換される。そして現在 時刻は署名有効期間の開始日と終了日の間であるとみなすことにより、署名は 認証される。 NSECは問合わせに回答する際に、より良いもの(完全一致またはより良く一致する ワイルドカード)が存在しなかったことを証明し、またNSEC RRは回答が有効で あると認証される前に認証されなければならない。 C.7. ワイルドカードによる該当データ無しエラー 付録B.7に示す問合わせは、問合わせたデータは存在せず、また適用可能な ワイルドカードも存在しないことを証明するNSEC RRを返されている。 この否定応答は、両方のNSEC RRを検証することによって認証される。 C.8. 子ゾーンにおけるDSの該当データ無しエラー 付録B.8に示す問合わせは、問合わせは子サーバ("example"サーバ)が回答した ことを示すNSEC RRを返されている。NSEC RRはSOA RRの存在を示しているため、 回答が子から得られたものであることがわかる。"example" DS RRsetへの 問合わせを親サーバ("ルート"サーバ)に送るべきである。 Arends, et al. Standards Track [Page 51] RFC 4035 DNSSEC Protocol Modifications March 2005 著者の連絡先 Roy Arends Telematica Instituut Brouwerijstraat 1 7523 XC Enschede NL EMail: roy.arends@telin.nl Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA EMail: sra@isc.org Matt Larson VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA EMail: mlarson@verisign.com Dan Massey Colorado State University Department of Computer Science Fort Collins, CO 80523-1873 EMail: massey@cs.colostate.edu Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-8920 USA EMail: scott.rose@nist.gov Arends, et al. Standards Track [Page 52] RFC 4035 DNSSEC Protocol Modifications March 2005 完全な著作権表示 Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 知的所有権に関する表示 The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 謝辞 RFCエディタの活動に対する資金は現在Internet Societyによって提供されて いる。 Arends, et al. Standards Track [Page 53] RFC4035-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Service Co., Ltd. http://jprs.jp/tech/