ネットワークワーキンググループ B. Laurie Request for Comments: 5155 G. Sisson 分類: 標準化過程(Standards Track) R. Arends Nominet D. Blacka VeriSign, Inc. 2008年3月 DNSSECにおけるハッシュを使用した不在証明 本文書の位置づけ 本文書はインターネットコミュニティのためにインターネット標準化過程に あるプロトコルを規定し、改善に向けた議論と提案を求めるものである。 このプロトコルの標準化の状況については"Internet Official Protocol Standards"(STD 1)の最新版を参照のこと。本文書の配布は制限されない。 要旨 DNSSEC(Domain Name System Security Extensions)では、不在証明を行う NSECリソースレコード(RR)が導入された。本文書は、この代替となるNSEC3 リソースレコードを導入する。NSEC3はNSECと同様に不在証明を提供するが、 更にゾーン列挙に対抗する手段を提供し、委任が主たる内容の(delegation- centric)ゾーンを少しずつ拡大していくこともできるようにする。 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. 本仕様提案の理由 . . . . . . . . . . . . . . . . . . . . . 4 1.2. 要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. 後方互換性 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. NSEC3リソースレコード . . . . . . . . . . . . . . . . . . . . 7 3.1. RDATAフィールド . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. ハッシュアルゴリズム . . . . . . . . . . . . . . . . . 8 3.1.2. フラグ . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.3. 繰り返し . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.4. ソルト長 . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.5. ソルト . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.6. ハッシュ長 . . . . . . . . . . . . . . . . . . . . . . 9 3.1.7. 次ハッシュ化所有者名 . . . . . . . . . . . . . . . . . 9 3.1.8. タイプビットマップ . . . . . . . . . . . . . . . . . . 9 3.2. NSEC3 RDATAのワイヤフォーマット . . . . . . . . . . . . . 9 3.2.1. Tタイプビットマップのエンコーディング . . . . . . . . 10 3.3. 表記形式 . . . . . . . . . . . . . . . . . . . . . . . . . 11 Laurie, et al. Standards Track [Page 1] RFC 5155 NSEC3 March 2008 4. NSEC3PARAMリソースレコード . . . . . . . . . . . . . . . . . . 12 4.1. RDATAフィールド . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. ハッシュアルゴリズム . . . . . . . . . . . . . . . . . 12 4.1.2. フラグフィールド . . . . . . . . . . . . . . . . . . . 12 4.1.3. 繰り返し . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.4. ソルト長 . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.5. ソルト . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. NSEC3PARAM RDATAのワイヤフォーマット . . . . . . . . . . . 13 4.3. 表記形式 . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. ハッシュの計算 . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. 権威サーバに関する考慮点 . . . . . . . . . . . . . . . . . . . 16 7.1. ゾーン署名 . . . . . . . . . . . . . . . . . . . . . . . . 16 7.2. ゾーンの提供 . . . . . . . . . . . . . . . . . . . . . . . 17 7.2.1. 最近接名の証拠 . . . . . . . . . . . . . . . . . . . . 18 7.2.2. "Name Error"応答 . . . . . . . . . . . . . . . . . . . 19 7.2.3. QTYPEがDSでない場合の"No Data"応答 . . . . . . . . . . 19 7.2.4. QTYPEがDSである場合の"No Data"応答 . . . . . . . . . . 19 7.2.5. "Wildcard No Data"応答 . . . . . . . . . . . . . . . . 19 7.2.6. "Wildcard Answer"応答 . . . . . . . . . . . . . . . . 20 7.2.7. 未署名サブゾーンへの参照 . . . . . . . . . . . . . . . 20 7.2.8. NSEC3の所有者名への問合わせに対する応答 . . . . . . . 20 7.2.9. 問合わせ実行時の衝突に対するサーバ応答 . . . . . . . . 21 7.3. セカンダリサーバ . . . . . . . . . . . . . . . . . . . . . 21 7.4. 未知のハッシュアルゴリズムを使用するゾーン . . . . . . . . 21 7.5. ダイナミックアップデート . . . . . . . . . . . . . . . . . 21 8. バリデータに関する考慮点 . . . . . . . . . . . . . . . . . . . 23 8.1. 未知のハッシュタイプの応答 . . . . . . . . . . . . . . . . 23 8.2. NSEC3 RRの検証 . . . . . . . . . . . . . . . . . . . . . . 23 8.3. 最近接名の証拠 . . . . . . . . . . . . . . . . . . . . . . 23 8.4. "Name Error"応答の検証 . . . . . . . . . . . . . . . . . . 24 8.5. "No Data"応答の検証: QTYPEがDSでない場合 . . . . . . . . . 24 8.6. "No Data"応答の検証: QTYPEがDSの場合 . . . . . . . . . . . 24 8.7. "Wildcard No Data"応答の検証 . . . . . . . . . . . . . . . 25 8.8. "Wildcard Answer"応答の検証 . . . . . . . . . . . . . . . 25 8.9. 未署名サブゾーンへの参照の検証 . . . . . . . . . . . . . . 25 9. リゾルバに関する考慮点 . . . . . . . . . . . . . . . . . . . . 26 9.1. NSEC3リソースレコードのキャッシュ . . . . . . . . . . . . 26 9.2. ADビットの使用 . . . . . . . . . . . . . . . . . . . . . . 26 10. 特別な考慮点 . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.1. ドメイン名長の制約 . . . . . . . . . . . . . . . . . . . . 26 10.2. ゾーン頂点のDNAME . . . . . . . . . . . . . . . . . . . . 27 10.3. 繰り返し . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.4. 署名ゾーンにおけるNSECからNSEC3への移行 . . . . . . . . . 28 10.5. 署名ゾーンにおけるNSEC3からNSECへの移行 . . . . . . . . . 28 11. IANAに関する考慮点 . . . . . . . . . . . . . . . . . . . . . . 29 12. セキュリティに関する考慮点 . . . . . . . . . . . . . . . . . . 30 12.1. ハッシュに関する考慮点 . . . . . . . . . . . . . . . . . . 30 Laurie, et al. Standards Track [Page 2] RFC 5155 NSEC3 March 2008 12.1.1. 辞書攻撃 . . . . . . . . . . . . . . . . . . . . . . . 30 12.1.2. ハッシュの衝突 . . . . . . . . . . . . . . . . . . . . 31 12.1.3. 新しいハッシュアルゴリズムへの移行 . . . . . . . . . . 31 12.1.4. 大きな繰り返し値の使用 . . . . . . . . . . . . . . . . 31 12.2. オプトアウトに関する考慮点 . . . . . . . . . . . . . . . . 32 12.3. その他の考慮点 . . . . . . . . . . . . . . . . . . . . . . 33 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 13.1. Normative References . . . . . . . . . . . . . . . . . . . 33 13.2. Informative References . . . . . . . . . . . . . . . . . . 34 付録A. ゾーンの例 . . . . . . . . . . . . . . . . . . . . . . . . 35 付録B. 応答の例 . . . . . . . . . . . . . . . . . . . . . . . . 40 B.1. "Name Error"応答 . . . . . . . . . . . . . . . . . . . . . 40 B.2. "No Data"応答 . . . . . . . . . . . . . . . . . . . . . . 42 B.2.1. 空の非終端が原因の"No Data"応答 . . . . . . . . . . . 43 B.3. Opt-Out未署名ゾーンへの参照 . . . . . . . . . . . . . . . 44 B.4. "Wildcard Answer"応答 . . . . . . . . . . . . . . . . . . 45 B.5. "Wildcard No Data"応答 . . . . . . . . . . . . . . . . . . 46 B.6. 子ゾーンへのDS問合わせに対する"No Data"応答 . . . . . . . 48 付録C. 特別な考慮点 . . . . . . . . . . . . . . . . . . . . . . . 48 C.1. ソルトの使用 . . . . . . . . . . . . . . . . . . . . . . . 49 C.2. ハッシュの衝突 . . . . . . . . . . . . . . . . . . . . . . 49 C.2.1. NSEC3生成におけるハッシュ衝突の回避 . . . . . . . . . 50 C.2.2. 第二原像計算困難性に関する要求分析 . . . . . . . . . 50 Laurie, et al. Standards Track [Page 3] RFC 5155 NSEC3 March 2008 1. はじめに 1.1. 本仕様提案の理由 DNSSECは、不在証明を行うためにNSEC RRを導入した。NSEC RRは不在証明を 行うという要件を満たすが、ゾーン内容を列挙できてしまうという副作用を もたらした。この副作用が望ましくないポリシー問題を発生させている。 ゾーン列挙は、署名ゾーンに存在するNSECレコードのセットにより可能となる。 NSECレコードは、正規化順に整列された2つの名前を列挙することで、その間に 何も存在しないことを示す。したがって、NSECレコードの全セットはゾーンの 全ての名前を列挙する。存在しない名前を問い合わせることで、ゾーンの内容を 収集することは容易である。 ゾーン列挙で得られた情報により、例えば以下のようなことが可能となる。 得た情報を元にしてSPAMを送るメールアドレスを推測すること、多くの レジストリが法的に保護責任を持つ登録者情報を暴くために、WHOISに対して 多量の問合わせを行う際の検索鍵として使用することなどである。 このような理由により、多くのレジストリでは、レジストリ自身が管理する ゾーンデータの複製を禁止しているが、NSEC RRを使用すると、このポリシーの 強制力が失われる。 もう1つの問題は、次に示す2つの事例では、未署名ゾーンへの委任に対して 暗号を使用してセキュリティを保つコストが、予想されるセキュリティ上の 恩恵よりも高くなってしまうことである。2つの事例とはすなわち、委任が 主たる内容の大規模ゾーンと、"Insecure(未署名状況検出：信頼度低)"な 委任が短期間で更新されるゾーンの場合である。これらの事例では NSEC RRの連鎖を維持するコストが非常に高くなるので、(これらの未署名 ゾーンに対して) "Opt-Out"方式を利用することがより適当である。 本文書では、これらの問題を軽減するために、NSECの代替として使用可能な NSEC3リソースレコードを提示する。 この問題に取り組んだ初期の検討結果が[DNSEXT-NO]、[RFC4956]、 [DNSEXT-NSEC2v2]にある。 1.2. 要件 本文書におけるキーワード"しなければならない(MUST)"、"してはならない (MUST NOT)"、"要求される(REQUIRED)"、"するものとする(SHALL)"、 "しないものとする(SHALL NOT)"、"すべきである(SHOULD)"、 "すべきでない(SHOULD NOT)"、"推奨される(RECOMMENDED)"、 "してもよい/することができる(MAY)"、"任意である(OPTIONAL)"は、 [RFC2119]の記述どおりに解釈するものとする。 Laurie, et al. Standards Track [Page 4] RFC 5155 NSEC3 March 2008 1.3. 用語 本文書の読者は、[RFC1034]、[RFC1035]と、これらのRFCを更新した [RFC2136]、 [RFC2181]、[RFC2308]、および[RFC4033]、[RFC4034]、[RFC4035]に記述される 基本的なDNS、DNSSECの概念に精通しているものとする。 本文書を通して以下の用語を使用する。 ゾーン列挙: 成功した問合わせを元にゾーンの全内容を見破ろうとする 試み。DNSSEC導入以前は、ゾーン列挙を行うことは容易でなかった。 オリジナル所有者名: ハッシュ化所有者名に対応する所有者名。 ハッシュ化所有者名: 所有者名にハッシュ関数を適用した後に生成される 所有者名。 ハッシュ整列順: ハッシュ化所有者名がその数値に応じて配列される順序。 最左端(最低数値)オクテットを最上位オクテットとして扱う。 この順序は、ハッシュ化所有者名をBase32により拡張16進アルファベット (Extended Hex Alphabet)[RFC4648]でエンコードした場合に、[RFC4034]で 規定されるDNS名の正規化整列順と同じになることに注意してもらいたい。 空の非終端: 1つ以上のサブドメインがリソースレコードを持つが自身は リソースレコードを持たないドメイン名。 委任: 現在のゾーン頂点(zone apex)とは異なる(つまりゾーン頂点でない) 名前を持つNS RRsetであり、子ゾーンへの委任を表す。 "Secure"な委任: 委任(NS RRset)と署名されたDS RRsetを持つ名前であり、 署名された子ゾーンへの委任を表す。 "Insecure"な委任: 委任(NS RRset)を持つが、DS RRsetが無い名前で あり、未署名の子ゾーンへの委任を表す。 Opt-Out NSEC3リソースレコード: Opt-Outフラグフィールドが1に設定されている NSEC3リソースレコード。 Opt-Out ゾーン: 1つ以上のOpt-Out NSEC3 RRを持つゾーン。 最近接名(Closest Encloser): ある名前に最長一致する実在の名前で、先祖 (訳注: 親、親の親等)にあたるもの。[RFC4592]のセクション3.3.1も 参照のこと。 Laurie, et al. Standards Track [Page 5] RFC 5155 NSEC3 March 2008 証明可能な最近接名(Closest Provable Encloser): ある名前に最長一致する 実在の名前で、先祖にあたり、かつ存在証明が可能なもの。 これは、Opt-Out ゾーンにおいてのみ最近接名と異なることに注意して もらいたい。 次近接名(Next Closer Name): ある名前の証明可能な最近接名より1ラベル 長い名前。 Base32: [RFC4648]で規定される"拡張16進アルファベットを使用した Base32エンコーディング"。NSEC3仕様では、末尾パディング文字("=")は 使用しないことに注意してもらいたい。 カバーする: ある名前もしくは次近接名のハッシュが、NSEC3の所有者名と 次ハッシュ化所有者名の間にあるとき、そのNSEC3 RRはその名前を "カバーする"という。言い換えれば、NSEC3が名前の不在を証明する場合、 直接またはその名前の先祖の不在を証明するかどちらかの方法を使用する。 一致する: ある名前のハッシュ化所有者名が、NSEC3の所有者名と同じ場合、 そのNSEC3 RRはその名前に"一致する"という。 2. 後方互換性 本仕様は、[RFC4033][RFC4034][RFC4035]に対して基本的に後方互換性のない プロトコル変更を記述する。特に、本仕様に対応しないDNSSEC対応リゾルバ (NSEC3非対応リゾルバ)は、本文書の変更が反映された応答の検証に失敗 するだろう。 本仕様の普及を支援するために、NSEC3を使用する署名ゾーンからの応答を NSEC3非対応リゾルバが検証しないよう、シグナル技法を使用する。 この目的のため、本仕様では2つの新しいDNSKEYアルゴリズムを採用する。 アルゴリズム6(DSA-NSEC3-SHA1)はアルゴリズム3(DSA)の別名であり、 アルゴリズム7(RSASHA1-NSEC3-SHA1)はアルゴリズム5(RSASHA1)の別名である。 これらは新しいアルゴリズムではなく、既存アルゴリズムの追加IDである。 本仕様に対応した署名ゾーンは、DNSKEY RRにこれらのアルゴリズムIDのみを 使用しなければならない(MUST)。これらの新しいIDは、既存のNSEC3非対応 リゾルバにとっては未知のものであるから、これらのリゾルバは、 [RFC4035]のセクション5.2の詳細に従い、NSEC3を使用する署名ゾーンを "Insecure"と見なすだろう。 これらのアルゴリズムIDはNSEC3のハッシュアルゴリズムであるSHA1とともに 用いられる。SHA1以外のNSEC3ハッシュアルゴリズムを使用する場合、 新しい別名が必要となる(セクション12.1.3参照)。 Laurie, et al. Standards Track [Page 6] RFC 5155 NSEC3 March 2008 本仕様準拠のDNSSEC対応リゾルバは、新しいアルゴリズムIDを認識し、 別名の元になっているアルゴリズムと等しいものとして扱わなければ ならない(MUST)。 DNSSECの署名ゾーンをNSEC3を使用する署名ゾーンに移行する方法については、 セクション10.4で議論する。 3. NSEC3リソースレコード NSEC3リソースレコード(RR)は、DNSリソースレコードセットの不在証明を 提供する。 NSEC3 RRは、NSEC3 RRのオリジナル所有者名に対して存在するRRタイプを 列挙する。また、ゾーンのハッシュ整列順に従う次ハッシュ化所有者名を含む。 ゾーンのNSEC3 RRの完全なセットは、NSEC3 RRのオリジナル所有者名に対して 存在しているRRsetを示し、またゾーン内のハッシュ化所有者名の連鎖を 形成する。この情報は、DNSデータの不在証明を提供するために使用される。 ゾーン列挙を防ぐため、NSEC3 RRで使用される所有者名は、オリジナル所有者名の 暗号ハッシュを単一ラベルとしてゾーン名の前に付加したものである。 NSEC3 RRは、ハッシュ値生成時に使用したハッシュ関数、使用したソルト、 オリジナル所有者名へのハッシュ関数の適用回数を示す。 これらのハッシュ技法については、セクション5に完全な記述がある。 未署名委任のハッシュ化所有者名は、連鎖から取り除いてもよい。この場合、 未署名委任のハッシュ化所有者名または次近接名をカバーするNSEC3 RRは Opt-Out NSEC3 RRとみなされ、フラグ指定によりそれが明示される。 NSEC3 RRの所有者名は、ハッシュ化所有者名のBase32エンコーディングを 単一ラベルとしてゾーン名の前に付加したものである。 NSEC3 RRのタイプ値は50である。 NSEC3 RRのRDATAフォーマットはクラス非依存である。詳細は後述する。 NSEC3 RRのクラスはオリジナル所有者名のクラスに一致していなければ ならない(MUST)。 NSEC3 RRは、SOAの最小TTLフィールドと同じTTL値を持つべきである (SHOULD)。これはネガティブキャッシュ[RFC2308]の原則に従うことを 意味する。 Laurie, et al. Standards Track [Page 7] RFC 5155 NSEC3 March 2008 3.1. RDATAフィールド 3.1.1. ハッシュアルゴリズム ハッシュアルゴリズムフィールドは、ハッシュ値生成時に使用する暗号ハッシュ アルゴリズムを指定する。 このフィールドの値は、セクション11に記述するNSEC3ハッシュアルゴリズム レジストリで定義される。 3.1.2. フラグ フラグフィールドは、異なる処理を示すために使用可能な8つの1ビットフラグを 含む。未定義のフラグは全て0でなければならない。本仕様で定義するフラグは Opt-Outフラグだけである。 3.1.2.1. Opt-Outフラグ Opt-Outフラグが設定されている場合、そのNSEC3 RRは0以上の未署名委任を カバーしている。 Opt-Outフラグが設定されていない場合、そのNSEC3 RRは未署名委任をカバー していない。 Opt-Outフラグは、NSEC3 RRが未署名委任をカバーしているかどうかを示す。 これはフラグフィールドの最下位ビットで指定する。このフラグの使用に関する 詳細は、セクション6を参照のこと。 3.1.3. 繰り返し 繰り返しフィールドは、追加でハッシュ関数を実行する回数を指定する。 繰り返し回数を増やせば、辞書攻撃に対して耐性の大きいハッシュ値の生成が 可能となるが、サーバ・リゾルバの双方にとって計算コストが高くなる。 このフィールドの使用の詳細についてはセクション5を、値の制約については セクション10.3を参照のこと。 3.1.4. ソルト長 ソルト長フィールドは、ソルトフィールドのオクテット長を、0から255の 範囲の値で指定する。 3.1.5. ソルト 予め計算された辞書攻撃を防御するため、ソルトフィールドはハッシュ化前に オリジナル所有者名に付加される。ソルトの使用方法の詳細については セクション5を参照のこと。 Laurie, et al. Standards Track [Page 8] RFC 5155 NSEC3 March 2008 3.1.6. ハッシュ長 ハッシュ長フィールドは、次ハッシュ化所有者名フィールドのオクテット長を、 1から255の範囲の値で指定する。 3.1.7. 次ハッシュ化所有者名 次ハッシュ化所有者名フィールドは、ハッシュ整列順に従う次ハッシュ化 所有者名を含む。この値はバイナリ形式となる。全ハッシュ化所有者名を 整列した集合がある場合に、あるNSEC3 RRの次ハッシュ化所有者名フィールドは、 そのNSEC3 RRの所有者名の直後にくる所有者名のハッシュを含む。 ハッシュ整列順でゾーン最後尾となるNSEC3 RRの次ハッシュ化所有者名 フィールドの値は、ゾーン先頭のNSEC3 RRの所有者名と等しい。NSEC3 RRの 所有者名とは異なり、このフィールドの値にはゾーン名が付加されないことに 注意してもらいたい。 3.1.8. タイプビットマップ タイプビットマップフィールドは、NSEC3 RRのオリジナル所有者名に対して 存在するRRsetのタイプを指定する。 3.2. NSEC3 RDATAのワイヤフォーマット NSEC3 RRのRDATAを以下に示す。 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ハッシュ | フラグ | 繰り返し | | アルゴリズム | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソルト長 | ソルト / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ハッシュ長 | 次ハッシュ化所有者名 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / タイプビットマップ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ハッシュアルゴリズムは1オクテットである。 以下に示す通り、フラグフィールドは1オクテットであり、Opt-Outフラグが 最下位ビットとなる。 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | |O| +-+-+-+-+-+-+-+-+ Laurie, et al. Standards Track [Page 9] RFC 5155 NSEC3 March 2008 繰り返しは符号なし16ビットの整数で表され、最上位ビットが先頭になる。 ソルト長は符号なしオクテットで表され、ソルトフィールドのオクテット長を 表す。値が0であれば、続くソルトフィールドは省略される。 ソルトが存在する場合、バイナリのオクテット列でエンコードされる。 フィールドの長さは、先行するソルト長フィールドで指定される。 ハッシュ長は符号なしオクテットで表され、次ハッシュ化所有者名フィールドの オクテット長を表す。 NSEC3 RRの所有者名とは異なり、次ハッシュ化所有者名はBase32エンコード ではなく、無変換のバイナリのハッシュ値である。これはゾーンの名前を 含まない。このフィールドの長さは、先行するハッシュ長フィールドで 指定される。 3.2.1. タイプビットマップのエンコーディング タイプビットマップフィールドのエンコーディングは、NSEC RRが使用する タイプビットマップフィールドのエンコーディング([RFC4034]記載)と同じ である。ここでは明確化のためにあらためて説明する。 RRタイプ空間を256のウインドウブロックに分割する。各ブロックは16ビットの RRタイプ空間のうち、下位8ビットを表現する。アクティブなRRタイプを 少なくとも1つ持つブロックは、1オクテットのウインドウ番号(0～255)、 そのブロックが使用するビットマップのオクテット数を示す1オクテットの ビットマップ長(1～32)、最大32オクテット(256ビット)のビットマップを使用して エンコードされる。 各ブロックは、ウインドウ番号の小さいものから順にNSEC3 RR RDATA内に 保存される。 タイプビットマップフィールド = ( ウインドウブロック番号 | ビットマップ長 | ビットマップ )+ "|"は連結を表す。 各ビットマップはウインドウブロック内に保存されたRRタイプの下位8ビットを ネットワークビットオーダでエンコードしたものである。 ビットマップの第1ビットがビット0に相当する。ウインドウブロック0の場合、 ビット1はタイプ1(A)に相当し、ビット2はタイプ2(NS)に相当する。 以下同様である。ウインドウブロック1の場合、ビット1はRRタイプ257に相当し、 ビット2はRRタイプ258に相当する。 ビットが1に設定されている場合、NSEC3 RRのオリジナル所有者名に対して そのビットが表現するタイプのRRsetが存在していることを意味する。 ビットが0に設定されている場合、NSEC3 RRのオリジナル所有者名に当該ビットが 表現するタイプのRRsetは存在しないことを意味する。 Laurie, et al. Standards Track [Page 10] RFC 5155 NSEC3 March 2008 ウインドウブロック0におけるビット0は、存在しないRRタイプ0を参照する ため、0に設定しなければならない(MUST)。検証後は、バリデータ(validator： 署名検証モジュール)はウインドウブロック0のビット0の値を無視しなければ ならない(MUST)。 [RFC2929]のセクション3.1で規定されるメタタイプ(Meta-TYPE)や QTYPE、またはQTYPE・メタタイプ割当てのために予約された範囲のものは ゾーンデータには現れないので、これを表現するビットは0に設定され なければならない(MUST)。当該ビットが設定されていた場合は、読み出し時に 無視しなければならない(MUST)。 タイプを持たない、つまりビットマップが全て0のブロックを含めては ならない(MUST NOT)。ビットマップ内で末尾に続く0のオクテット列 (trailing zero octets)は省略しなければならない。 各ブロックのビットマップ長は、NSEC3 RRのオリジナル所有者名に対して 設定されるRRタイプ値の中で、そのブロックが表現しようとするタイプコードの 最大値に応じて決定される。末尾に続くオクテット列が明示的に指定されて いないのであれば、それは存在しない(ゼロオクテット)と解釈しなければ ならない(MUST)。 3.3. 表記形式 RDATA部の表記形式は以下のとおりである。 ・ ハッシュアルゴリズムフィールドは符号なし10進整数で表記する。 最大値は255である。 ・ フラグフィールドは符号なし10進整数で表記する。最大値は255である。 ・ 繰り返しフィールドは符号なし10進整数で表記する。値は0以上65535以下 である。 ・ ソルト長フィールドは表記しない。 ・ ソルトフィールドは大文字小文字を区別しない16進数列で表記する。 空白文字を16進数列内で用いてはならない。ソルト長フィールドの値 が0の場合、ソルトフィールドは"-"(引用符は除く)と表記すること。 ・ ハッシュ長フィールドは表記しない。 ・ 次ハッシュ化所有者名フィールドは、大文字小文字を区別しないBase32 文字列で表記する。この際空白文字は使用せず、またPADも付加されない。 ・ タイプビットマップフィールドはRRタイプのニーモニック(簡略化して 表記した文字列)の並びとして表記する。ニーモニックが不明な際には、 [RFC3597]のセクション5に記述されるタイプ表記を使用しなければ ならない(MUST)。 Laurie, et al. Standards Track [Page 11] RFC 5155 NSEC3 March 2008 4. NSEC3PARAMリソースレコード NSEC3PARAM RRは、権威サーバがハッシュ化所有者名を計算する際に必要な NSEC3パラメータ(ハッシュアルゴリズム、フラグ、繰り返し、ソルト)を保持 する。ゾーン頂点にNSEC3PARAM RRが存在するということは、不在応答を 行う際に、権威サーバが適切なNSEC3 RRのセットを選択するために、 NSEC3PARAM RRが指定するパラメータを使用できることを意味する。 NSEC3PARAM RRはバリデータやリゾルバが使用するものではない。 ゾーン頂点にフラグフィールド値が0のNSEC3PARAM RRが存在する場合、 ゾーン内の全てのハッシュ化所有者名について、NSEC3PARAM RRが指定するものと 同じハッシュアルゴリズム、繰り返し、ソルトパラメータを使用したNSEC3 RRが 存在しなければならない(MUST)。つまり、ゾーンは同一のハッシュアルゴリズム、 繰り返し、ソルトパラメータによるNSEC3 RRの完全なセットを含んでいなければ ならない(MUST)。 NSEC3PARAM RRの所有者名はゾーン頂点の名前である。 NSEC3PARAM RRのタイプ値は51である。 NSEC3PARAM RRのRDATAフォーマットはクラスに依らない。詳細は後述する。 NSEC3PARAM RRのクラスは、このレコードが参照するNSEC3 RRと同一でなけれ ばならない(MUST)。 4.1. RDATAフィールド このRRのRDATAはNSEC3 RRの最初の4フィールドと同じである。 4.1.1. ハッシュアルゴリズム ハッシュアルゴリズムフィールドは、ハッシュ値生成時に使用する暗号ハッシュ アルゴリズムを指定する。 許容される値は、NSEC3 RRの対応フィールドと同じである。 4.1.2. フラグフィールド Opt-Outフラグは使用せず、0に設定しておく。 その他のフラグは全て将来の使用のために予約されており、0としなければ ならない。 フラグフィールド値が0以外のNSEC3PARAM RRは、無視しなければ ならない(MUST)。 Laurie, et al. Standards Track [Page 12] RFC 5155 NSEC3 March 2008 4.1.3. 繰り返し 繰り返しフィールドは、追加でハッシュを実行する回数を指定する。 許容される値は、NSEC3 RRの対応フィールドと同じである。 4.1.4. ソルト長 ソルト長フィールドは、ソルトのオクテット長を、0から255の範囲の値に よって指定する。 4.1.5. ソルト ソルトフィールドはハッシュ化前にオリジナル所有者名に付加される。 4.2. NSEC3PARAM RDATAのワイヤフォーマット NSEC3PARAM RRのRDATAを以下に示す。 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ハッシュ | フラグ | 繰り返し | | アルゴリズム | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソルト長 | ソルト / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ハッシュアルゴリズムは1オクテットである。 フラグフィールドは1オクテットである。 繰り返しは符号なし16ビットの整数で表され、最上位ビットが先頭になる。 ソルト長は符号なしオクテットで表され、引き続くソルトフィールドの オクテット長を表す。値が0であれば、続くソルトフィールドは省略される。 ソルトが存在する場合、バイナリのオクテット列としてエンコードされる。 ソルトフィールド長は直前のソルト長フィールドにおいて指定される。 Laurie, et al. Standards Track [Page 13] RFC 5155 NSEC3 March 2008 4.3. 表記形式 RDATA部の表記形式は以下のとおりである。 ・ ハッシュアルゴリズムフィールドは符号なし10進整数で表記する。 最大値は255である。 ・ フラグフィールドは符号なし10進整数で表記する。最大値は255である。 ・ 繰り返しフィールドは符号なし10進整数で表記する。値は0以上65535以下 である。 ・ ソルト長フィールドは表記しない。 ・ ソルトフィールドは大文字小文字を区別しない16進数列で表記する。 空白文字を16進数列内で用いてはならない。ソルト長フィールドの値 が0の場合、ソルトフィールドは"-"(引用符は除く)と表記すること。 5. ハッシュの計算 ハッシュ計算では、NSEC3 RDARTAフィールドのうち、ハッシュアルゴリズム、 ソルト、繰り返し回数の3つを使用する。 NSEC3 RRが指定するハッシュアルゴリズムを使用した x のハッシュをH(x)、 繰り返し回数を k とする。また、||は結合を意味するものとする。 ここで、 k = 0 の場合 IH(ソルト, x, 0) = H(x || ソルト) k > 0 の場合 IH(ソルト, x, k) = H(IH(ソルト, x, k-1) || ソルト) を定義する。 算出されるハッシュ化所有者名は、 IH(ソルト, 所有者名, 繰り返し回数) となる。ただし、所有者名は正規形式であるものとする。正規形式の所有者名は、 以下の条件を満たす所有者名のワイヤフォーマットと定義する。 1. 所有者名が(DNS名前圧縮されずに)完全に展開され、FQDN表記になっている。 2. 全てのUS-ASCII大文字が対応するUS-ASCII小文字に置き換えられている。 Laurie, et al. Standards Track [Page 14] RFC 5155 NSEC3 March 2008 3. 所有者名がワイルドカード名の場合、所有者名は展開されずにそのまま "*"ラベルを含んだ形式となっている(ワイルドカード展開されていない)。 この形式は、[RFC4034]のセクション6.2で定義されるものである。 ハッシュの計算方法は[RFC2898]に基づくものである。 6. Opt-Out 本仕様は、[RFC4033][RFC4034][RFC4035]と同様に、委任点のNS RRsetには 署名せず、DS RRsetを付随させる。Opt-Out ビットが設定されていない場合、 子ゾーンのセキュリティ状態は、委任点のハッシュ化所有者名を持つ 署名されたNSEC3 RRが暗号論的に証明するもの、具体的にDS RRの有無で 決まる。Opt-Outフラグが設定される場合はこの状況が変わり、委任点の ハッシュ化所有者名に対応するNSEC3 RRが無い"Insecure"な委任が署名ゾーンに 存在できるようになる。 委任点のハッシュ化所有者名または次近接名がOpt-Out NSEC3 RRの所有者名と 次ハッシュ化所有者名の間にある場合、当該Opt-Out NSEC3 RRは委任を カバーしているという。 Opt-Out NSEC3 RRは、それがカバーする"Insecure"な委任の有無を主張する ものではない。これにより、NSEC3 RR連鎖に対する再計算やNSEC3 RRへの 再署名を行わずに"Insecure"な委任の追加・削除が可能となる。ただし、 Opt-Out NSEC3 RRは、権威を持つその他のRRsetの存在(不在)は主張する。 Opt-Out NSEC3 RRは、"Insecure"な委任のオリジナル所有者名と同じ名前を 持ってもよい(MAY)。この場合、署名されたNSEC3 RRは委任の存在を主張し、 タイプビットマップにDSビットがないことからその委任が"Insecure"なことが 証明される。 Opt-Outを使用するゾーンに、Opt-OutNSEC3 RRと非Opt-Out NSEC3 RRを混在 させてもよい(MAY)。NSEC3 RRがOpt-Outでない場合、NSEC3 RRとNSEC3の RDATA内で指定される次ハッシュ化所有者名の間に、"Insecure"な委任 (および他のあらゆるRR)のハッシュ化所有者名が存在してはならない(MUST NOT)。 NSEC3 RRがOpt-Outの場合、NSEC3 RRは"Insecure"な委任のハッシュ化所有者名 またはハッシュ化次近接名のみをカバーしなければならない(MUST)。 ゾーンへの署名・ゾーンの提供、応答の検証におけるOpt-Outフラグの 影響については、以後のセクションに記述する。 Laurie, et al. Standards Track [Page 15] RFC 5155 NSEC3 March 2008 7. 権威サーバに関する考慮点 7.1. ゾーン署名 NSEC3を使用するゾーンは以下の条件を満たさなければならない。 ・ ゾーン内に権威を持つRRsetを保持する所有者名は、対応するNSEC3 RRを 持たなければならない(MUST)。未署名委任に対応する所有者名は、 対応するNSEC3 RRを保持してもよい(MAY)。ただし、対応するNSEC3 RRが 存在しない場合は、委任の次近接名をカバーするOpt-Out NSEC3 RRが 存在しなければならない(MUST)。他の権威を持たないRRはNSEC3 RRには 表記されない。 ・ 空の非終端は、Opt-Out NSEC3 RRがカバーする"Insecure"な委任から 派生しているのでない限り、対応するNSEC3 RRを持たなければならない (MUST)。 ・ 全てのNSEC3 RRのTTL値は、ゾーンのSOA RRの最小TTLフィールドの値と 同じにすべきである(SHOULD)。 ・ 署名ゾーン内にあるNSEC3 RRのタイプビットマップフィールドは、 NSEC3 RRそれ自身のタイプを除き、オリジナル所有者名が保持する 全てのタイプ の存在を示さなければならない(MUST)。これは、NSEC3タイプは タイプビットマップに存在しないことを意味することに注意してもらいたい。 以下の手順は、NSEC3 RRを適切に構成する方法を記述したものである。 これが考えられる唯一の方法というわけではない。 1. ハッシュアルゴリズム、ソルト値、繰り返し値を決定する。 2. ゾーン内の一意なオリジナル所有者名それぞれに対してNSEC3 RRsetを 追加する。 * Opt-Out を使用中である場合、未署名委任の所有者名は除外しても よい(MAY)。 * NSEC3 RRの所有者名は、オリジナル所有者名をハッシュ化し、 ゾーン名の前に単一ラベルとして付加したものである。 * 次ハッシュ化所有者名フィールドは当座空のままとする。 * Opt-Outを使用中である場合、Opt-Out ビットを1に設定する。 * 衝突を検出するために、任意でオリジナル所有者名をNSEC3 RRと併せて 記録する。 Laurie, et al. Standards Track [Page 16] RFC 5155 NSEC3 March 2008 * 加えて、衝突を検出するために、任意でアスタリスクラベルを前に 付加したオリジナル所有者名(この所有者名に子のワイルドカードが 存在する形の名前)に対応する付加的なNSEC3 RRを追加で生成し、 このオリジナル所有者名を記録する。このNSEC3 RRには"暫定"と 印をつける。 3. オリジナル所有者名が保持する各RRsetについて、タイプビットマップ フィールドの対応ビットを設定する。 4. ゾーン頂点のラベル数とオリジナル所有者名のラベル数の差が1より大きい 場合、ゾーン頂点とオリジナル所有者名の間にある全ての空の非終端に 対して、追加のNSEC3 RRを加える必要がある。この処理は重複した ハッシュ化所有者名を持つNSEC3 RRを生成する可能性がある。 衝突を検出するために、任意でこれらのNSEC3 RRのオリジナル所有者名を 記録するとともに、ステップ2と同様のやり方で暫定NSEC3 RRを生成し、 ワイルドカードの衝突を検出できるようにする。 5. NSEC3 RRのセットをハッシュ整列順に従って整列する。 6. 同一のハッシュ化所有者名を持つNSEC3 RRを一つにまとめる。これは、同じ ハッシュ化所有者名を持つ複数のNSEC3 RRを、各NSEC3 RRが示すタイプを 集約して構成した新しいタイプビットマップを持つ単一のNSEC3 RRに 置き換えるということである。オリジナル所有者名が記録対象になっている 場合、一体化する複数のNSEC3 RRは同じオリジナル所有者名を持つはず なので、一体化処理の段階で衝突を検出できるだろう。暫定的に生成した NSEC3 RRは全て廃棄する。 7. 各NSEC3 RRにおいて、ハッシュ整列順にしたがった次のNSEC3 RRの 値を、次ハッシュ化所有者名として挿入する。ゾーン末尾のNSEC3 RRの 次ハッシュ化所有者名には、ハッシュ整列順で先頭にあるNSEC3 RRの ハッシュ化所有者名を含める。 8. 最後に、同じハッシュアルゴリズム、繰り返し、ソルトフィールドを 持つNSEC3PARAM RRをゾーン頂点に追加する。 ハッシュ衝突が検出された場合は、新しいソルトを選択して署名処理を再実行 しなければならない。 7.2. ゾーンの提供 本仕様は、権威サーバが生成するDNSSEC対応のDNS応答を変更する。特に、 DNSSEC対応応答におけるNSEC RRの使用をNSEC3 RRで置き換える。 Laurie, et al. Standards Track [Page 17] RFC 5155 NSEC3 March 2008 以下の応答例では、DNSSEC[RFC4035]で規定されたNSEC RRは等価な証明を 行うNSEC3 RRに置き換えられている。NSEC RRを含まない応答については、 本仕様による変更はない。 NSEC3 RRを複数含んだ応答を返す場合、全てのNSEC3 RRは同じハッシュ アルゴリズム、繰り返し、ソルト値でなければならない(MUST)。フラグ フィールド値は0か1でなければならない(MUST)。 7.2.1. 最近接名の証拠 NSEC3による応答では、多くの場合に最近接名の証拠が必要となる。これは、 QNAMEの先祖名がそのQNAMEの最近接名であることの証拠である。 この証拠は(最大)2つの異なるNSEC3 RRにより構成される。 ・ (証明可能な)最近接名に一致するNSEC3 RR ・ 最近接名の次近接名をカバーしているNSEC3 RR 1つめのNSEC3 RRは、基本的に最近接名の候補を示し、また特定の近接名が実際に 存在していることを証明する。2つめのNSEC3 RRは、最近接名の候補が実際に 最近接であることを証明し、またQNAME(およびQNAMEと最近接名間に存在する あらゆる先祖の名前)が存在していないことを証明する。 以降の記述では、これらのNSEC3 RRをまとめて"最近接名の証拠"と 呼ぶことにする。 例えば、存在しない所有者名"alpha.beta.gamma.example."の最近接名の証拠に より、"gamma.example."が最近接名であると証明する場合を考える。 その場合、この応答には"gamma.example."に一致するNSEC3 RRと、 "beta.gamma.example."(次近接名)をカバーするNSEC3 RRが含まれる。 Opt-Out(セクション6)を使用している場合、実際の最近接名がOpt-Out範囲内の "Insecure"な委任もしくは委任の部分であるために、存在を証明できない ことがある。このような場合は、実際の最近接名を証明するのではなく、 "証明可能な最近接名"を使用する。つまり、最近接の権威名で代用される。 この際、証拠として使用されるNSEC3 RRを"証明可能な最近接名の証拠"と 呼ぶことにする。 Laurie, et al. Standards Track [Page 18] RFC 5155 NSEC3 March 2008 7.2.2. "Name Error(名前エラー)"応答 QNAMEの不在を証明する場合、最近接名の証拠と、最近接名に対する(存在しない) ワイルドカードRRをカバーするNSEC3 RRが応答に含まれなければならない(MUST)。 この(最大)3つのNSEC3 RRは、QNAMEが存在しないことおよびQNAMEに一致する ワイルドカードが存在しないことの両方を証明する。 例えば、"gamma.example."がQNAMEの証明可能な最近接名である場合、 "*.gamma.example."をカバーするNSEC3 RRが応答の権威部(authority section)に含められる。 7.2.3. QTYPEがDSでない場合の"No Data(該当データ無し)"応答 サーバは、QNAMEに一致するNSEC3 RRを含めなければならない(MUST)。 このNSEC3 RRのタイプビットマップフィールドに、そのQTYPEまたは CNAMEのビットが設定されていてはならない(MUST NOT)。 7.2.4. QTYPEがDSである場合の"No Data"応答 QNAMEに一致するNSEC3 RRがある場合、サーバはそれを回答しなければ ならない(MUST)。このNSEC3 RRのタイプビットマップフィールドに、 DSビットおよびCNAMEビットが設定されていてはならない(MUST NOT)。 QNAMEに一致するNSEC3 RRがない場合、サーバはQNAMEの証明可能な 最近接名の証拠を返さなければならない(MUST)。次近接名をカバーする NSEC3 RRは、Opt-Outビットが設定されていなければならない(MUST)。 (定義より、Opt-Outビットが設定されていなければ何かが間違っていることに 注意してもらいたい) サーバがQNAMEのゾーンカットの両側において権威をもつ場合、サーバはゾーン カットの親側から証拠を返さなければならない(MUST)。 7.2.5. "Wildcard No Data(ワイルドカード展開後該当データ無し)"応答 QNAMEに一致するワイルドカードはあるが、該当するQTYPEが存在しない 場合、応答にはQNAMEの最近接名の証拠およびワイルドカードに一致する NSEC3 RRの両方が含まれなければならない(MUST)。この組合わせにより、 QNAMEそのものは存在しないこと、およびQNAMEに一致するワイルドカードは 存在していることの両方が証明される。QNAMEの最近接名はワイルドカード RRの直前の先祖名でなければならない(MUST)ことに注意してもらいたい (この状況に当てはまらない場合、何かが間違っている)。 Laurie, et al. Standards Track [Page 19] RFC 5155 NSEC3 March 2008 7.2.6. "Wildcard Answer(ワイルドカード展開後一致)"応答 QNAMEとQTYPEに一致するワイルドカードが存在する場合、応答の回答部で ワイルドカードRRsetを展開することに加え、ワイルドカードの一致が 有効であることの証拠を返さなければならない。 この証拠は、QNAMEが存在しないこと、およびQNAMEの最近接名がワイルドカードの 直前の先祖と等しい(つまり正確にワイルドカード一致する)ことを証明する ことで達成される。 このためには、ワイルドカードの直前の先祖の次近接名をカバーするNSEC3 RRを 返さなければならない(MUST)。最近接名に一致するNSEC3 RRを返すことは 必須ではない。最近接名の存在は、応答に含まれる展開されたワイルドカードの 存在によって証明されるからである。 7.2.7. 未署名サブゾーンへの参照 委任名に一致するNSEC3 RRが存在する場合、応答にそのNSEC3 RRを 含めなければならない(MUST)。そのNSEC3 RRのタイプビットマップに DSビットが設定されていてはならない(MUST NOT)。 Opt-Outゾーンの場合、委任点に対応するNSEC3 RRは存在しないかもしれない。 この場合、証明可能な最近接名の証拠を応答で返さなければならない(MUST)。 応答に含まれる委任の次近接名をカバーするNSEC3 RRは、Opt-Outフラグが 1に設定されていなければならない(MUST)。(何かが間違っていない限り このようになる)。 7.2.8. NSEC3の所有者名への問合わせに対する応答 他の所有者名と異なり、NSEC3 RRの所有者名は(訳注: ハッシュ化所有者名として 再帰的には)NSEC3 RR連鎖に表記されない。結果として、NSEC3 RRの所有者名は、 そのNSEC3 RRの存在を効力を持って否定する他のNSEC3 RRにカバーされる。 しかし、NSEC3 RRの存在はそれ自体のRRSIG RRsetによって証明されるので、 これはパラドックスである。 次の状況が全て満たされる場合を考える。 ・ QNAMEと実在のNSEC3 RRの所有者名が一致する ・ QNAMEおよびONAMEの子孫に対して、RRタイプが存在しない。 この場合、応答は"Name Error"応答(セクション7.2.2)でなければならない (MUST)。言い換えると、権威ネームサーバはNSEC3 RRの所有者名が存在して いないかのように振る舞う。 Laurie, et al. Standards Track [Page 20] RFC 5155 NSEC3 March 2008 ただし、AXFRやIXFRに対してはNSEC3 RRが返されることに注意してもらいたい。 7.2.9. 問合わせ実行時の衝突に対するサーバ応答 存在しないQNAMEのハッシュが存在するNSEC3 RRの所有者名と衝突した場合、 サーバはQNAMEの不在証明を行う応答を返せない。この場合、サーバはRCODE=2 (server failure)を返さなければならない(MUST)。 本文書で指定するハッシュアルゴリズムであるSHA-1を使用する場合、このような 衝突が発生する可能性は、極めて小さいことに注意してもらいたい。 7.3. セカンダリサーバ セカンダリサーバ(およびNSEC3を処理する他の関連プログラム)は、不在応答に 含まれる複数のNSEC3 RRが属する個々のセットを適切に特定するために、 ハッシュ化所有者名それぞれについて使用されているNSEC3パラメータ (ハッシュ、ソルト、繰り返し)を確実に決定する必要がある。これらの情報は、 ゾーン頂点に存在するNSEC3PARAM RRによって示される。 複数のNSEC3PARAM RRが存在する場合は、有効なNSEC3連鎖も複数存在する。 サーバはそれらのうち1つを選択しなければならないが、選択基準は何でも よい。 7.4. 未知のハッシュアルゴリズムを使用するゾーン 本仕様に基づく署名ゾーンがサーバの知らないNSEC3ハッシュアルゴリズム値を 使用している場合、サーバはゾーン提供を有効に行えない。サーバは、 そのようなゾーンはゾーンのロード段階で拒否すべきである(SHOULD)。 そのようなゾーンに関する問合わせを扱う際には、サーバはRCODE=2 (server failure)を応答すべきである(SHOULD)。 7.5. ダイナミックアップデート NSEC3を使用する署名ゾーンはダイナミックアップデート[RFC2136]を受理し てもよい。しかし、NSEC3はダイナミックアップデートに関して幾つかの特 殊な考慮点を持ち込んでいる。 ゾーンに名前を追加・削除する際には、その名前に関して生じる空の非終端の 生成・削除に対する責任を負わなければならない(MUST)。 ・ ある名前と対応するNSEC3 RRとを共に削除する際には、その名前によって 生成された空の非終端に対応する全てのNSEC3 RRを削除しなければならない (MUST)。特定の空の非終端は、生成された原因となる名前が2つ以上ある場合も あることに注意してもらいたい。 Laurie, et al. Standards Track [Page 21] RFC 5155 NSEC3 March 2008 ・ NSEC3 RRの追加が必要となる名前を追加する場合、その名前追加に付随して 生成される全ての空の非終端に対してもNSEC3 RRを追加しなければならない (MUST)。つまり、空の非終端に一致するNSEC3 RRが存在していない場合、 それを生成し追加しなければならない。 ゾーンにOpt-Outが存在する場合は、名前の追加・委任がゾーン内のNSEC3 RRの 変更を必要としないことがある。 ・ 委任のRRsetを削除する際に、その委任に一致するNSEC3 RRがない場合、 それはOpt-Outされていたものである。この場合、特に行うべきことはない。 ・ 委任のRRsetを追加する際に、その委任の次近接名をカバーするOpt-Out NSEC3 RRが存在している場合、ゾーンのNSEC3 RRを変更せずにその委任を 追加してもよい(MAY)。 ゾーンにOpt-Outが存在するということは、NSEC3 RRを追加・削除する際に、 追加・修正されるNSEC3 RRに設定されるべきOpt-Outフラグ値が曖昧になることを 意味する。この曖昧さを解決するため、サーバは以下の基本ルールセットに 従うべきである(SHOULD)。 これらのルールの中心となる考え方は、カバーするNSEC3 RRのOpt-Outフラグの 状態を保存することである。 ・ NSEC3 RRを削除する際には、直前に位置する(つまりNSEC3 RR削除に伴って 次ハッシュ化所有者名が変更された)NSEC3 RRのOpt-Outフラグ値を 変更すべきではない。 ・ NSEC3 RRを追加する際には、そのNSEC3 RRの所有者名をそれまでカバー していたNSEC3 RRのOpt-Outフラグ値をそのOpt-Outフラグ値として設定する。 つまり、そのNSEC3 RRがこれまで直前のNSEC3 RRが果たしてきた役割を 引き継ぐということである。 NSEC3 RRの追加・削除を行うゾーンが、Opt-Outフラグの使用において 一貫している(つまり、ゾーンの全てのNSEC3 RRが同一のフラグ値を持つ) 場合、これらのルールは一貫性を維持する。ゾーンがフラグの使用において 一貫していない(つまり、部分的なOpt-Outゾーンである)場合、これらの ルールではOpt-Outフラグ使用パターンを同じものとして維持できないだろう。 部分的にオプトアウトフラグを使用するゾーンについて、その使用方法に 論理的パターンがあるならば、サーバにローカルポリシーを適用することに より、そのパターンを維持できるかもしれない。 Laurie, et al. Standards Track [Page 22] RFC 5155 NSEC3 March 2008 8. バリデータに関する考慮点 8.1. 未知のハッシュタイプの応答 バリデータは、未知のハッシュタイプのNSEC3 RRを無視しなければならない (MUST)。この実際的な結果として、そのようなNSEC3 RRのみを含む応答は 一般に"Bogus(検証失敗：信頼禁止)"と見なされるようになる。 8.2. NSEC3 RRの検証 バリデータは、フラグフィールドの値が0または1以外のNSEC3 RRを 無視しなければならない(MUST)。 バリデータは、ゾーンからの応答に含まれる複数のNSEC3 RRのハッシュ アルゴリズム、繰り返し、ソルトのいずれかが互いに異なる値であった場合、 その応答を"Bogus"として処理してよい(MAY)。 8.3. 最近接名の証拠 バリデータは、最近接名の証拠を検証するため、以下の条件を満たす最長の 名前Xを発見しなければならない(MUST)。 ・ Xは応答に含まれるNSEC3 RRに一致するQNAMEの先祖である。これは最近接名の 候補である。 ・ Xより1ラベルだけ長い(しかし依然としてQNAMEの先祖かQNAMEに等しい) 名前が応答に含まれるNSEC3 RRにカバーされる。 この証拠を検証するために可能なアルゴリズムの一例は以下のようになる。 1. SNAME = QNAME とし、フラグをクリアする。 2. SNAMEが存在するか調べる * SNAMEに一致するNSEC3 RR(NSEC3 RRの所有者名がゾーン名の前に SNAMEのハッシュを単一ラベルで付加したものと一致する)が応答内に 存在しなければ、フラグをクリアする。 * SNAMEをカバーするNSEC3 RRが応答内に存在すればフラグを設定する。 * 一致するNSEC3 RRが応答内に存在し、かつフラグが設定されていれば、 証拠は完全であり、SNAMEが最近接名となる。 Laurie, et al. Standards Track [Page 23] RFC 5155 NSEC3 March 2008 * 一致するNSEC3 RRが応答内に存在するが、フラグが設定されていない 場合、応答は"Bogus"である。 3. SNAMEを左1ラベル切り詰めて短くし、ステップ2に戻る 最近接名を発見したならば、バリデータはその最近接名をオリジナル所有者名に 持つNSEC3 RRが正しいゾーンから得たものであることを検査しなければならない (MUST)。DNAMEタイプビットは設定されてはならず、NSタイプビットはSOAタイプ ビットが設定されている時に限り設定されてもよい。この条件にあわない場合、 サーバが権威を持たないRRの存在を不当に否認するために、攻撃者が これらのタイプビットを操作している兆候かもしれない。 以後の記述においては、"Xの(証明可能な)最近接名の証拠"という表現は、 上記のアルゴリズム(または同等のアルゴリズム)により、Xの先祖がXの最近接名で あることが証明され、その結果Xの不在が証明されたことを意味する。 8.4. "Name Error"応答の検証 バリデータは、応答内にQNAMEの最近接名の証拠が含まれていること、 最近接名のワイルドカード名(最近接名の前にアスタリスクラベルを付加した名前) をカバーするNSEC3 RRが含まれていることを検証しなければならない(MUST)。 8.5. "No Data"応答の検証: QTYPEがDSでない場合 バリデータは、QNAMEに一致するNSEC3 RRが存在し、そのタイプビットマップ フィールドにはQTYPEとCNAMEタイプのいずれも設定されていないことを 検証しなければならない(MUST)。 この検証は、NSEC3 RRが空の非終端に対して存在する場合も行うことに注意して もらいたい。その場合、NSEC3 RRは空のタイプビットマップフィールドを持つ。 8.6. "No Data"応答の検証: QTYPEがDSの場合 応答内にQNAMEに一致するNSEC3 RRが存在する場合、そのNSEC3 RRのタイプ ビットマップフィールドにDS及びCNAMEのビットが設定されていてはならない (MUST NOT)。 そのようなNSEC3 RRが存在しない場合、バリデータは、QNAMEの証明可能な 最近接名の証拠が応答に含まれていること、次近接名をカバーするNSEC3 RRに Opt-Outビットが設定されていることを検証しなければならない(MUST)。 Laurie, et al. Standards Track [Page 24] RFC 5155 NSEC3 March 2008 8.7. "Wildcard No Data"応答の検証 バリデータは、QNAMEの最近接名の証拠を検証しなければならず(MUST)、 また最近接名の前にアスタリスクラベルを付加したワイルドカード名に 一致するNSEC3 RRが応答に含まれることを確認しなければならない(MUST)。 更に、ワイルドカード一致したNSEC3 RRのQTYPEとCNAMEの双方に対応する ビットが設定されていてはならない(MUST NOT)。 8.8. "Wildcard Answer"応答の検証 応答に含まれる"Wildcard Answer"に関する検証済みRRsetは、QNAMEの最近接名 (の候補)をバリデータに提供する。この最近接名は、生成されたワイルドカードの 直前の先祖である。 バリデータは、応答内にQNAMEの次近接名をカバーするNSEC3 RRが存在することを 検証しなければならない(MUST)。これにより、QNAMEそのものは存在しないこと、 正しいワイルドカードを使用して応答が生成されたことが証明される。 8.9. 未署名サブゾーンへの参照の検証 ゾーン参照の委任名は、ゾーン参照応答の権威部に存在するNS RRsetの 所有者名である。 委任名に一致するNSEC3 RRが応答内に存在する場合、バリデータは、 NSEC3 RRのタイプビットマップフィールドにNSビットは設定されているが、 DSビットは設定されていないことを確認しなければならない(MUST)。また、 バリデータは、NSEC3 RRが正しい(つまり親)ゾーンからのものである ことを確認しなければならない(MUST)。これは、このNSEC3 RRのタイプ ビットマップフィールドにSOAビットが設定されていないことを確かめればよい。 NSビットの存在はDNAMEビットの不在を意味するので、NSEC3 RRのタイプ ビットマップにDNAMEビットが存在するか検査する必要はないことに注意して もらいたい。 委任名に一致するNSEC3 RRが存在しない場合、バリデータは、その委任名の 証明可能な最近接名の証拠を検証しなければならない(MUST)。バリデータは、 その委任名の次近接名をカバーするNSEC3 RRのOpt-Outビットが設定されている ことを検証しなければならない(MUST)。 Laurie, et al. Standards Track [Page 25] RFC 5155 NSEC3 March 2008 9. リゾルバに関する考慮点 9.1. NSEC3リソースレコードのキャッシュ キャッシングリゾルバは、NSEC3 RRを含む応答を返す際には、適切なNSEC3 RRを 検索できなければならない(MUST)。DNSSEC[RFC4035]では多くの場合、応答で 返される適切なNSEC RRを名前から探索できる(例えば、ゾーン参照を返す場合、 NSEC RRは常に委任名と同じ所有者名を持つ)。本仕様では上記のようにはできず、 またキャッシングリゾルバが適切なNSEC3 RRの名前を計算することもできない。 NSEC3 RRのキャッシュと検索の実装では新しい方法を使用する必要があるだろう。 9.2. ADビットの使用 返される応答に(証明可能な)最近接名の証拠が含まれており、その中に 次近接名をカバーし、Opt-Outビットが設定されているNSEC3 RRが存在する場合、 [RFC4035]により定義されるADビットを設定してはならない(MUST NOT)。 この規則は、応答に含まれる最近接名の証拠が実際に何を証明しているかに 基づいている。Opt-Out NSEC3 RRがカバーする名前は、存在しているならば "Insecure"な委任であるが、存在しているともしていないとも証明されない。 したがって、この最近接名の証拠を含む応答内に存在する全データを暗号論的に 検証することはできない。よってADビットを設定してはならない。 10. 特別な考慮点 10.1. ドメイン名長の制約 本仕様に基づく署名ゾーンには、新たにドメイン名長に関する制約が課される。 特に、ハッシュ化所有者名に変換した際に[RFC1035]で規定される255オクテットを 超える名前を持つゾーンは、本仕様を利用できない。 個々のゾーンにおける実際の最大ドメイン名長は、(全体のドメイン名に 対する)ゾーン名の長さと使用する特定のハッシュ関数の双方に依存する。 例として、160ビットのハッシュを生成するSHA-1を考える。160ビットを Base32でエンコードすると32文字となる。この32文字が単一ラベルとして ゾーン名の前に付加されるが、ゾーン名は1オクテットの長さフィールドを 含んでいる。よって、SHA-1を使用する場合の最長のゾーン名長は222(255-33) オクテットである。 Laurie, et al. Standards Track [Page 26] RFC 5155 NSEC3 March 2008 10.2. ゾーン頂点のDNAME [RFC2672]のセクション3のDNAME仕様には"子孫不在"の制約がある。 ノードNにDNAMEが存在する場合、Nのいずれの子孫にもデータが存在しては ならない(MUST NOT)。 しかし、Nがゾーン頂点ならば、NSEC3とRRSIGタイプがNの子孫として存在 することになる。本仕様はDNAME仕様を更新し、ゾーン頂点にDNAMEが存在 するかによらず、ゾーン頂点の子孫としてNSEC3とRRSIGタイプの存在を許容 できるものとする。 10.3. 繰り返し ゾーン管理者は、使用する繰り返し回数を設定することにより、ハッシュの計算 コスト、つまり辞書生成のコストを制御できる。これはソルトの効果とは異なる ことに注意してもらいたい。ソルトは、予め計算された単一の辞書がいつでも 使用できてしまうことを防止するものである。 繰り返しの回数は、バリデータがゾーンからの応答を検証するコストだけでなく、 ゾーン管理者がゾーンに署名するコスト・ゾーンを提供するコストにも影響を 与えることは明らかである。したがって、繰り返し回数に上限を課すことにする。 この際の基準として、RRsetの検証コストに近似的となる繰り返し回数を設定する。 したがって、この上限は、表中の最も近い値に切り上げた際の(鍵が表の最大値 より大きい場合は切り下げた際の)最小のゾーン署名鍵長に基づく。 ゾーン管理者は、それぞれの鍵長に対して以下の表に示されるより大きな 繰り返し回数を使用してはならない(MUST NOT)。リゾルバは、バリデータが NSEC3 RRの署名が正しいことを検証した後、以下の表の値よりも大きな値を持つ 応答を"Insecure"と見なしてもよい(MAY)。 +----------+------------+ | 鍵長 |繰り返し回数| +----------+------------+ | 1024 | 150 | | 2048 | 500 | | 4096 | 2,500 | +----------+------------+ この表は、SHA-1の計算コストとRSA署名検証コストの比は、1024ビット鍵の 場合 1:150、2048ビット鍵の場合 1:500、4096ビット鍵の場合 1:2500という 見積りに基づくものである。 Laurie, et al. Standards Track [Page 27] RFC 5155 NSEC3 March 2008 SHA-1の計算コストとDSA署名検証コストの比は更に大きくなる(1024ビット 鍵の場合 1:1500)。繰り返し回数を増やせばパフォーマンスが悪くなるが、 同じ鍵サイズで比較した場合でも、DSA署名検証はRSA署名検証よりもコストが 高い。従って、鍵アルゴリズムに関わらず表の値を使用しなければならない (MUST)。 10.4. 署名ゾーンにおけるNSECからNSEC3への移行 既に信頼されている署名ゾーンを本仕様に移行する際には、移行中に クライアントの検証が失敗しないように注意しなければならない。 基本的な手順は以下の通りである。 1. 全てのDNSKEYを、セクション2で定義される別名アルゴリズムを使用する DNSKEYに移行する。安全かつ確実にゾーンのDNSKEY RRsetを変更する 実際的な方法については本仕様の対象範囲外であるが、最終的には 親ゾーンの全てのDS RRが指定された別名アルゴリズムを使用している 状態にしなければならない(MUST)。 この移行が完了した後は、全てのNSEC3非対応クライアントがこのゾーンを "Insecure"と見なすだろう。ただしこの時点では、権威サーバは依然として NSEC RRを含む不在応答・ワイルドカード応答を返している。 2. 徐々にまたは一度に、署名されたNSEC3 RRの全てをゾーンに追加する。 徐々に追加する場合、最後に追加するRRsetはNSEC3PARAM RRset でなければならない(MUST)。 3. NSEC3PARAM RRsetを追加した後、本仕様に従い、NSEC3 RRを 使用した不在応答・ワイルドカード応答を返すようサーバを切り替える。 4. 徐々にまたは一度に、NSEC RRを削除する。 10.5. 署名ゾーンにおけるNSEC3からNSECへの移行 DNSSEC[RFC4035]の署名ゾーンに安全に切り戻すためには、単に上記手順の逆を 行えばよい。 1. 徐々にまたは一度に、NSEC RRを追加する。 2. NSEC3PARAM RRsetを削除する。これにより、サーバは不在応答・ワイルド カード応答にNSEC RRを使用するようになる。 3. 徐々にまたは一度に、NSEC3 RRを削除する。 Laurie, et al. Standards Track [Page 28] RFC 5155 NSEC3 March 2008 4. 全てのDNSKEYをDNSSECのアルゴリズムIDに移行する。この移行が完了 した後は、全てのNSEC3非対応クライアントがこのゾーンを"Secure"と 見なすだろう。 11. IANAに関する考慮点 NSEC3・NSEC3PARAM RRのフォーマットはハッシュアルゴリズムのパラメータを 含むが、本文書では、NSEC3が使用中のハッシュアルゴリズムを別のものに 安全に移行する方式については特に定義しない。NSEC3に新しいハッシュ アルゴリズムを指定する場合、移行方式についても定義しなければならない (MUST)。 本文書は、2つの新タイプを定義し、IANAレジストリの"TYPES"サブレジストリ における"DOMAIN NAME SYSTEM PARAMETERS" (http://www.iana.org/assignments/dns-parameters)を更新する。 セクション3においてNSEC3 RRのタイプを50と定義している。 セクション4においてNSEC3PARAM RRのタイプを51と定義している。 本文書は、IANAレジストリの"DNS SECURITY ALGORITHM NUMBERS -- per [RFC4035]"(http://www.iana.org/assignments/dns-sec-alg-numbers) を更新する。セクション2において、既存のレジストリ情報であるDSAとRSASHA1を NSEC3のハッシュアルゴリズムSHA1と組み合わせたものを、それぞれ DSA-NSEC3-SHA1(6)、RSASHA1-NSEC3-SHA1(7)という別名で定義している。 これらのアルゴリズム番号は既存のDNSKEYアルゴリズム番号の別名なので、 オリジナルアルゴリズムで定義されているフラグは別名のアルゴリズムにおいても 有効である。 本文書はNSEC3のフラグに関する新しいIANAレジストリを生成する。 レジストリの名前は"DNSSEC NSEC3 Flags"である。このレジストリの 開始時点での内容は以下の通りである。 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | | | | | | | |Opt| | | | | | | | |Out| +---+---+---+---+---+---+---+---+ ビット7はOpt-Outフラグである。 ビット0から6は今後割り当てを行うことができる。 このレジストリに対して追加のNSEC3フラグを割り当てるには、IETF標準化活動 [RFC2434]が必要である。 本文書はNSEC3PARAMのフラグに関する新しいIANAレジストリを生成する。 レジストリの名前は"DNSSEC NSEC3PARAM Flags"である。このレジストリの 開始時点での内容は以下の通りである。 Laurie, et al. Standards Track [Page 29] RFC 5155 NSEC3 March 2008 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | | | | | | | | 0 | +---+---+---+---+---+---+---+---+ ビット7は予約済みであり、0でなければならない。 ビット0から6は今後割り当てを行うことができる。 このレジストリに対して追加のNSEC3PARAMフラグを割り当てるには、 IETF標準化活動[RFC2434]が必要である。 最後に、本文書はNSEC3のハッシュアルゴリズムに関する新しいIANAレジストリを 生成する。レジストリの名前は"DNSSEC NSEC3 Hash Algorithms"である。 このレジストリの開始時点での内容は以下の通りである。 0 予約済み 1 SHA-1 2-255 今後割り当てを行うことができる。 このレジストリに対して追加のNSEC3ハッシュアルゴリズムを割り当てるには、 IETF標準化活動[RFC2434]が必要である。 12. セキュリティに関する考慮点 12.1. ハッシュに関する考慮点 12.1.1. 辞書攻撃 NSEC3 RRは辞書攻撃には依然として脆弱である(つまり、攻撃者は全ての NSEC3 RRを収集し、ドメイン名である可能性のある文字列全てについて ハッシュ値を計算し、NSEC3 RRから得たハッシュ値と比較する。これを 繰り返せば、ゾーンを列挙することができる)。しかし、元のNSEC RRを 使用する場合に比べて遥かに列挙コストがかかるし、またどのような場合であれ 辞書攻撃は、直接ネームサーバに対して可能性のある文字列全てについて問合わせ を行うため、明らかに検出は容易である。NSEC3 RRにおける繰り返し回数を設定 することにより、このオフライン攻撃にかかるコストを制御することができる。 ゾーンもまた、予め計算された辞書攻撃(可能性のある文字列のハッシュを 計算してリストにまとめておき、NSEC3 RRを定期的に読み取って、事前に計算 しておいたハッシュリストと比較する)に対して脆弱である。この攻撃は、 ソルト変更を定常化することにより防ぐことができる。 Laurie, et al. Standards Track [Page 30] RFC 5155 NSEC3 March 2008 ソルトは少なくとも64ビットの長さを持ち、予測不能なものにすべきである (SHOULD)。そのようにすることで、ゾーンが公開される前に攻撃者が ソルトの値を推測したり、次の辞書セットを計算したりできなくなる。 12.1.2. ハッシュの衝突 QNAMEとNSEC3 RRの所有者名との間でハッシュの衝突が起こることがある。 その場合、衝突したQNAMEの不在証明は不可能である。しかし、SHA-1を使用する 状況では、衝突の発生はほぼあり得なくなる(2の160乗分の1のオーダである)。 DNSSECは既に暗号ハッシュ関数が第二原像計算困難性(second pre-image resistant)を持つという前提に依存していることに注意してもらいたい。 なぜなら、署名の生成・検証やDS RRにおいてもこれらのハッシュ関数を 使用しているからである。 12.1.3. 新しいハッシュアルゴリズムへの移行 NSEC3・NSEC3PARAM RRのフォーマットはハッシュアルゴリズムのパラメータを 含むが、本文書では、NSEC3が使用中のハッシュアルゴリズムを別のものに 安全に移行する方式については特に定義しない。NSEC3に新しいハッシュ アルゴリズムを指定する場合には、移行方式についても定義しなければならない (MUST)。現実に受け容れられそうで、かつ実際に機能しそうな移行方式は、 "Insecure"な状態か、NSEC3の代わりにNSECレコードを使用する状態を移行中に 必要とするかもしれない。 12.1.4. 大きな繰り返し値の使用 バリデータは、大きな繰り返し値を持つNSEC3 RRを含む応答を "Insecure"と 見なすべきであるから、大きな繰り返し値を持つ署名されたNSEC3 RRが ゾーンに1つでも存在すれば、攻撃者にダウングレード攻撃の可能性を与える ことになる。 この攻撃は、応答から単純に既存のNSEC3 RRのいずれかを削除し、大きな 繰り返し値を持つ1つ(または複数)のNSEC3 RRの置換・追加をするだけである。 攻撃後、バリデータは応答を"Insecure"と見なさざるを得なくなる。 この攻撃は、以下の条件が全て満たされた場合にのみ有効となる。 ・ ゾーンに大きな繰り返し値を持つ署名されたNSEC3 RRが少なくとも1つ 存在する ・ 攻撃者が1つ以上のこれらのNSEC3 RRにアクセスできている。通常の応答で 大きな繰り返し値を持つNSEC3 RRが返される場合は、明らかにこの条件が 満たされているが、これ以外にも攻撃者がAXFR・IXFR問合わせや他の手段を 経てゾーンにアクセスできる場合も条件が満たされていると考えられる。 Laurie, et al. Standards Track [Page 31] RFC 5155 NSEC3 March 2008 大きな繰り返し値を使用することにより、サーバがサービス不能攻撃を受ける 機会が新たに増加する。なぜなら、サーバは不在応答やワイルドカード応答毎に 複数回ハッシュを計算しなければならないからである。 12.2. オプトアウトに関する考慮点 Opt-Outフラグ(O)により、署名ゾーン内に未署名の名前を未署名ゾーンへの委任 という形で存在させることができるようになる。定義により、未署名の名前は 全て"Insecure"なので、それらの名前が有効であるかどうか、またはそれらの 名前が存在するかどうかを暗号論的に証明することはできない。 一般に、 ・ (存在するか否かによらず)未署名の名前を持つリソースレコードは、 未署名ゾーンのRRと同じ脆弱性を持つ。これらの脆弱性については [RFC3833]に詳細が記述されている(特にセクション2.3"名前の連鎖"、 セクション2.6"ドメイン名の認証された否認"に注意してもらいたい)。 ・ 署名された名前を持つリソースレコードは、Opt-Outの有無によらず、 同一のセキュリティを持つ。 "Insecure"な委任は、Opt-Outの有無によらず、攻撃を検知できないまま 攻撃者により改ざんされ得ることに注意してもらいたい。以上より、 Opt-Outを使用した結果生じるセキュリティの主要な変化は、Opt-Out NSEC3 RRの 範囲に"Insecure"な委任が存在するかどうかを証明できなくなることである。 具体的には、悪意を持った存在が、未署名の名前を持つRRを追加したり 削除したりすることが可能であることを意味する。この種のRRは大抵 NS RRだが、署名されたワイルドカードの展開にも当てはまる(ワイルド カードRR自体は署名されていても、展開された名前は未署名となる)。 委任を追加できるということは、機能的には全てのRRタイプを追加できる ことに等しいことに注意してもらいたい。攻撃者は、自分の制御下にある ネームサーバへの委任を偽造するだけで、サブゾーン頂点に必要なRRを 自由に設定することができる。 状況によっては、このことは重大なセキュリティ問題として顕在化しないかも しれないが、一般論としては軽く片付けてしまってはいけない。したがって、 Opt-Outは慎重に使用することが強く推奨される(RECOMMENDED)。 特に、ゾーン署名ツールは、オプトアウトの使用をデフォルトにすべきでないし (SHOULD NOT)、Opt-Outの使用を全く不可にしてもよい(MAY)。 Laurie, et al. Standards Track [Page 32] RFC 5155 NSEC3 March 2008 12.3. その他の考慮点 NSEC3 RRを辿っていくことにより、ゾーン中の全RR(と空の非終端)の数と それぞれのタイプが判明する。これはダミーのエントリーを追加することで 軽減できるものの、その上限値は常に確実に判明する。 13. References 13.1. Normative References [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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, September 2000. [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. [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 the DNS Security Extensions", RFC 4034, March 2005. Laurie, et al. Standards Track [Page 33] RFC 5155 NSEC3 March 2008 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. 13.2. Informative References [DNSEXT-NO] Josefsson, S., "Authenticating Denial of Existence in DNS with Minimum Disclosure", Work in Progress, July 2000. [DNSEXT-NSEC2v2] Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format", Work in Progress, December 2004. [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999. [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000. [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006. [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security (DNSSEC) Opt-In", RFC 4956, July 2007. Laurie, et al. Standards Track [Page 34] RFC 5155 NSEC3 March 2008 付録A. ゾーンの例 NSEC3 RRを含むゾーンを以下に示す。これらはハッシュアルゴリズムの テストベクターとして使用することもできる。 全体のTTLとクラスはSOA RRの中で指定され、以後はわかりやすくするために 省略される。 ゾーン情報の前に、オリジナル所有者名とそのハッシュ化所有者名のリストを 示しておく。 ; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom ; H(a.example) = 35mthgpgcu1qg68fab165klnsnk3dpvl ; H(ai.example) = gjeqe526plbf1g8mklp59enfd789njgi ; H(ns1.example) = 2t7b4g4vsa5smi47k61mv5bv1a22bojr ; H(ns2.example) = q04jkcevqvmu85r014c7dkba38o0ji5r ; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h ; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en ; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995 ; H(y.w.example) = ji6neoaepv8b5o6k4ev33abha8ht9fgc ; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s ; H(xx.example) = t644ebqk9bibcna874givr6joj62mlhv ; H(2t7b4g4vsa5smi47k61mv5bv1a22bojr.example) ; = kohar7mbb8dc2ce8a9qvl8hon4k53uhi example. 3600 IN SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) RRSIG SOA 7 1 3600 20150420235959 20051021000000 ( 40430 example. Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd VI2LmKusbZsT0Q== ) NS ns1.example. NS ns2.example. RRSIG NS 7 1 3600 20150420235959 20051021000000 ( 40430 example. PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv CnMXjtz6SyObxA== ) MX 1 xx.example. RRSIG MX 7 1 3600 20150420235959 20051021000000 ( 40430 example. GgQ1A9xs47k42VPvpL/a1BWUz/6XsnHkjotw 9So8MQtZtl2wJBsnOQsaoHrRCrRbyriEl/GZ n9Mto/Kx+wBo+w== ) DNSKEY 256 3 7 AwEAAaetidLzsKWUt4swWR8yu0wPHPiUi8LU ( sAD0QPWU+wzt89epO6tHzkMBVDkC7qphQO2h TY4hHn9npWFRw5BYubE= ) Laurie, et al. Standards Track [Page 35] RFC 5155 NSEC3 March 2008 DNSKEY 257 3 7 AwEAAcUlFV1vhmqx6NSOUOq2R/dsR7Xm3upJ ( j7IommWSpJABVfW8Q0rOvXdM6kzt+TAu92L9 AbsUdblMFin8CVF3n4s= ) RRSIG DNSKEY 7 1 3600 20150420235959 ( 20051021000000 12708 example. AuU4juU9RaxescSmStrQks3Gh9FblGBlVU31 uzMZ/U/FpsUb8aC6QZS+sTsJXnLnz7flGOsm MGQZf3bH+QsCtg== ) NSEC3PARAM 1 0 12 aabbccdd RRSIG NSEC3PARAM 7 1 3600 20150420235959 ( 20051021000000 40430 example. C1Gl8tPZNtnjlrYWDeeUV/sGLCyy/IHie2re rN05XSA3Pq0U3+4VvGWYWdUMfflOdxqnXHwJ TLQsjlkynhG6Cg== ) 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762 BOCXJZMnpuwhpA== ) 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127 RRSIG A 7 2 3600 20150420235959 20051021000000 ( 40430 example. h6c++bzhRuWWt2bykN6mjaTNBcXNq5UuL5Ed K+iDP4eY8I0kSiKaCjg3tC1SQkeloMeub2GW k8p6xHMPZumXlw== ) NSEC3 1 1 12 aabbccdd ( 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN 4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq NI6mRk/r1dOSUw== ) 2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd ( 35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. KL1V2oFYghNV0Hm7Tf2vpJjM6l+0g1JCcVYG VfI0lKrhPmTsOA96cLEACgo1x8I7kApJX+ob TuktZ+sdsZPY1w== ) 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) Laurie, et al. Standards Track [Page 36] RFC 5155 NSEC3 March 2008 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ XtAIR3chwgW+SA== ) a.example. NS ns1.a.example. NS ns2.a.example. DS 58470 5 1 ( 3079F1593EBAD6DC121E202A8B766A6A4837206C ) RRSIG DS 7 2 3600 20150420235959 20051021000000 ( 40430 example. XacFcQVHLVzdoc45EJhN616zQ4mEXtE8FzUh M2KWjfy1VfRKD9r1MeVGwwoukOKgJxBPFsWo o722vZ4UZ2dIdA== ) ns1.a.example. A 192.0.2.5 ns2.a.example. A 192.0.2.6 ai.example. A 192.0.2.9 RRSIG A 7 2 3600 20150420235959 20051021000000 ( 40430 example. hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+ rznEn8sQ64UdqA== ) HINFO "KLH-10" "ITS" RRSIG HINFO 7 2 3600 20150420235959 20051021000000 ( 40430 example. Yi42uOq43eyO6qXHNvwwfFnIustWgV5urFcx enkLvs6pKRh00VBjODmf3Z4nMO7IOl6nHSQ1 v0wLHpEZG7Xj2w== ) AAAA 2001:db8:0:0:0:0:f00:baa9 RRSIG AAAA 7 2 3600 20150420235959 20051021000000 ( 40430 example. LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG cHueLuXkMjBArQ== ) b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd ( gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh 5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3 pOv0TSTyiTxIZg== ) c.example. NS ns1.c.example. NS ns2.c.example. ns1.c.example. A 192.0.2.7 ns2.c.example. A 192.0.2.8 gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd ( ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA RRSIG ) Laurie, et al. Standards Track [Page 37] RFC 5155 NSEC3 March 2008 RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. IVnezTJ9iqblFF97vPSmfXZ5Zozngx3KX3by LTZC4QBH2dFWhf6scrGFZB980AfCxoD9qbbK Dy+rdGIeRSVNyw== ) ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd ( k8udemvp1j2f7eg6jebps17vp3n8i58h ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7 2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0 MpzVSKfTwx4uYA== ) k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd ( kohar7mbb8dc2ce8a9qvl8hon4k53uhi ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt Otx7w9WfcIg62A== ) kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd ( q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. VrDXs2uVW21N08SyQIz88zml+y4ZCInTwgDr 6zz43yAg+LFERjOrj3Ojct51ac7Dp4eZbf9F QJazmASFKGxGXg== ) ns1.example. A 192.0.2.1 RRSIG A 7 2 3600 20150420235959 20051021000000 ( 40430 example. bu6kx73n6XEunoVGuRfAgY7EF/AJqHy7hj0j kiqJjB0dOrx3wuz9SaBeGfqWIdn/uta3SavN 4FRvZR9SCFHF5Q== ) ns2.example. A 192.0.2.2 RRSIG A 7 2 3600 20150420235959 20051021000000 ( 40430 example. ktQ3TqE0CfRfki0Rb/Ip5BM0VnxelbuejCC4 zpLbFKA/7eD7UNAwxMgxJPtbdST+syjYSJaj 4IHfeX6n8vfoGA== ) q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3 ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN NlkxWcLsIlMmUg== ) Laurie, et al. Standards Track [Page 38] RFC 5155 NSEC3 March 2008 r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd ( t644ebqk9bibcna874givr6joj62mlhv MX RRSIG ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+ HF1FWKW7RIJdtQ== ) t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd ( 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA RRSIG ) RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 ( 40430 example. RAjGECB8P7O+F4Pa4Dx3tC0M+Z3KmlLKImca fb9XWwx+NWUNz7NBEDBQHivIyKPVDkChcePI X1xPl1ATNa+8Dw== ) *.w.example. MX 1 ai.example. RRSIG MX 7 2 3600 20150420235959 20051021000000 ( 40430 example. CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb 9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM ivEBP6+4KS3ldA== ) x.w.example. MX 1 xx.example. RRSIG MX 7 3 3600 20150420235959 20051021000000 ( 40430 example. IrK3tq/tHFIBF0scHiE/1IwMAvckS/55hAVv QyxTFbkAdDloP3NbZzu+yoSsr3b3OX6qbBpY 7WCtwwekLKRAwQ== ) x.y.w.example. MX 1 xx.example. RRSIG MX 7 4 3600 20150420235959 20051021000000 ( 40430 example. MqSt5HqJIN8+SLlzTOImrh5h9Xa6gDvAW/Gn nbdPc6Z7nXvCpLPJj/5lCwx3VuzVOjkbvXze 8/8Ccl2Zn2hbug== ) xx.example. A 192.0.2.10 RRSIG A 7 2 3600 20150420235959 20051021000000 ( 40430 example. T35hBWEZ017VC5u2c4OriKyVn/pu+fVK4AlX YOxJ6iQylfV2HQIKjv6b7DzINB3aF/wjJqgX pQvhq+Ac6+ZiFg== ) HINFO "KLH-10" "TOPS-20" RRSIG HINFO 7 2 3600 20150420235959 20051021000000 ( 40430 example. KimG+rDd+7VA1zRsu0ITNAQUTRlpnsmqWrih FRnU+bRa93v2e5oFNFYCs3Rqgv62K93N7AhW 6Jfqj/8NzWjvKg== ) AAAA 2001:db8:0:0:0:0:f00:baaa Laurie, et al. Standards Track [Page 39] RFC 5155 NSEC3 March 2008 RRSIG AAAA 7 2 3600 20150420235959 20051021000000 ( 40430 example. IXBcXORITNwd8h3gNwyxtYFvAupS/CYWufVe uBUX0O25ivBCULjZjpDxFSxfohb/KA7YRdxE NzYfMItpILl/Xw== ) 付録B. 応答の例 本セクションで示す例は、付録Aの署名ゾーンの例を使用した応答メッセージ である。 B.1. "Name Error"応答 権威を持つ名前のエラー。NSEC3 RRは、その名前が存在しないこと、および 展開すべきワイルドカードRRが存在しないことを証明している。 ;; ヘッダ: QR AA DO RCODE=3 ;; ;; 問合わせ部 a.c.x.w.example. IN A ;; 回答部 ;; (空) ;; 権威部 example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 ( 40430 example. Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd VI2LmKusbZsT0Q== ) ;; 次近接名(c.x.w.example)をカバーするNSEC3 RR ;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG ) 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762 BOCXJZMnpuwhpA== ) Laurie, et al. Standards Track [Page 40] RFC 5155 NSEC3 March 2008 ;; 最近接名(x.w.example)に一致するNSEC3 RR ;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995 b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd ( gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) b4um86eghhds6nea196smvmlo4ors995.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh 5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3 pOv0TSTyiTxIZg== ) ;; 最近接名のワイルドカード名(*.x.w.example)をカバーするNSEC3 RR ;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) 35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ XtAIR3chwgW+SA== ) ;; 付加情報部 ;; (空) 問合わせに対し、要求データは存在せず、ワイルドカード展開も適用されなかった ことを証明する3つのNSEC3 RRが返されている。この不在応答は、NSEC3 RRを 検証することで認証される。対応するRRSIGは、このNSEC3 RRがアルゴリズム7、 鍵タグ40430の"example"のDNSKEYで署名されていることを示している。 リゾルバはこの回答を認証するために、対応するDNSKEY RRを必要とする。 返された3つのNSEC3 RRの所有者名の1つが最近接名に一致している。NSEC3 RRの 1つは、それ以上長く一致する名前がないことを証明している。NSEC3 RRの1つは、 展開すべきワイルドカードRRsetが存在しなかったことを証明している。 セクション8.3のアルゴリズムを適用することにより、最近接名を発見することが できる。 上記の例では、"x.w.example"がハッシュ化され "b4um86eghhds6nea196smvmlo4ors995"となっている。このハッシュはこれが 最近接名であるかもしれないことを示している。"c.x.w.example"と "*.x.w.example"が存在しないことを証明するため、それぞれを "0va5bpr2ou0vk0lbqeeljri88laipsfh" "92pqneegtaue7pjatc3l3qnk738c6v5m" のようにハッシュ化する。最初と最後のNSEC3 RRは、これらのハッシュ化 所有者名が存在しないことを証明している。 Laurie, et al. Standards Track [Page 41] RFC 5155 NSEC3 March 2008 B.2. "No Data"応答 "No Data(該当データ無し)"応答。NSEC3 RRは、名前は存在するが要求RRタイプは 存在しないことを証明している。 ;; ヘッダ: QR AA DO RCODE=0 ;; ;; 問合わせ部 ns1.example. IN MX ;; 回答部 ;; (空) ;; 権威部 example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 ( 40430 example. Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd VI2LmKusbZsT0Q== ) ;; NSEC3 RRはQNAMEに一致しており、MXタイプビットは設定されていない 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd ( 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG ) 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN 4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq NI6mRk/r1dOSUw== ) ;; 付加情報部 ;; (空) 問合わせに対し、要求された名前("ns1.example."をハッシュ化したものが "2t7b4g4vsa5smi47k61mv5bv1a22bojr")は存在するが、要求されたRRタイプは 存在せず(NSEC3 RRのタイプコードリストにタイプMXは存在しない)、またこれは CNAMEでもない(NSEC3 RRのタイプコードリストにタイプCNAMEも存在しない) ことを証明するNSEC3 RRが返されている。 Laurie, et al. Standards Track [Page 42] RFC 5155 NSEC3 March 2008 B.2.1. 空の非終端が原因の"No Data"応答 空の非終端が原因で生じた"No Data"応答。NSEC3 RRは名前は存在するが 要求されたRRタイプは存在しないことを証明している。 ;; ヘッダ: QR AA DO RCODE=0 ;; ;; 問合わせ部 y.w.example. IN A ;; 回答部 ;; (空) ;; 権威部 example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 ( 40430 example. Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd VI2LmKusbZsT0Q== ) ;; NSEC3 RRはQNAMEに一致し、Aタイプビットは設定されていない ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd ( k8udemvp1j2f7eg6jebps17vp3n8i58h ) ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7 2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0 MpzVSKfTwx4uYA== ) ;; 付加情報部 ;; (空) 問合わせに対し、要求された名前("y.w.example."をハッシュ化したものが "ji6neoaepv8b5o6k4ev33abha8ht9fgc")は存在するが、要求されたRRタイプ は存在しないことを証明する(NSEC3 RRのタイプビットマップフィールドに タイプAは存在しない)NSEC3 RRが返されている。NSECを使用した空の非終端 の証明とは異なり、これは"No Data"エラーと同じである。この例は単に 完全な記述を示すためのものである。 Laurie, et al. Standards Track [Page 43] RFC 5155 NSEC3 March 2008 B.3. Opt-Out未署名ゾーンへの参照 NSEC3 RRは、この委任に関して何も署名されていないことを証明している。 未署名委任が存在する証拠は存在しない。 ;; Header: QR DO RCODE=0 ;; ;; 問合わせ部 mc.c.example. IN MX ;; 回答部 ;; (空) ;; 権威部 c.example. NS ns1.c.example. NS ns2.c.example. ;; 次近接名(c.example)をカバーするNSEC3 RR ;; H(c.example) = 4g6p9u5gvfshp30pqecj98b3maqbn1ck 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) 35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ XtAIR3chwgW+SA== ) ;; 最近接名(example)に一致するNSEC3 RR ;; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG ) 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762 BOCXJZMnpuwhpA== ) ;; 付加情報部 ns1.c.example. A 192.0.2.7 ns2.c.example. A 192.0.2.8 Laurie, et al. Standards Track [Page 44] RFC 5155 NSEC3 March 2008 問合わせに対し、未署名の"c.example"ゾーンへの参照が返されている。 応答に含まれる"c.example"の証明可能な最近接名は"example"である。 なぜなら"c.example"のハッシュ("4g6p9u5gvfshp30pqecj98b3maqbn1ck")が 最初のNSEC3 RRにカバーされており、そのNSEC3 RRにOpt-Outビットが 設定されているからである。 B.4. "Wildcard Answer"応答 ワイルドカード展開を含む応答が返された問合わせ。回答部に含まれる RRSIG RRsetのラベル数は、この応答を生成するためにワイルドカードRRset が展開されたことを示している。またNSEC3 RRはゾーン内に次近接名が存在 しないことを証明している。 ;; ヘッダ: QR AA DO RCODE=0 ;; ;; 問合わせ部 a.z.w.example. IN MX ;; 回答部 a.z.w.example. MX 1 ai.example. a.z.w.example. RRSIG MX 7 2 3600 20150420235959 20051021000000 ( 40430 example. CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb 9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM ivEBP6+4KS3ldA== ) ;; 権威部 example. NS ns1.example. example. NS ns2.example. example. RRSIG NS 7 1 3600 20150420235959 20051021000000 ( 40430 example. PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv CnMXjtz6SyObxA== ) ;; 次近接名(z.w.example)をカバーするNSEC3 RR ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03 q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3 ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN NlkxWcLsIlMmUg== ) Laurie, et al. Standards Track [Page 45] RFC 5155 NSEC3 March 2008 ;; 付加情報部 ai.example. A 192.0.2.9 ai.example. RRSIG A 7 2 3600 20150420235959 20051021000000 ( 40430 example. hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+ rznEn8sQ64UdqA== ) ai.example. AAAA 2001:db8:0:0:0:0:f00:baa9 ai.example. RRSIG AAAA 7 2 3600 20150420235959 20051021000000 ( 40430 example. LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG cHueLuXkMjBArQ== ) 問合わせに対し、ワイルドカード展開をして生成された回答が返されている。 従来のDNS応答と同様に、回答部は展開されたワイルドカードRRsetを 含んでいる。名前"a.z.w.example"は4ラベルであるから、RRSIGのラベル フィールド値が2であるということは、回答がワイルドカード展開の結果得られた ことを示している。また、これは"w.example"が存在することも示している ので、NSEC3 RRが最近接名に一致する必要はない。 NSEC3 RRは、問合わせへの回答において、これ以上一致するものは存在しない ことを証明している。 B.5. "Wildcard No Data"応答 ワイルドカードがカバーする名前に対する"No Data"応答。このNSEC3 RRは、 ワイルドカード名に一致する名前は要求されたタイプのRRを持たず、 またゾーン内にこれ以上一致する名前も存在しないことを証明している。 ;; ヘッダ: QR AA DO RCODE=0 ;; ;; 問合わせ部 a.z.w.example. IN AAAA ;; 回答部 ;; (空) ;; 権威部 example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 ( 40430 example. Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd VI2LmKusbZsT0Q== ) Laurie, et al. Standards Track [Page 46] RFC 5155 NSEC3 March 2008 ;; 最近接名(w.example)に一致するNSEC3 RR ;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd ( kohar7mbb8dc2ce8a9qvl8hon4k53uhi ) k8udemvp1j2f7eg6jebps17vp3n8i58h.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt Otx7w9WfcIg62A== ) ;; 次近接名(z.w.example)をカバーするNSEC3 RR ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03 q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3 ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN NlkxWcLsIlMmUg== ) ;; 最近接名のワイルドカード名に一致するNSEC3 RR ;; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd ( t644ebqk9bibcna874givr6joj62mlhv MX RRSIG ) r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. RRSIG NSEC3 7 2 3600 ( 20150420235959 20051021000000 40430 example. aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+ HF1FWKW7RIJdtQ== ) ;; 付加情報部 ;; (空) 問合わせに対し、要求されたデータが存在せず、また適用可能なワイルドカード RRも存在しないことを証明するNSEC3 RRが返されている。 Laurie, et al. Standards Track [Page 47] RFC 5155 NSEC3 March 2008 B.6. 子ゾーンへのDS問合わせに対する"No Data"応答 子ゾーンのネームサーバに誤って送られた、QTYPEがDSである問合わせに対する "No Data"応答。 ;; ヘッダ: QR AA DO RCODE=0 ;; ;; 問合わせ部 example. IN DS ;; 回答部 ;; (空) ;; 権威部 example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 ( 40430 example. Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd VI2LmKusbZsT0Q== ) ;; NSEC3 RRはQNAMEに一致しており、DSタイプビットは設定されていない 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG ) 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 40430 example. OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762 BOCXJZMnpuwhpA== ) ;; 付加情報部 ;; (空) 問合わせに対し、"example"ゾーンの権威サーバから要求に対する回答が 行われたことを示すNSEC3 RRが返されている。NSEC3 RRはSOA RRの存在を示す ことにより、このNSEC3 RRは子のゾーン頂点から得られたものであり、親の ゾーンカットから得られたものではないことを示している。"example"の DS RRsetに対する問合わせは、親サーバ(この場合はルートサーバ)に送信 されるべきである。 付録C. 特別な考慮点 以下の節では、NSEC3固有の振る舞いを明確にし、実装に必要となる特別な 考慮点について説明する。 Laurie, et al. Standards Track [Page 48] RFC 5155 NSEC3 March 2008 C.1. ソルトの使用 ハッシュ化前にオリジナル所有者名にソルトを付加すると、ハッシュ値を 事前生成して辞書を作成するコストが増大する。辞書を事前に計算して作成 するコストはソルトのビット毎に倍加する(各単語とソルト値のあり得る値 全ての組み合わせ数だけ辞書エントリが必要となるため)。 NSEC3 RRでは、最大2040ビット(255オクテット)のソルトが使用できるので、 辞書の事前作成コストは2の2040乗倍まで増加する。これは事実上、ソルトが 変更される度に攻撃者は辞書を再計算しなければならないことを意味する。 ソルトを導入してもそのサイズに関わらずNSEC3 RRを構成するコストには影響 しない。しかし、NSEC3 RRのサイズは増加する。 ゾーンにおいては、同じソルト値を使用した少なくとも1つの完全なNSEC3 RR のセットが存在しなければならない(MUST)。 単一のソルトを使用して、事前にハッシュ値を計算する攻撃を防ぐため、 ソルトは定期的に変更すべきである(SHOULD)。再署名の度毎にソルトを 変更することを推奨する(RECOMMENDED)。 ソルト変更により、リゾルバからは同じゾーンに関して異なるソルト値を持つ RRが見えるようになることに注意してもらいたい。これは問題にはならない。 なぜなら、各RRは独立に処理されるからである(つまり、NSEC3 RRに含まれる ソルトを使用した所有者名のハッシュが複数になるような状況はあり得ない)。 サーバだけが、様々な問合わせに回答するため、同一ソルトによる完全な NSEC3 RRのセットを必要とするのである。 同じゾーン内に異なるソルトを持つNSEC3 RRが存在することは禁止されない。 しかし、権威サーバが一貫して適切なNSEC3 RRを発見できるようにするため、 権威サーバはNSEC3の選択時に単一のパラメータ(アルゴリズム、ソルト、 繰り返し)を使用しなければならない(MUST)。 C.2. ハッシュの衝突 異なるメッセージが同一のハッシュ値を持つとき、ハッシュの衝突が発生した という。nビット長のハッシュの場合、1/2の確率で1つの衝突が発生するために 必要となるドメイン名数の期待値は、約2の(n/2)乗個である(つまり、SHA-1では 2の80乗個となる)。この確率は極度に低いといえるものの、以下の節では、 ハッシュ衝突の回避法とハッシュの衝突を使用した攻撃が発生した場合の 影響評価を取り扱う。 Laurie, et al. Standards Track [Page 49] RFC 5155 NSEC3 March 2008 C.2.1. NSEC3生成におけるハッシュ衝突の回避 NSEC3 RRの生成時には、ハッシュ値はおそらく一意になる。衝突が発生した 場合(ほとんど学術的な意味しかないが)、別のソルトを選択し、全ての ハッシュ値を再生成しなければならない(MUST)。 C.2.2. 第二原像計算困難性に関する要求分析 暗号ハッシュ関数は、第二原像計算困難性を持つ。第二原像計算困難性とは、 あるメッセージと同じハッシュ値を持つ別のメッセージ、つまり任意の 原像Xについて、hash(X) = hash(X')となるような別の原像を発見する ことは、計算量的に実行不可能という意味である。SHA-1において第二原像を 発見するためのワークファクタは、2の160乗のオーダーとなる。 既存のNSEC3 RRを利用して攻撃を仕掛けるには、攻撃者は第二原像を発見 しなければならない。 攻撃者が仮に第二原像を発見するという究極の攻撃を行えると仮定した場合に、 実際に発生する影響は、存在しない特定のQNAME(第二原像)が存在すると主張する (偽陽性の)応答メッセージを生成可能になることである。これにより、 DNSSEC対応リゾルバは存在しない名前を再度問い合わせるか、最初の 問合わせに失敗するかのいずれかとなる。攻撃者は既存の名前に対してこの 攻撃を仕掛けることはできず、攻撃者が選択不可能な、存在しない名前に対して だけ攻撃できることに注意してもらいたい。 Laurie, et al. Standards Track [Page 50] RFC 5155 NSEC3 March 2008 Authors' Addresses Ben Laurie Nominet 17 Perryn Road London W3 7LR England Phone: +44 20 8735 0686 EMail: ben@links.org Geoffrey Sisson Nominet Minerva House Edmund Halley Road Oxford Science Park Oxford OX4 4DQ UNITED KINGDOM Phone: +44 1865 332211 EMail: geoff-s@panix.com Roy Arends Nominet Minerva House Edmund Halley Road Oxford Science Park Oxford OX4 4DQ UNITED KINGDOM Phone: +44 1865 332211 EMail: roy@nominet.org.uk David Blacka VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US Phone: +1 703 948 3200 EMail: davidb@verisign.com Laurie, et al. Standards Track [Page 51] RFC 5155 NSEC3 March 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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. Intellectual Property 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. Laurie, et al. Standards Track [Page 52]