ネットワークワーキンググループ 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セキュリティ拡張(DNSSEC)のためのプロトコル変更 本文書の位置づけ 本文書はインターネットコミュニティのためにインターネット標準化過程に あるプロトコルを規定し、その向上のために議論と提案を求めるものである。 このプロトコルの標準化の状況については"Internet Official Protocol Standards"(STD 1)の最新版を参照のこと。本文書の配布は制限されない。 著作権表示 Copyright (C) The Internet Society (2005). 要旨 本文書はDNSセキュリティ拡張(DNSSEC)について記述する文書群の1つである。 DNSSECは、データの出自の認証機能とデータの完全性保護機能をDNSに追加する ためのリソースレコードとプロトコル変更をまとめたものである。 本文書はDNSSECプロトコルの変更を規定する。本文書は、署名ゾーンの概念と、 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. Secureなゾーンの例 . . . . . . . . . . . . . . . . . . . 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. BADデータのキャッシュ. . . . . . . . . . . . . . . . . . 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.1. Normative References . . . . . . . . . . . . . . . . . . 34 9.2. Informative References . . . . . . . . . . . . . . . . . 35 A. 署名ゾーンの例 . . . . . . . . . . . . . . . . . . . . . . . . 36 B. 応答の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 B.1. 正常な回答 . . . . . . . . . . . . . . . . . . . . . . . 41 B.2. "Name Error"応答 . . . . . . . . . . . . . . . . . . . . 43 B.3. "No Data"応答. . . . . . . . . . . . . . . . . . . . . . 44 B.4. 署名ゾーンへの参照 . . . . . . . . . . . . . . . . . . . 44 B.5. 未署名ゾーンへの参照 . . . . . . . . . . . . . . . . . . 45 B.6. "Wildcard Answer"応答. . . . . . . . . . . . . . . . . . 46 B.7. "Wildcard No Data"応答 . . . . . . . . . . . . . . . . . 47 B.8. 子ゾーンのDSに関する"No Data"応答. . . . . . . . . . . . 48 C. 認証の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 C.1. 回答の認証 . . . . . . . . . . . . . . . . . . . . . . . 49 C.1.1. 例示したDNSKEY RRの認証. . . . . . . . . . . . . 49 C.2. "Name Error"応答の認証 . . . . . . . . . . . . . . . . . 50 C.3. "No Data"応答の認証. . . . . . . . . . . . . . . . . . . 50 C.4. 署名ゾーンへの参照の認証 . . . . . . . . . . . . . . . . 50 C.5. 未署名ゾーンへの参照の認証 . . . . . . . . . . . . . . . 51 C.6. "Wildcard Answer"応答の認証. . . . . . . . . . . . . . . 51 C.7. "Wildcard No Data"応答の認証 . . . . . . . . . . . . . . 51 C.8. 子ゾーンのDSに関する"No Data"応答の認証. . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53 1. はじめに 本文書はDNSセキュリティ拡張(DNSSEC)について記述する文書群の1つである。 DNSSECは、データの出自の認証機能とデータの完全性保護機能をDNSに追加する ためのリソースレコードとプロトコル変更をまとめたものである。 本文書はDNSSECプロトコルの変更を定義する。セクション2で署名ゾーンの 概念を定義し、ゾーン署名の要件を列挙する。セクション3で署名ゾーンを 処理するために必要な権威ネームサーバの振る舞いの変更を規定する。 セクション4でDNSSEC対応リゾルバ機能を持つものの振る舞いを規定する。 最後にセクション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)。 署名鍵(ZSKまたはKSK)を保存するDNSKEY RRは、RDATAフィールドの 署名鍵フラグビットが設定されていなければならない(MUST)([RFC4034]の セクション2.1.1参照)。 他のDNS処理で使用する公開鍵を署名鍵フラグが設定されないDNSKEY RRに 保存してもよい(MAY)が、RRSIGの検証に使用してはならない(MUST NOT)。 ゾーン管理者が署名ゾーンをセキュリティの島以外の形態で使用したい場合、 セキュアエントリーポイント(SEP)の役割を果たすDNSKEY RRをゾーン頂点に 最低1つ持たなければならない(MUST)。すると、このSEPは親ゾーン側にある DS RR([RFC4034]参照)に対応するSecureな委任先として使用できるようになる。 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)。 ゾーン頂点にあるDNSKEY RRsetは、1種類以上の公開鍵アルゴリズムの DNSKEYを保持するが、各RRsetに対して、少なくともその1つを使用して 生成したRRSIGが存在しなければならない(MUST)。 ゾーン頂点にあるDNSKEY RRset自身は、親側の委任点にDS RRsetが 存在する場合、個々のDS RRは複数の暗号アルゴリズムを指定するので、 そのうちの1つを使用して署名されなければならない(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)。 この主な理由は、同じゾーンに署名がある場合と無い場合で名前空間の 一貫性を持たせたいという要望と、DNSSEC非対応再帰ネームサーバで 応答の不整合が生じるリスクを減らしたいという要望のためである。 署名ゾーンにある各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は DS RRが参照するDNSKEY RR(公開鍵)と対の秘密鍵で署名されるべき(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. Secure(検証成功：信頼度高)なゾーンの例 付録Aに小規模な署名ゾーン一式の例を示す。 3. サーバ側処理 本セクションでは、DNSSEC対応ネームサーバ機能を持つものの振る舞いを 規定する。多くの場合、その機能はDNSSEC対応再帰ネームサーバの一部だが、 DNSSEC対応権威ネームサーバも幾つか同じ要件を持つ。 DNSSEC対応再帰ネームサーバ固有の機能についてはセクション3.2で規定する。 またDNSSEC対応権威サーバ固有の機能についてはセクション3.1で規定する。 以下の記述において、[RFC1034]と同様に、用語"SNAME"、"SCLASS"および "STYPE"を使用する。 DNSSEC対応ネームサーバはEDNS0([RFC2671])メッセージサイズ拡張を サポートしなければならない(MUST)。少なくとも1220オクテットのメッセージ サイズをサポートしなければならず(MUST)、4000オクテットのメッセージ サイズをサポートすべき(SHOULD)である。IPv6パケットは発信元ホストだけが フラグメント化できるので、DNSSEC対応ネームサーバはパスMTUが既知でない 場合に、IPv6で転送されるUDPデータグラムが必要に応じて最小のIPv6 MTUで フラグメント化されることを保証する処理手順をふむべき(SHOULD)である。 パケットサイズとフラグメンテーションに関する詳細な検討については [RFC1222]、[RFC2460]および[RFC3226]を参照のこと。 Arends, et al. Standards Track [Page 8] RFC 4035 DNSSEC Protocol Modifications March 2005 DNSSEC対応ネームサーバがEDNS OPT擬似RRを持たない、またはDOビットが クリアされたDNS問合わせを受信した場合、RRSIG、DNSKEYおよびNSEC RRを DNSSEC RRset以外のRRsetのように扱わなければならず(MUST)、以下に規定する 付加的な処理を実行してはならない(MUST NOT)。 DS RRタイプは委任点の親ゾーンにしか存在しないという特殊な性質があるため、 DS RRは常にセクション3.1.4.1で規定する特別な処理を必要とする。 DNSSEC対応ネームサーバが明示的なDNSSEC RRの問合わせを受信し、かつ DNSSEC対応ネームサーバが管理する複数のゾーンにその問合わせRRが存在 する場合(例えば、サーバがゾーンの親側と子側両方で権威を持つ場合に、 委任点の上、下両方に存在するNSECおよびRRSIG RRの問合わせを受けた場合)、 サーバは一貫性をもって振る舞うべきである。 ネームサーバへの問合わせに対して応答が常に一貫しているならば、 ネームサーバは以下のうち1つを返してもよい(MAY)。 ・委任点の上に存在するRRset ・委任点の下に存在するRRset ・委任点の上、下にあるRRset両方 ・回答部を空(レコードなし)にして返す ・それ以外の応答 ・エラー DNSSECはDNSメッセージヘッダ内に2つの新しいビットを割り当てる。 CD(Checking Disabled)ビットとAD(Authentic Data)ビットである。 CDビットはリゾルバが制御する。DNSSEC対応ネームサーバは問合わせの CDビットを対応する応答にコピーしなければならない(MUST)。 ADビットはネームサーバが制御する。DNSSEC対応ネームサーバは 問合わせに含まれるADビットを無視しなければならない(MUST)。 これらのビットに関する振る舞いの詳細については、セクション 3.1.6、3.2.2、3.2.3、4および4.9を参照のこと。 DNSSEC対応ネームサーバが[RFC2672]の規定にしたがってDNAMEからCNAME RRを 合成する場合、合成したCNAME RRに対して署名を生成すべきではない (SHOULD NOT)。 3.1. 権威ネームサーバ DNSSEC対応権威ネームサーバが、自身が管理する署名ゾーンに対する 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 RRsetまたは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付加 DNSSEC対応権威ネームサーバがDOビットの設定された問合わせに応答する場合、 DNSSEC対応リゾルバが応答に含まれるRRsetの認証に使用できるように、 RRSIG RRの送信を試みるべき(SHOULD)である。 ネームサーバは、RRsetとそのRRsetのRRSIGを1つの応答に付加するために あらゆる試みをすべきである(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付加 DNSSEC対応権威ネームサーバが、署名ゾーンの頂点にあるSOAまたはNS RRに 対するDOビットが設定された問合わせに応答する場合、ゾーン頂点にある DNSKEY RRsetを付加情報部に入れて返してもよい(MAY)。 この場合、このDNSKEY RRsetと対応するRRSIG RRは、付加情報部に入れられるべき 他の情報よりも優先度は低い。DNSKEY RRsetと対応するRRSIG RRの付加に 充分な容量が応答メッセージに無い場合、ネームサーバはDNSKEY RRsetを 応答に付加すべきではない(SHOULD NOT)。 DNSKEYとRRSIG RRの付加に充分な容量が無い場合、ネームサーバは両RRを除外 しなければならない(MUST)。また、これらのRRが入らなかったという理由だけで TCビットを設定してはならない(MUST NOT)(セクション3.1.1参照)。 3.1.3. 応答へのNSEC RR付加 DNSSEC対応権威ネームサーバが、自身が管理する署名ゾーンに対する DOビットが設定された問合わせに応答する場合、以下の全ての場合において NSEC RRを付加しなければならない(MUST)。 No Data(該当データ無し): ゾーンはに完全一致するRRsetを 持つが、に完全一致するRRsetは存在しない。 Name Error(名前エラー): ゾーンにはに完全一致するRRsetも ワイルドカード展開により一致するRRsetも存在しない。 Wildcard Answer(ワイルドカード展開後一致): ゾーンにに 完全一致するRRsetは存在しないが、ワイルドカード展開により に一致するRRsetが存在する。 Wildcard No Data(ワイルドカード展開後該当データ無し): ゾーンにはに完全一致するRRsetが存在しない。ワイルド カード展開をするとに一致する1つ以上のRRsetが存在するが、 に一致するRRsetは存在しない。 それぞれの場合について、ゾーン内にに完全一致する RRsetが存在しないこと、また返された応答がゾーン内のデータを正しく 提示していることを証明するため、ネームサーバはNSEC RRを応答に付加する。 Arends, et al. Standards Track [Page 11] RFC 4035 DNSSEC Protocol Modifications March 2005 3.1.3.1. NSEC RRの付加: "No Data"応答の場合 ゾーン内にに一致するRRsetは存在するが、 に一致するRRsetは存在しない場合、ネームサーバは 応答の権威部にに関するNSEC RRと、対応するRRSIG RRを 共に付加しなければならない(MUST)(セクション3.1.1参照)。 容量的にNSEC RRまたは対応するRRSIG RRが付加できない場合、ネームサーバは TCビットを設定しなければならない(MUST)(セクション3.1.1参照)。 問合わせ対象の名前は存在しているので、この問合わせに対してワイルドカード 展開は行われない。また問合わされたRRタイプが存在しないことを証明 するためには単一の署名付きNSEC RRがあれば充分である。 3.1.3.2. NSEC RRの付加: "Name Error"応答の場合 ゾーン内に、に完全一致するRRsetも、ワイルドカード展開により 一致するRRsetも存在しない場合、ネームサーバは以下のNSEC RRと対応する RRSIG RRを権威部に付加しなければならない(MUST)。 ・に完全一致するRRsetが存在しないことを証明するNSEC RR。 ・ワイルドカード展開を行ってもに一致するRRsetが存在しない ことを証明するNSEC RR。 場合によっては単一のNSEC RRが上記2つの内容を証明することもある。 その場合、ネームサーバはNSEC 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の付加: "Wildcard Answer"応答の場合 ゾーン内にに完全一致するRRsetは存在しないが、 ワイルドカード展開によりに一致するRRsetが 存在する場合、ネームサーバは応答の回答部にワイルドカード展開後の 回答と対応するRRSIG RRを付加しなければならず(MUST)、また権威部には ゾーン内ににより良く一致するRRsetが無いことを証明する NSRC 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の付加: "Wildcard No Data"応答の場合 これは先に説明した状況の組み合わせである。すなわち、ゾーンには に完全一致するRRsetが存在しないが、ワイルドカード展開を するとに一致する1つ以上のRRsetが存在する。しかしそれでも STYPEに一致するRRsetは存在しないという場合である。この場合、ネーム サーバは応答の権威部に以下の条件を満たすNSEC RRとそのRRのRRSIG RRを 共に付加しなければならない(MUST)。 ・ワイルドカード展開を行うとに一致するワイルドカード 所有者名は存在するが、STYPEに一致するRRsetは存在しないことを証明する NSEC RR。 ・ゾーン内ににより良く一致するRRsetは存在しないことを 証明するNSEC RR。 場合によっては単一のNSEC RRが上記2つの内容を証明することもある。 その場合、ネームサーバはNSEC RRと対応するRRSIG RRをそれぞれ1つだけ 権威部に付加すべきである(SHOULD)。 NSEC RRとRRSIG RRを応答の権威部に付加する際に、これらの所有者名は ワイルドカード展開されない。 容量的にNSEC RRとRRSIG RRが付加できない場合、ネームサーバはTCビットを 設定しなければならない(MUST)(セクション3.1.1参照)。 3.1.3.5. 適切なNSEC RRの発見 先に説明したように、DNSSEC対応ネームサーバが、特定の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付加 DNSSEC対応権威ネームサーバがDOビットが設定された問合わせに対して 参照を返す場合、NS RRsetに加えてDNSSECデータを付加する。 委任点にDS RRsetが存在する場合、ネームサーバはNS RRsetに加えて、 DS RRsetと対応するRRSIG RRを共に権威部に付加しなければならない(MUST)。 委任点にDS RRsetが存在しない場合、ネームサーバはNS RRsetに加えて、 DS RRsetが存在しないことを証明するNSEC RRと対応するRRSIG RRを共に 返さなければならない(MUST)。ネームサーバはまずNS RRsetを付加し、 その後NSEC RRsetと対応するRRSIG RRを付加しなければならない(MUST)。 DS、NSECおよびRRSIG RRを付加することにより、参照メッセージのサイズが 大きくなるため、幾つかまたは全てのグルーRRが省略されてしまう場合がある。 容量的にDS RRまたはNSEC 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 DNSSEC対応リゾルバが委任点にあるDS RRを検索する場合、親ゾーンに 問合わせを送信する(セクション4.2参照)。しかし、その処理にDNSSEC非対応 リゾルバが関与する場合(例えば、ネットワーク環境のためにDNSSEC対応 リゾルバがDNSSEC非対応再帰ネームサーバを通して問合わせを送信しなければ ならない場合が考えられる)に混乱が生じるのを避けるために、特別な規則が 必要である。本セクションの残りで、この問題を避けるために、DNSSEC対応 ネームサーバがDSの問合わせをどう処理するかを規定する。 DNSSEC対応ネームサーバが特別な処理を必要とするのは、以下の条件が 全て満たされた場合だけである。 ・ネームサーバがゾーンカットにあるDS RRsetの問合わせを受信した。 ・ネームサーバは子ゾーンに対して権威を持つ。 ・ネームサーバは親ゾーンに対して権威を持たない。 ・ネームサーバは再帰検索を行わない。 他の場合は全て、ネームサーバが別の手段でDS RRsetを得られるか、 DNSSEC処理規則以前の段階でDS RRsetが得られないことがわかっているかの どちらかである。したがってネームサーバはDS RRsetか通常の処理規則に 従ったエラー応答を返すことができる。 しかし上記の条件が全て満たされた場合、ネームサーバはSNAMEに対して権威を 持つが、問い合わされたRRsetを提供することができない。この場合、 ネームサーバは子ゾーンの頂点にDS RRsetが存在しないことを示す権威を持つ "No Data"応答を返さなければならない(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ビットは、DNSSEC対応リゾルバとDNSSEC対応再帰ネームサーバ間の やりとりで使用するよう設計された。これらのビットはほとんどの場合、 DNSSEC対応権威ネームサーバが行う問合わせ処理とは関係がない。 DNSSEC対応ネームサーバは、たとえCDビットがクリアされていたとしても 問合わせ処理の際に権威を持つデータの署名検証を行わない。DNSSEC対応 ネームサーバは権威を持つ応答を生成する際にCDビットをクリアすべき(SHOULD) である。 Arends, et al. Standards Track [Page 16] RFC 4035 DNSSEC Protocol Modifications March 2005 応答の回答部および権威部に入れたRRsetが全て信頼できない限り、 DNSSEC対応ネームサーバは応答にADビットを設定してはならない(MUST NOT)。 DNSSEC対応ネームサーバのローカルポリシーは、権威を持つゾーンから得た データを付加的検証無しで信頼してもよい(MAY)。 ただし、ネームサーバが権威を持つゾーンを安全な手段(安全なゾーン転送の 仕組みのような)で入手できない限り、付加的検証無しの信頼をしては ならない(MUST NOT)。また、明示的に設定されていない限り、このような 振る舞いをしてはならない(MUST NOT)。 再帰検索をサポートするDNSSEC対応ネームサーバは、再帰検索を経て得た データを含む応答を生成する際に、セクション3.2で規定するCDビットとADビット に関する規則に従わなければならない(MUST)。 3.2. 再帰ネームサーバ [RFC4033]で規定するように、DNSSEC対応再帰ネームサーバとはDNSSEC対応 ネームサーバとDNSSEC対応リゾルバの両方の役割を担うものである。 したがって本セクションでは、DNSSEC対応再帰ネームサーバのコードの中で DNSSEC対応ネームサーバ機能を実装した部分を"ネームサーバサイド"、 DNSSEC対応リゾルバ機能を実装した部分を"リゾルバサイド"と呼ぶことにする。 リゾルバサイドは、DNSSEC対応リゾルバに適用される通常のキャッシュ処理、 ネガティブキャッシュ処理に関する規則に従う。 3.2.1. DOビット DNSSEC対応再帰ネームサーバのリゾルバサイドは、ネームサーバサイドが はじめに受信した再帰問合わせ要求にDOビットが設定されているかに関わらず、 問合わせ送信時にはDOビットを設定しなければならない(MUST)。 再帰問合わせにDOビットが設定されていない場合、ネームサーバサイドは 応答に含まれる全ての認証用DNSSEC RRを取り除かなければならない(MUST)。 しかし再帰問合わせで明示的に要求されたDNSSEC RRタイプを取り除いては ならない(MUST NOT)。 3.2.2. CDビット CDビットを使用することにより、DNSSEC対応リゾルバはDNSSEC対応ネーム サーバへの特定の問合わせで署名検証を無効にさせることができる。 ネームサーバサイドは問合わせに対応する応答にCDビットの設定をコピー しなければならない(MUST)。 Arends, et al. Standards Track [Page 17] RFC 4035 DNSSEC Protocol Modifications March 2005 DNSSEC対応再帰ネームサーバのネームサーバサイドは、はじめに受信した 再帰問合わせの処理経過と共に、CDビットの状態をリゾルバサイドに 渡さなければならない(MUST)。これにより、リゾルバサイドはネームサーバ サイドに返された応答データの検証が必要であるかがわかる。 CDビットが設定されている場合、再帰問合わせを生成したリゾルバが ローカルポリシーが要求する認証を実行することを意味する。 したがって、再帰ネームサーバのリゾルバサイドで応答に含まれるRRsetの 認証を実行する必要はない。 CDビットが設定されている場合、再帰ネームサーバのローカルな認証ポリシーが 再帰問合わせを生成したリゾルバが要求するレコードの提供を拒否していると しても、可能ならばそのデータを返すべき(SHOULD)である。すなわち、CDビットを 設定することにより、きっかけとなる問合わせを生成したリゾルバは自分自身で 認証を実行する責任を負うため、再帰ネームサーバは干渉すべきでないことを 明示するのである。 リゾルバサイドがBADキャッシュ(検証失敗キャッシュ)(セクション4.7)を実装 している状況で、ネームサーバサイドがリゾルバサイドのBADキャッシュに 一致する問合わせを受信した場合、ネームサーバサイドの応答は問合わせの CDビットの設定状況に依存する。 CDビットが設定されている場合、ネームサーバサイドはBADキャッシュから データを返すべき(SHOULD)である。CDビットが設定されていない場合、 ネームサーバサイドはRCODE 2(server failure)を返さなければならない(MUST)。 上記の規則の意図は、自分で署名検証を実行できるクライアントには 生データ(raw data)を提供し、一方でDNSSEC対応再帰ネームサーバの リゾルバサイドに署名検証を依存するクライアントは保護することにある。 署名検証が失敗する原因は様々な条件によるが、署名検証を行う 再帰ネームサーバとクライアントで、その条件が異なる場合がある。 例えば、再帰ネームサーバの時計が正確に設定されていなかったり、 再帰ネームサーバが持たない適切なセキュリティの島に関する情報を クライアントが持っていることがあり得る。 このような場合、自ら署名検証を行えるクライアントを"不良"データから "保護"することはクライアントの助けにはならない。 3.2.3. ADビット DNSSEC対応再帰ネームサーバのネームサーバサイドは、応答の回答部および 権威部に入れた全ての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. リゾルバ側処理 本セクションではDNSSEC対応リゾルバ機能を持つものの振る舞いを規定する。 多くの場合、この機能はDNSSEC対応再帰ネームサーバの一部であるが、 単独で動作する(stand-alone)DNSSEC対応リゾルバも多くの同じ要件を持つ。 DNSSEC対応再帰ネームサーバ固有の機能についてはセクション3.2で規定する。 4.1. EDNSのサポート DNSSEC対応リゾルバは、問合わせ送信時にDOビット([RFC3225])が 設定されたEDNS([RFC2671]) OPT擬似RRを入れなければならない(MUST)。 DNSSEC対応リゾルバは、少なくとも1220オクテットのメッセージサイズを サポートしなければならず(MUST)、4000オクテットのメッセージサイズを サポートすべき(SHOULD)である。 また、EDNS OPT擬似RR内の"sender's UDP payload size"フィールドを使用して 受信できるメッセージサイズを広報しなければならない(MUST)。 DNSSEC対応リゾルバのIP層は、受信したパケットがIPv4かIPv6であるかに 関わらず、フラグメントされたUDPパケットを正しく処理できなければ ならない(MUST)。これらの要件に関する議論については[RFC1122]、[RFC2460] および[RFC3226]を参照のこと。 4.2. 署名検証のサポート DNSSEC対応リゾルバはセクション5で規定する署名検証の仕組みを サポートしなければならず(MUST)、また受信した応答全てに対して その仕組みを適用すべき(SHOULD)である。ただし以下の場合は例外とする。 ・DNSSEC対応リゾルバがDNSSEC対応再帰ネームサーバの一部であり、かつ応答が CDビットを設定された再帰問合わせ要求の結果得られたものである場合。 ・何らかのアプリケーションインターフェースを通してDNSSEC対応リゾルバに 検証を行わないよう指示した問合わせに対する応答である場合。 ・ローカルポリシーにより、問合わせに対する検証が無効にされている場合。 Arends, et al. Standards Track [Page 19] RFC 4035 DNSSEC Protocol Modifications March 2005 DNSSEC対応リゾルバの署名検証サポートには、ワイルドカード所有者名の 検証も含まれなければならない(MUST)。 DNSSEC対応リゾルバは、署名検証を実行するために、不足しているDNSSEC RRの 問合わせを行ってもよい(MAY)。この問合わせ実行を選択した実装は、 得られた応答がオリジナルの応答を検証するには不十分であることを 認識していなければならない。例えばオリジナルの問合わせとその後の問合わせの 間に発生したゾーン更新により、求めている情報が変更(または削除)されてしまう 可能性もある。 ゾーンカットの親側にあるNSEC RRが不足していてそれを取得しようと試みる 場合、DNSSEC対応の反復検索を行うリゾルバ(フルリゾルバ)は、子ゾーンでは なく親ゾーンのネームサーバに問合わせをしなければならない(MUST)。 DSが不足していてそれを取得しようと試みる場合、DNSSEC対応の反復検索を 行うリゾルバは、子ゾーンではなく親ゾーンのネームサーバに問合わせを しなければならない(MUST)。 セクション3.1.4.1で規定したように、DNSSEC対応ネームサーバはDS RRの 処理に特別な処理規則を適用する必要がある。リゾルバもまた、親側の NS RRsetを保持していなければ、親ゾーンのネームサーバを特定するために 特別な処理規則を適用しなければならない場合がある。 親のNS RRsetを特定するために、リゾルバは委任名から処理を開始できる。 一番左側のラベルを取り除いた上でその名前のNS RRsetを問い合わせる。 その名前に対してNS RRsetが存在しない場合、リゾルバは残されたラベルから 一番左のラベルを取り除き、その名前に対する問合わせを行う。この木構造を 上に登っていく処理をNS RRsetが見つかるかラベルが無くなるまで繰り返す。 4.3. データのセキュリティ状態の判定 DNSSEC対応リゾルバは、特定のRRsetが署名付きであると期待すべきかどうかを 判定できなければならない(MUST)。より厳密には、DNSSEC対応リゾルバは 以下の4つの場合を識別できなければならない。 Secure(検証成功：信頼度高) トラストアンカーからそのRRsetに至る、署名付きDNSKEY RRおよびDS RRの 連鎖を構築できる。この場合、そのRRsetは署名付きのはずであるから、 先に記述した署名検証を行うことができる。 Insecure(未署名状況検出：信頼度低) トラストアンカーからそのRRsetに至る、署名付きDNSKEY RRおよびDS RRの 連鎖が存在しないことがわかっている。対象のRRsetが未署名ゾーンに存在 したり、未署名ゾーンの下位に存在する場合にこのような状況が生じ得る。 この場合、RRsetは署名付きであるかもしれないし、未署名かもしれないが、 いずれにせよリゾルバは署名を検証できない。 Arends, et al. Standards Track [Page 20] RFC 4035 DNSSEC Protocol Modifications March 2005 Bogus(検証失敗：信頼禁止) トラストアンカーからそのRRsetに至る、信頼の連鎖を構築できると 想定していたが、何らかの理由で署名検証に失敗したか、存在すべき 適切なDNSSEC RRが無いために信頼の連鎖が構築できない。 このような状況は攻撃を示唆している場合もあるが、設定エラーや 何らかのデータ破損を示唆する場合もある。 Indeterminate(検証対象外：信頼度低) リゾルバが必要なDNSSEC RRを得られなかったため、そのRRsetが署名付きか どうかを判断できない。DNSSEC対応リゾルバが署名ゾーンを管理する DNSSEC対応ネームサーバにアクセスできない場合にこのような状況が 生じ得る。 4.4. トラストアンカーの取得 DNSSEC対応リゾルバは、少なくとも1つの信頼できる公開鍵またはDS RRを 設定情報から取得できなければならず(MUST)、複数の信頼できる公開鍵または DS RRを設定情報から取得できるようにすべき(SHOULD)である。 DNSSEC対応リゾルバは、このような設定情報から取得したトラストアンカー無し では署名検証を行えないので、リゾルバ起動時にこの種の鍵を得られる適度に 強固な何らかの仕組みを持つべき(SHOULD)である。例えば(ディスクドライブの ような)揮発しない記憶装置や、信頼できるローカルネットワーク経由で設定を 取得するなどが挙げられる。 また、トラストアンカーが保持する鍵情報は安全な手段で更新されることに 注意してもらいたい。安全な手段としては、物理的メディアを介するものや、 鍵交換プロトコル、他の帯域外(out-of-band)の手段等が考えられる。 4.5. 応答のキャッシュ ある所有者名に対してRRsetと関連するDNSSEC RRが存在する場合、DNSSEC対応 リゾルバは、その所有者名を持つ個々の応答をアトミック性を持つ 単一エントリーとしてキャッシュすべきである。キャッシュに含まれる個々の 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レコードを使用することにより、回答がワイルドカードから合成 されたことが推測できる場合。 DNSSEC対応対応再帰ネームサーバは、最初に受信したオリジナルの回答に 含まれるワイルドカードデータをキャッシュし、最初の問合わせ対象 以外の名前への問合わせに対する肯定応答を生成することができる。 2. ある名前の不在を証明するNSEC RRを受信した場合。 DNSSEC対応リゾルバは、NSEC RRをキャッシュし再利用することにより、 NSEC RRが指定する範囲内に最初の問合わせ以外の名前が存在しないことを 証明する不在応答を生成することができる。 理論的には、リゾルバはTTLやレコードの署名が期限切れになるまでワイルドカード またはNSEC RRを使用して肯定および不在応答をそれぞれ生成することができる。 しかし、リゾルバが新しい権威を持つデータを得たり、リゾルバが保持するデータ から新しいデータを合成したりすることを阻害しない方が賢明に思われる。 この推奨に従うリゾルバはより一貫性のある名前空間の構成情報を 得られるだろう。 4.6. CDビットおよびADビットの処理 DNSSEC対応リゾルバは、ローカルポリシーが要求する認証処理について自分が 責任を負うことを示すために、問合わせのCDビットを設定してもよい(MAY)。 DNSSEC対応再帰ネームサーバの振る舞いに対してこのビットの設定が与える 影響についてはセクション3.2を参照のこと。 自分が理解できないヘッダービットを問合わせメッセージから応答メッセージに 無分別にコピーしてしまうような不適当な動作をするネームサーバの影響を 避けるために、DNSSEC対応リゾルバは問合わせメッセージ生成時に ADビットをクリアしなければならない(MUST)。 応答メッセージが安全なチャネルから得られたか、安全なチャネルから応答を 得られない場合はメッセージヘッダーに注意せよという設定が特にされていない 限り、リゾルバは応答に含まれるCDおよびADビットを無視しなければならない (MUST)。 4.7. BADデータのキャッシュ 短期的な多くの署名検証エラーが発生することが予想されるが、その中の 幾つかのもの、例えば管理上のエラー(ゾーンへの再署名失敗、時刻のずれ等)が 原因の署名検証エラーは長期にわたる可能性がある。 そのような状況では、再問合わせは役に立たないので、署名を検証する リゾルバが署名検証の失敗が続いているRRsetに対する問合わせを繰り返すと、 不要なDNSトラヒックを大量に発生させてしまう。 そのような不要なDNSトラヒックを抑制するために、DNSSEC対応リゾルバは 署名が無効なデータを制限付きでキャッシュしてもよい(MAY)。 Arends, et al. Standards Track [Page 22] RFC 4035 DNSSEC Protocol Modifications March 2005 概念的には、そのようなデータのキャッシュはネガティブキャッシュ ([RFC2308])と同様である。違いは有効な不在応答をキャッシュするのではなく、 特定の回答の検証に失敗したという事実をキャッシュすることにある。 本文書では、この署名が無効なデータのキャッシュを"BADキャッシュ (検証失敗キャッシュ)"と呼ぶ。 BADキャッシュを実装しているリゾルバは、そのキャッシュを利用した サービス不能攻撃の踏み台にならないよう、幾つかの処理を行わなければ ならない(MUST)。具体的には以下のとおりである。 ・署名検証に失敗したRRsetのTTLは信頼できないので、実装はTTLを自分で 割り当てなければならない(MUST)。攻撃の結果をキャッシュした影響を 軽減するために、このTTLは小さくすべき(SHOULD)である。 ・一時的に生じた署名検証失敗(この失敗も攻撃の影響である可能性がある)を キャッシュしてしまわないように、検証が失敗した問合わせを追跡すべき (SHOULD)である。一定のしきい値の回数を越えて署名検証に失敗した への問合わせに対してだけBADキャッシュを 使用して応答すべき(SHOULD)である。 特定のRRsetに対して、本文書のセクション4.2で規定する規則に従った 署名検証が求められていない限り、リゾルバはRRsetへの問合わせに対して BADキャッシュを使用して応答してはならない(MUST NOT)。 DNSSEC対応再帰ネームサーバがどのようにBADキャッシュを使用して 応答を返すかに関する議論はセクション3.2.2を参照のこと。 4.8. 合成されたCNAMEの処理 署名を検証するDNSSEC対応リゾルバは、有効な署名付きDNAME RRから [RFC2672]の規定にしたがって未署名CNAME RRが合成された場合に、 DNAME RRの署名が未署名CNAME RRも対象としているものとして処理 しなければならない(MUST)。少なくとも、未署名のCNAME RRが存在する という理由で応答メッセージを拒否してはならない。 リゾルバはこのようなCNAME RRをキャッシュしたり応答に入れたり してもよい(MAY)が、特にそうすることを要求するものではない。 4.9. スタブリゾルバ DNSSEC対応スタブリゾルバはDNSSEC RRタイプをサポートしなければ ならない(MUST)。少なくとも応答にDNSSEC RRが含まれているために 誤った応答をしてはならない。 Arends, et al. Standards Track [Page 23] RFC 4035 DNSSEC Protocol Modifications March 2005 4.9.1. DOビットの処理 署名を検証しないDNSSEC対応スタブリゾルバは、スタブリゾルバを呼び出した アプリケーションへの応答に、DNSSEC対応再帰ネームサーバから返された DNSSEC RRを含めてもよい(MAY)が、特にそうすることを要求するものではない。 署名を検証しないスタブリゾルバがDNSSEC RRをアプリケーションに 返そうとする場合、再帰ネームサーバからDNSSEC RRを受信するために DOビットを設定する必要がある。 署名を検証するDNSSEC対応スタブリゾルバはDOビットを設定しなければ ならない(MUST)。そうしなければ署名検証に必要なDNSSEC RRを受信できない からである。 4.9.2. CDビットの処理 署名を検証しないDNSSEC対応スタブリゾルバは、アプリケーション層から 要求されない限り送信時にCDビットを設定すべきではない(SHOULD NOT)。 定義により、署名を検証しないDNSSEC対応スタブリゾルバはDNSSEC対応 再帰ネームサーバに署名検証の実行を依存するものだからである。 署名を検証するDNSSEC対応スタブリゾルバはCDビットを設定すべき(SHOULD) である。そうしなければDNSSEC対応再帰ネームサーバはネームサーバの ローカルポリシーを使用して問合わせに応答するため、スタブリゾルバの ローカルポリシーが許容できるデータを受信できないかもしれないからである。 4.9.3. ADビットの処理 署名を検証しないDNSSEC対応スタブリゾルバは、応答を返したDNSSEC対応 再帰ネームサーバが応答メッセージの回答部および権威部のデータを暗号技術で 検証したことを明示しているかを判定するために、ADビットの状態を調査しても よい(MAY)。ただし、DNSSEC対応スタブリゾルバが受信した応答はDNSSEC対応 再帰ネームサーバのローカルポリシーに強く依存していることに注意して もらいたい。したがって、デバッグの手がかりとするような例外を除けば、 ADビットの状態を検査する実際的な価値はわずかであろう。 DNSSEC対応スタブリゾルバが信頼できるDNSSEC対応再帰ネームサーバから 安全なチャネルを通してデータを得た場合を除き、どのような場合でも DNSSEC対応スタブリゾルバは自分の代わりに行ったとされる署名検証を 信頼してはならない(MUST NOT)。 署名を検証するDNSSEC対応スタブリゾルバは、応答メッセージにADビットが 設定されているかを検査すべきではない(SHOULD NOT)。 定義により、署名を検証するDNSSEC対応スタブリゾルバはADビットが 設定されているかどうかに拘わらず署名検証を行うからである。 Arends, et al. Standards Track [Page 24] RFC 4035 DNSSEC Protocol Modifications March 2005 5. DNS応答の認証 DNSSEC RRを使用した認証を行うために、DNSSEC対応リゾルバは少なくとも 1つの認証された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が存在するか、および 起点となるDNSKEY RRでそのRRSIG RRを署名検証し、DNSKEY RRsetを 認証できるか確認する。RRSIG RRを使用したRRsetの認証処理については セクション5.3で規定する。 起点となるDNSKEY RRを使用して、リゾルバがゾーン頂点のDNSKEY RRsetを 一旦認証したならば、DS RRを使用してそのゾーンからの委任を認証できる ようになる。このように、リゾルバは起点となる鍵から認証を開始し、 他のゾーン頂点にあるDNSKEY RRsetの取得とDS RRsetの使用により、再帰的に DNS木構造の下方に向けて認証を続けることが可能になる。 リゾルバが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がゾーン内に存在しないことを証明する方法を示す。 Arends, et al. Standards Track [Page 25] RFC 4035 DNSSEC Protocol Modifications March 2005 リゾルバが(DOビットを設定して)DNSSECサポートを明示した場合、DNSSEC対応 ネームサーバは必要なDNSKEY、RRSIG、NSECおよびDS RRsetを応答で提供しようと 試みるべきである(セクション3参照)。 しかし、上流にあるDNSSEC非対応再帰ネームサーバが偶然DNSSEC RRを 抑制したり、意図的な攻撃による応答の改ざんでDNSSEC RRが消去される、 あるいは問合わせを一部変更されてDNSSEC RRを要求できないなどの理由に より、DNSSEC対応リゾルバは依然として適切なDNSSEC RRを欠いた応答を 受信する場合がある。 リゾルバは応答の中にDNSSECデータが存在しないという事実から、認証情報が 存在しないと解釈してはならない(MUST NOT)。 リゾルバは署名ゾーンから認証情報が得られると期待すべき(SHOULD)である。 リゾルバは、あるゾーンに関する公開鍵が設定されているか、または あるゾーンの親が署名付きでその親からの委任にDS RRsetが設定されている場合、 そのゾーンは署名付きであると見なすべき(SHOULD)である。 5.1. セキュリティの島に関する特別な考慮点 セキュリティの島([RFC4033]参照)は、その親から認証の連鎖を構築できない 署名ゾーンである。セキュリティの島内部にある署名を検証するためには、 バリデータ(validator：署名検証モジュール)が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のダイジェスト値と一致する。 ・DS RRと一致した子ゾーンのDNSKEY RRには署名鍵フラグが設定されており、 対の秘密鍵で子ゾーンの頂点にあるDNSKEY RRsetに署名している。 署名の結果得られたRRSIG RRが子ゾーンの頂点にあるDNSKEY RRsetを 認証している。 親ゾーンから得られた参照がDS RRsetを含まない場合、委任された名前に関する DS RRsetが存在しないことを証明する署名付きNSEC RRsetが応答には含まれて いるべきである(セクション3.1.4参照)。DNSSEC対応リゾルバは、参照に 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では そのビットはクリアされているからである。DNSSEC対応リゾルバが 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の有効性検査 以下の条件が全て満たされていれば、DNSSEC対応リゾルバは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の正規形式は、RRsetを構成する各RRの順番 を考慮しないとしても、受信したRRsetと異なる場合がある。それは DNS名前圧縮、TTLのデクリメントあるいはワイルドカード展開などの 理由による。バリデータはオリジナルの署名付きデータを再構成 するために以下の手続きを使用すべきである。 署名付きデータ = 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の所有者名のFQDN表記 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の所有者名のFQDN表記のラベル数と 一致しない場合、そのRRsetは無効なものか、ワイルドカード展開によって 得られたものかのどちらかである。 リゾルバはRRsetを信頼できると見なす前に、ワイルドカード展開が 適切に行われたかを検証しなければならない(MUST)。 セクション5.3.4でワイルドカードが適切に適用されたかを判断する方法を示す。 RRsetが複数のRRSIG RRを持つ場合、リゾルバがこれらの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が 存在しないことを証明することができる。DNSSEC対応ネームサーバは、 DNSSEC対応リゾルバへの応答の中に署名ゾーンに関して必要な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の不在も証明する必要がある。 更に、DNSSEC対応リゾルバはセクション5.3に記載する不在証明を含む NSEC RRsetを認証しなければならない(MUST)。 Arends, et al. Standards Track [Page 32] RFC 4035 DNSSEC Protocol Modifications March 2005 あるRRsetの不在を証明するためには、問合わされたRRsetが存在しないこと、 そして関連するワイルドカードRRsetが存在しないことの両方をリゾルバが 検証できなければならない。 これを証明するためには、ゾーン内のNSEC RRsetが2つ以上必要かもしれない。 必要なNSEC RRsetが応答に全て含まれていない場合 (おそらくはメッセージ 切り詰めによって)、DNSSEC対応リゾルバは問合わされた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ビットが 設定されている場合に限り、完全な応答を返さなければならない(MUST)。 署名検証できなかった応答のキャッシュについてはセクション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. セキュリティに関する考慮点 本文書はDNSSECが公開鍵暗号を使用してDNSリソースレコードセットに 署名する方法、リソースレコードセットを認証する方法を規定している。 用語およびDNSSECに関連するセキュリティに関する考慮点については [RFC4033]を参照のこと。またDNSSECリソースレコードセット固有の考慮点に ついては[RFC4034]を参照のこと。 Arends, et al. Standards Track [Page 33] RFC 4035 DNSSEC Protocol Modifications March 2005 DNS問合わせメッセージのCDビットが設定できる、あるいはDNS応答メッセージの ADビットを設定できるやり手の攻撃者は、これらのビット設定を使用して、 DNSSECがDNSSEC非対応再帰型リゾルバに提供する保護の仕組みを突破する ことができる。この理由により、DNSSEC対応再帰型リゾルバがこれらの 制御ビットを使用する場合は安全なチャネルが必要となる。詳細な議論に ついてはセクション3.2.2および4.9参照のこと。 本文書で規定するプロトコルは、DNSSEC非対応スタブリゾルバに対しても DNSSECで得られる利益を拡大しようと試みるものである。 しかし、署名検証失敗後の復旧手続きはアプリケーション固有になる可能性が 高いので、DNSSECがスタブリゾルバに利便性を提供するのは不適当かもしれない。 DNSSEC対応再帰ネームサーバの運用者は、ローカルな署名検証ポリシーを 選択する際には、サービスを利用するアプリケーションの振る舞いに 充分な注意を払わなければならないだろう。さもないと、再帰ネームサーバが 本来クライアントに向けてサポートしようとしていたサービスを誤って 拒否してしまう結果になりかねない。 8. Acknowledgements This document was created from the input and ideas of the members of the DNS Extensions Working Group and working group mailing list. The editors would like to express their thanks for the comments and suggestions received during the revision of these security extension specifications. Although explicitly listing everyone who has contributed during the decade in which DNSSEC has been under development would be impossible, [RFC4033] includes a list of some of the participants who were kind enough to comment on these documents. 9. References 9.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. [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. Informative References [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= ) exampleゾーンの頂点にあるDNSKEY RRsetは2つのDNSKEY RRを含み、DNSKEY RDATA フラグはどちらも署名鍵であることを示している。2つのDNSKEY RRのうちの 1つにはSEPフラグが設定されており、頂点のDNSKEY RRsetに署名するために 使用されている。この鍵はハッシュされ、親ゾーンに保存されるDSレコードが 生成されているはずである。もう1つのDNSKEYはゾーン内の他のRRset全てに 署名するために使用される。 ゾーンはワイルドカードエントリー"*.w.example"を含む。 NSECの連鎖を構築する際に、この"*.w.example"という名前が使用されて いること、また "*.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. "Name Error"応答 権威を持つ名前に関するエラー応答。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. "No Data"応答 "No Data"を返す応答。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. "Wildcard Answer"応答 ワイルドカード展開により一致した問合わせへの応答。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. "Wildcard No Data"応答 ワイルドカードの展開範囲にある名前を対象とした"No Data"応答。 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に関する"No Data"応答 誤って子ゾーンのネームサーバに送信されたQTYPE=DSの問合わせに対する "No Data"応答。 ;; 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内の 全ての鍵は認証されたと見なされる。次に、リゾルバは1つ(以上)のルートの DNSKEY RRを使用して、"example"のDS RRsetを認証する。リゾルバは、 ルートのDNSKEY RRsetまたは"example"のDS RRsetを得るためにルートゾーンに 問合わせをしなければならないかもしれないことに注意してもらいたい。 Arends, et al. Standards Track [Page 49] RFC 4035 DNSSEC Protocol Modifications March 2005 "example"のDS RRsetがルートのDNSKEYで認証されたならば、リゾルバは "example"のDNSKEY RRsetの中に"example"のDS RRと一致するDNSKEY RRが 存在するかを調査する。一致する"example"のDNSKEYが見つかったならば、 リゾルバはそのDNSKEY RRが"example" DNSKEY RRsetに署名したかどうか、 および署名が有効期間内であるかを調査する。全ての条件が満たされたならば、 "example"のDNSKEY RRset内の全ての鍵は認証されたと見なされる。 最後に、リゾルバは"example"のDNSKEY RRsetの中に、アルゴリズムが5で 鍵タグが38519のDNSKEY RRが存在するかを調査する。その鍵が応答に含まれる RRSIGの認証に使用するDNSKEYである。複数の"example"のDNSKEY RRの アルゴリズム、鍵タグが条件に一致した場合、各DNSKEY RRを試し、 どれかが先に記述したように署名を検証できたならば、回答は認証される。 C.2. "Name Error"応答の認証 付録B.2に示した応答は、問い合わされたデータが存在しないことを証明する NSEC RR、および適用可能なワイルドカードが存在しないことを証明する NSEC RRを返している。 この不在応答は、両方のNSEC RRの署名検証を行うことによって認証される。 各NSEC RRは、先に示したMX RRsetの認証手順と同様の手順で認証される。 C.3. "No Data"応答の認証 付録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が認証されたならば、 リゾルバは"a.example"のDNSKEY RRsetの中に"a.example"のDS RRと一致する DNSKEY RRが存在するかを調査する。一致する"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. "Wildcard Answer"応答の認証 付録B.6に示した応答は、ワイルドカード展開の結果生成された回答を 返している。回答部には、従来のDNS応答と同様にワイルドカードを展開した 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. "Wildcard No Data"応答の認証 付録B.7に示した応答は、問い合わされたデータが存在しないことを証明する NSEC RR、および適用可能なワイルドカードが存在しないことを証明する NSEC RRを返している。この不在応答は、両方のNSEC RRの署名検証を 行うことによって認証される。 C.8. 子ゾーンのDSに関する"No Data"応答の認証 付録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 Authors' Addresses 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 Full Copyright Statement 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. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Arends, et al. Standards Track [Page 53]