ネットワークワーキンググループ O. Gudmundsson Request for Comments: 3658 2003年12月 更新: 3090, 3008, 2535, 1035 分類: 標準化過程(Standards Track) Delegation Signer (DS)リソースレコード(RR) 本文書の位置づけ 本文書はインターネットコミュニティのためにインターネット標準化過程に あるプロトコルを規定し、その向上のために議論と提案を求めるものである。 このプロトコルの標準化の状況については「Internet Official Protocol Standards」(STD 1)の最新版を参照のこと。本文書の配布は制限されない。 著作権表示 Copyright (C) The Internet Society (2003). All Rights Reserved. 要旨 Delegation Signer(DS)リソースレコード(RR)は、ゾーンの分割場所(zone cut) (すなわち委任ポイント)に挿入されるものであり、委任されたゾーンが 電子署名されていること、また委任されたゾーンが、提示された鍵をその 委任されたゾーンに関する有効なゾーン鍵として認識していることを示す。 DS RRは、運用上の考察が動機となった、DNSセキュリティ拡張の定義の 修正である。その意図は、ゾーンの委任に関して、推測に頼るよりむしろ、 このリソースレコードを明示的な委任の記述として使用することにある。 本文書はDS RRを定義し、その使用法の例を与え、リゾルバーへの影響を 記述する。この変更はRFC2535と下位互換ではない。本文書はRFC1035、 RFC2535、RFC3008、RFC3090を更新する。 Gudmundsson Standards Track [Page 1] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 目次 1. はじめに. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. 予約語. . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Delegation key Signerの仕様 . . . . . . . . . . . . . . . . . 4 2.1. Delegation Signerレコードモデル . . . . . . . . . . . . 4 2.2. プロトコルの変更. . . . . . . . . . . . . . . . . . . . 5 2.2.1. RFC2535 2.3.4および3.4: 委任ポイントにおける 特別な考察. . . . . . . . . . . . . . . . . . . 6 2.2.1.1. DSの問い合わせに対する特別な処理 . . . 6 2.2.1.2. 子と先祖がネームサーバーを共有する 場合の特別な処理 . . . . . . . . . . . 7 2.2.1.3. 応答構成時におけるKEY RR使用の変更 . . 7 2.2.2. 署名者名(RFC3008のセクション2.7を置き換えるもの) 9 2.2.3. RFC3090に対する変更 . . . . . . . . . . . . . . 9 2.2.3.1. RFC3090: セクション1「はじめに」の更新 9 2.2.3.2. RFC3090のセクション2.1: 大域的に安全な 状態(Globally Secured) . . . . . . . . 9 2.2.3.3. RFC3090のセクション3: 実験的状態 (Experimental Status). . . . . . . . . 10 2.2.4. NULL KEYの廃止. . . . . . . . . . . . . . . . . 10 2.3. プロトコル変更に関するコメント. . . . . . . . . . . . . 10 2.4. DSレコードのワイヤーフォーマット. . . . . . . . . . . . 11 2.4.1. フィールドの正当化 . . . . . . . . . . . . . . 12 2.5. DSレコードの表記フォーマット. . . . . . . . . . . . . . 12 2.6. 過去の方式を導入した環境の移行に関する問題. . . . . . . 12 2.6.1. RFC2535およびRFC1035との後方互換性. . . . . . . 12 2.7. KEYと対応するDSレコードの例 . . . . . . . . . . . . . . 13 3. リゾルバー. . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. DSの例. . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2. DSレコードに関するリゾルバーのコスト評価. . . . . . . . 15 4. セキュリティに関する考察. . . . . . . . . . . . . . . . . . . 15 5. IANAに関する考察. . . . . . . . . . . . . . . . . . . . . . . 16 6. 知的所有権に関する表記. . . . . . . . . . . . . . . . . . . . 16 7. 謝辞. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. 参考文献. . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. 必須の参考文献. . . . . . . . . . . . . . . . . . . . . 17 8.2. 有用な参考文献. . . . . . . . . . . . . . . . . . . . . 17 9. 著者の連絡先. . . . . . . . . . . . . . . . . . . . . . . . . 18 10. 完全な著作権表示. . . . . . . . . . . . . . . . . . . . . . . 19 Gudmundsson Standards Track [Page 2] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 1. はじめに 読者は、DNSシステム[RFC1035]、DNSセキュリティ拡張[RFC2535]、および DNSSEC用語[RFC3090] に精通していることが重要である。 管理上異なる2つのDNSゾーンに同じデータが存在できる場合、そのデータの 同期もれが頻繁に発生することが経験上示されている。あるゾーンの頂点以外の 場所にNS RRセットが存在するということは、ゾーンが分割されているか、 委任されていることを示す。NS RRセットのRDATAは、委任されたゾーンまたは 子(child)ゾーンに対する権威サーバーを指定する。実際の測定によれば、 インターネット上の全委任のうち10～30%は親と子でNS RRセットが異なっている。 これには多くの理由がある。例えば親と子の間で意志の疎通が充分でない ことや、レジストリの要件を満たすために偽のネームサーバーがリストされる ことなどが挙げられる。 DNSSEC[RFC2535、RFC3008、RFC3090]は、検証可能なKEYの連鎖を生成するために、 子ゾーンは親から署名されたKEY RRセットを持たなければならないと 規定している。署名された鍵をどこに保持するか、子側[RFC2535]または親側か について議論がなされてきた。KEY RRセットを子側に置く場合、子側に 置かれた署名されたKEY RRセットを保守するために、親子間の双方向の通信が 頻繁に必要になる。はじめに、子が親にKER RRセットを転送し、次に親が子に 署名(群)を送信する。親側にKEY RRセットを保管すれば、この通信を簡略化 できると考えられる。 DNSSEC[RFC2535]は、親は安全でない子ゾーンに対して、安全でないことを 示すためにNULL KEYレコードを保持することを求めている。子が安全でない というわずか1ビットの情報を送るために、全体が署名されたRRセットを 使用することを考えると、NULL KEYレコードは無駄である。多くの場合、 NULL KEY RRセットの探索は、名前解決処理を複雑にする。子の ネームサーバーがKEY RRセットを返さない場合、親と子それぞれの ネームサーバーにKEY RRセットの問い合わせが必要になるからである。 KEY RRセットを親ゾーンにだけ保存すれば、この処理が簡略化され、 NULL KEY RRセットを完全に無くすことができるだろう。大規模な 委任ゾーンにとって、NULL鍵のコストが展開を妨げる深刻な障壁と なっている。 RFC3445[RFC3445]で制限が導入される以前には、DNSSEC鍵モデルに影響する ものとして、KEYレコードをDNSSEC鍵に加えて他のプロトコル用の公開鍵を 保存するために使用できるというものがあった。これには、以下に示すものを 含む数多くの潜在的な問題が存在している。 1. 多くのアプリケーションやプロトコルがそれぞれの鍵をゾーンの頂点に 保存する場合、KEY RRセットが非常に大きくなり得る。考えられる プロトコルとしてはIPSEC、HTTP、SMTP、SSH、公開鍵暗号を使用する 他のプロトコルなどが挙げられる。 Gudmundsson Standards Track [Page 3] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 2. KEY RRセットの頻繁な更新が必要になるかもしれない。 3. 緊急の鍵更新手続きを誘発させるセキュリティ侵害、鍵の紛失の確率が 増大する。 4. DNSSECゾーン鍵でないものを含むKEY RRセットに対して親が署名を拒否 するかもしれない。 5. 親がKEY RRセットに再署名する際に、所要時間が子の期待する条件と合致 しないかもしれない。 これらの理由により、親が子の鍵の署名を保持する方式(SIG@parent)は、子が 自分の鍵と鍵の署名を保持する方式(SIG/KEY@child)に比べて、何ら利点はない。 1.2. 予約語 本文書におけるキーワード「してもよい(MAY)」「しなくてもよい(MAY NOT)」 「しなければならない(MUST)」「してはならない(MUST NOT)」 「要求される(REQUIRED)」「推奨される(RECOMMENDED)」 「すべきである(SHOULD)」「すべきでない(SHOULD NOT)はBCP14、RFC2119 [RFC2119]に記述されているとおりに解釈される。 2. Delegation key Signerの仕様 このセクションはDelegation Signer (DS) RRタイプ(タイプコード43)と、 DNSがこれに対応するための変更を定義する。 2.1. Delegation Signerレコードモデル 本文書はDNSSEC KEYレコードの信頼の連鎖[RFC2535]に対して、親側にだけ 存在する新しいRRを使用した代替案を提示する。このレコードは、子が 自身のKEY RRセットを自己署名する際に使用する鍵(群)を識別する。 DSが鍵の2つの役割、鍵署名鍵(Key Signing Key: KSK)とゾーン署名鍵 (Zone Signing Key: ZSK)を識別するとしても、ゾーンはこれらの役割の ために2つの異なる鍵を使用しなくてもよい。多くの小さなゾーンは 1つの鍵だけを使用する一方で、大きなゾーンでは複数の鍵を使用する 場合が多くなることが予想される。 信頼の連鎖は、親のKEY RRセット、すなわち親から得たDS RRセットと 子側にあるKEY RRセットを検証することにより確立される。これは KEYレコードを使用する場合と暗号論的に等価である。 子は親に対して自身の頂点KEY RRセットに署名する鍵の変更を通知するだけで よくなるため、親と子の間の通信は大幅に減少する。 親は、子の頂点KEY RRセットに含まれる他の鍵は全て関知しない。 更に、子は頂点KEY RRセットとその内容を完全に制御する。子は親への 影響を最小限に抑えながら、DNSSEC用の鍵の使用に関して、任意のポリシーを 維持することが可能となる。 Gudmundsson Standards Track [Page 4] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 したがって、子がDNSゾーン鍵の頻繁な更新を行いたい場合、親はそれを 意識する必要はない。子はある鍵を頂点KEY RRセットに署名するためだけに 使用し、他の鍵をゾーン内の他のRRセットに署名するために使用できるから である。 このモデルはDNSSECのゆっくりした範囲の拡大とセキュリティーの島 モデル(*1)によく適合する。このモデルでは、"good.example."を信頼する 者は、"good.example."から得た鍵を信頼鍵として事前に設定することができ、 その後はその鍵によって署名されているか、その鍵への信頼の連鎖を持つ データを全て信用できるようになる。"example."がDSレコードの広報を 開始した場合、"good.example."は自己署名を一時停止すれば運用を 変更する必要はない。信頼鍵を識別するために、KEYレコードの代わりに DSレコードを設定ファイルの中で使用することができる。 もう1つ、特筆すべき利点として、大規模なゾーンに保存される情報の量が 減るというものがある。RFC2535の要求にしたがって安全でない 委任ひとつひとつにNULL KEYレコードを設定するのではなく、安全な委任だけが 署名付DS RRセット形式の付加情報を必要とするからである。 この方式の主な欠点は、ゾーンのKEY RRセットの検証をする際に、 RFC2535方式の信頼の連鎖では1度で済む署名の検証処理を2度行う必要がある ことである。他のタイプのRRセットに関しては、検証される署名数に 影響はない。 《脚注》 *1: 「セキュリティーの島モデル」 DNS木構造の中で、DNSSEC的に安全なゾーンが島のように点在している という状態を指す。 2.2. プロトコルの変更 DSをサポートする全てのDNSサーバーとリゾルバーは、OKビット[RFC3225]と、 より大きなメッセージサイズ[RFC3226]をサポートしなければならない(MUST)。 委任が安全であるとみなされるために、委任はDS RRセットを含まなければ ならない(MUST)。問い合わせがOKビットを含む場合、委任への参照を返す ネームサーバーは、権威部(authority section)に以下のRRを、以下に示す 順序で含めなければならない(MUST)。 DS RRセットが存在する場合: 親が持つ子のNS RRセットのコピー DSとSIG(DS) DS RRセットが存在しない場合: 親が持つ子のNS RRセットのコピー 親のゾーンNXTとSIG(NXT) これにより、参照メッセージのサイズが増大し、その結果一部または 全てのグルー(glue)が省略されてしまう可能性がある。署名付DSまたは NXT RRセットがDNSメッセージに収まらない場合、TCビットが設定 されなければならない(MUST)。付加情報部(additional section)の処理は 変更されない。 NS RRセットに付随しているDS RRセットは、子ゾーンが安全であることを 示している。DS RRセットのないNS RRセットがある場合、子ゾーンは (親の視点から見て)安全ではない。DS RRセットは、委任されない部分や ゾーンの頂点にあってはならない(MUST NOT)。 Gudmundsson Standards Track [Page 5] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 セクション2.2.1はDSの問い合わせに応答する権威ネームサーバーに関連する 特別な考察を定義し、RFC2535のセクション2.3.4と3.4を置き換えるものである。 セクション2.2.2はRFC3008のセクション2.7を置き換え、セクション2.2.3は RFC3090を更新する。 2.2.1. RFC2535 2.3.4および3.4: 委任ポイントにおける特別な考察 DNSセキュリティは、個々のゾーンをゾーン所有者の完全な制御下にあり、 各エントリー(RRセット)はゾーン管理者が保有する特別な秘密鍵で 署名されているデータ一式であると考える。しかし、DNSプロトコルは ゾーン内のリーフノードで、同時に子ゾーンの頂点ノードでもあるもの (すなわち委任ポイント)を"まさに"子ゾーンに属すると考える。対応する ドメイン名は2つのマスターファイルに記述され、親と子双方の鍵で署名された RRセットを持つかもしれない。1台のネームサーバーが委任ポイントの上位と 下位のゾーンにサービスを提供することがある[RFC2181]ため、1回の検索で、 これらのRRセットとSIGが混在したものを取得する可能性がある。 親ゾーン内に保存されるDS RRセットは、それぞれ少なくとも1つの 親ゾーンの秘密鍵で署名されなければならない(MUST)。親ゾーンは 委任ポイントにKEY RRセットを含んではならない(MUST NOT)。 親における委任はNS、DS、NXT、SIG RRタイプだけを含めてもよい(MAY)。 NS RRセットは署名されてはならない(MUST NOT)。NXT RRセットは 例外的な事例であり、これは親と子のゾーンの両方が安全である場合、 常にその両方のゾーンに個別に、権威ある形で記述される。 安全なゾーンは、自己署名されたKEY RRセットをその頂点に含まなければ ならない(MUST)。親から取得したDS RRセットの検証の際に、リゾルバーは DS RRセット内で識別される全ての鍵を、子の頂点KEY RRセットの有効な 署名者として信頼してもよい(MAY)。KEY RRセットに署名する鍵の1つを 信頼するように設定されたリゾルバーは、KEY RRセット内のゾーン鍵で 署名されたデータを全て安全なものとして信頼してもよい(MAY)。 それ以外の場合は、リゾルバーはゾーンを安全ではないと見なさなければ ならない(MUST)。 タイプDSの問い合わせを受けた権威ネームサーバーは、回答部(answer section)で DS RRセットを返さなければならない(MUST)。 2.2.1.1. DSの問い合わせに対する特別な処理 あるネームサーバーが委任ポイントにおいて親ゾーンに対して権威を 持っており、その名前に対するDSレコードの問い合わせを受信した場合、 サーバーは親ゾーン内のデータに基づいて応答し、DSか否定的応答の どちらかを返さなければならない(MUST)。これはサーバーが子ゾーンの 権威サーバーを兼ねていても、兼ねていなくても同じである。 Gudmundsson Standards Track [Page 6] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 ネームサーバーが委任ポイントにおいて子ゾーンに対して権威を持つが、 親ゾーンに対しては権威を持たない場合、適切な応答は存在しない。 子ゾーンはゾーンの頂点にあるDSレコードに関して権威を持たないからである。 これらの問い合わせは、DS対応ではない再帰的ネームサーバー(recursive nameserver)が生成しただけであると予想されるので、権威ネームサーバーは 以下の応答を返さなければならない(MUST)。 RCODE: NOERROR AAビット: 設定する 応答部: 空 権威部: SOA [+ SIG(SOA) + NXT + SIG(NXT)] つまり、サーバーは権威を持ち、DSレコードが存在しないかのように応答 する。DS対応の再帰的ネームサーバーは委任ポイントの親ゾーンに問い合わせを 行うので、この振る舞いに影響を受けることはない。 子ゾーンに対してだけ権威を持つネームサーバーが、再帰検索ネームサーバー (キャッシュサーバー)も兼ねている場合、そのサーバーは(問い合わせの RDビットが設定されていれば)委任ポイントにおけるDSレコードを 検索するために再帰処理を実行してもよい(MAY)。また、キャッシュに含まれる DSレコードを返してもよい(MAY)。この場合、応答にAAビットを設定しては ならない(MUST NOT)。 2.2.1.2. 子と先祖がネームサーバーを共有する場合の特別な処理 DS RR対応のネームサーバーが円滑に古いキャッシュと相互処理を行える ように、特別なルールが必要である。さもないと、古いキャッシュは DS RRセットが存在するために、ネームサーバーを不適切にいわゆるlameであると 分類してしまうかもしれない。 このような状況は、あるネームサーバーがゾーンと祖父ゾーン (grandparent zone)に対して権威を持つが、親に対しては権威を持たない場合に 発生する。これはわかりにくい例に思われるかもしれないが、非常に現実的な ものである。ルートゾーンは現在13台のマシンによって提供されており、 "root-servers.net."は13台のうち4台によって提供されている。しかし、 "net."は異なるネームサーバーによって提供される。 ネームサーバーが(, DS, )に対する問い合わせを受信した 場合、ルールを以下の順序で適用することによって応答を決定しなければ ならない(MUST)。 1) ネームサーバーがDS RRセットを持つゾーンに対して権威を持つ場合 (すなわち、ゾーンはを委任している。換言すれば"親"ゾーンで ある)、応答はDS RRセットを含む権威応答になる。 2) ネームサーバーが再帰サービスを提示しており、問い合わせにRDビットが 設定されていたならば、ネームサーバーは(後述するリゾルバーに対する ルールにしたがって)自身が問い合わせを実行し、検索結果を応答する。 Gudmundsson Standards Track [Page 7] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 3) ネームサーバーがのSOA RRセットを持つゾーンに対して権威を 持つ場合、応答は2.2.1.1で記述される権威を持つ否定的応答となる。 4) ネームサーバーがゾーンまたはQNAMEの上位ゾーンに対して権威を持つ場合、 最も多くのラベルを含む(最深一致の)ゾーンのサーバーに対して参照が なされる。 5) ネームサーバーがQNAMEのどの部分についても権威を持たない場合、 応答はQNAMEに対していわゆるlameなネームサーバーを示すものとなる。 これらのルールを使用するために、DS対応リゾルバーの一部に幾つかの特別な 処理が要求される。これを明らかにするために、例を使用する。 あるネームサーバーがroots.example.net.とルートゾーンに対して権威を 持つが、間にある2つのゾーン(または中間2ラベル分深いゾーン)に対しては 権威を持たないと仮定する。ここで、QNAME=roots.example.net、QTYPE=DS、 QCLASS=INであるとする。 リゾルバーはこの問い合わせを発行し(キャッシュされたデータは無い ものとする)、.net.のネームサーバーへの参照が返されることを期待する。 その代わり、先に示したルール番号3が適用され、ネームサーバーから 否定的応答が返される。リゾルバーの対応は、この応答を最終的なものとして 受理しない。否定的応答に含まれるSOA RRから、ネームサーバーが その応答をするに至った背景を判断できるからである。 解決策は、リゾルバーに総当り方式でデータの権威ゾーンを探索するよう 指示することである。 これは返されたSOA RRの所有者名を取り出し、NS応答が適切に得られるまで 左側のラベルを取り除くことによって達成される。ここで適切に応答が 得られるとは、応答にNSレコードが含まれることを意味する。(分割場所が ゾーン内で2ラベル分深い場所にある可能性を考慮する)。 話を例に戻すと、応答はroots.example.netが委任ドメインであるかどうかに よって、"roots.example.net."または"example.net."のSOA RRを持つ否定的 応答になる。どちらかの場合において、SOA所有者名の一番左側のラベルを 取り除くことにより、望まれるデータの場所が導き出される。 2.2.1.3. 応答構成時におけるKEY RR使用の変更 このセクションはRFC2535のセクション3.5を以下の内容に置き換えることに よって更新するものである。 Gudmundsson Standards Track [Page 8] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 KEY RRへの問い合わせを契機とした付加情報部の処理を発生させてはならない (MUST NOT)。セキュリティー対応のリゾルバーは対応するSIGレコードを 回答部に含める。 全ての問い合わせについて、応答の付加情報部にKEYレコードを加えるべきでは ない(SHOULD NOT)。 RFC2535はSOAまたはNSレコードが応答に含まれる場合、KEYレコードを 付加情報部に追加することを規定している。これは情報の往復を減らしたり (SOAの場合)、NULL KEYを廃棄する(NSの場合)ために行われる処理である。 本文書はNULL KEYを廃止するので、NSにKEYを含める必要はなくなる。 更に、SOAは否定的応答の権威部に含められるため、KEYを毎回含めることは 冗長なKEYレコードの転送を発生させる。 また、RFC2535のセクション3.5はAまたはAAAAタイプの問い合わせへの応答に KEY RRセットを追加するためのルールを含んでいる。Restrict KEY[RFC3445] は全てのアプリケーションでKEY RRの使用を廃止したので、このルールは もはや必要ないものである。 2.2.2. 署名者名(RFC3008のセクション2.7を置き換えるもの) SIG RRの署名者名フィールドには、データと署名が属するゾーンの名前が 含まれなければならない(MUST)。SIGを素材と見なす場合、署名者名、鍵タグ、 アルゴリズムの組み合わせによってゾーンを識別できなければならない(MUST)。 本文書はDNSSEC検証のための標準的なポリシーを定義する。局所的な ポリシーによって標準的なポリシーを上書きしてもよい(MAY)。 SIG(0)レコードの署名者フィールドには何も制約条件がない。このSIG(0)が 処理される場合には、署名者名、鍵タグ、アルゴリズムの組み合わせによって 鍵を識別できなければならない(MUST)。 2.2.3. RFC3090に対する変更 DSレコードに対応するために、RFC3090の幾つかのセクションを更新する 必要がある。 2.2.3.1. RFC3090: セクション1「はじめに」の更新 ほとんどの記述は適切であるが、"NULL鍵"という語は"DS RRセットの不在"に 置き換えられる。セクション1.3の最後の3つの段落は、上記でセクション2.2.1に 置き換えられたRFC2535の幾つかのセクションの混乱について論じている。 したがって、これらの段落はもはや廃止とする。 Gudmundsson Standards Track [Page 9] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 2.2.3.2. RFC3090のセクション2.1: 大域的に安全な状態(Globally Secured) ルール2.1bは以下のルールと置き換えられる。 2.1.b. ゾーンの頂点に存在するKEY RRセットは秘密鍵によって自己署名 されなければならない(MUST)。また、その秘密鍵に対応する公開鍵は、 ゾーンの頂点に所有されるゾーン署名KEY RR (2.a)内に存在しなければ ならず(MUST)、実装必須(mandatory-to-implement)のアルゴリズムを 指定したものでなければならない(MUST)。このKEY RRは親ゾーン内の 署名付DS RRセットに含まれるDS RRによって識別されなければならない(MUST)。 ゾーンが、そのゾーン用のDSレコードを親に広報してもらうことができない 場合、子ゾーンを大域的に安全であると見なすことはできない。唯一の例外は、 親ゾーンを持たないルートゾーンである。 2.2.3.3. RFC3090のセクション3: 実験的状態(Experimental Status) 実験的状態と大域的に安全な状態の唯一の違いは、親ゾーンに DS RRセットが欠落していることだけである。局所的に安全なゾーンは 全て実験的状態である。 2.2.4. NULL KEYの廃止 RFC3445のセクション3はKEY RRのフラグフィールドの先頭2ビットを廃止 している。この先頭2ビットはNULL KEYまたはNO KEYを示すために使用されて いた。RFC3090はゾーンは安全か安全でないかのどちらかであると定義 しており、これらのルールはゾーンがアルゴリズムにとって安全でないことを 示すためにゾーンの頂点にNULL KEYを置く必要性をなくしている。 本文書に加えて、これら2つの文書がNULL KEYの用途を全て廃止している。 以上により、本文書はNULL KEYを廃止する。 2.3. プロトコル変更に関するコメント 多年にわたり、DNS委任モデルに関する様々な議論が行われてきたが、委任が 存在する場合にそれを明示する良い方法が存在しないため、モデルが不十分 であると言われていた。RFC2535の時点でのDNSSECでは、NXTビットマップ内に NSビットが存在すれば、その名前について委任が行われていることが証明される。 安全な委任のためには、さらなる明白さが必要であり、DSレコードは この要求を満たすものである。 DSレコードはDNSに対する大きな変更である。なぜなら、このレコードは 委任の上位側だけに存在することができる最初のリソースレコードだから である。この追加は、相互運用性の問題を発生させ、ある時点でDNSSECの "一斉切り替え(flag day)"が必要となる。DSを適切に利用する ために、多くの古いネームサーバーおよびリゾルバーは更新されなければ ならない(MUST)。ある古いネームサーバーはDSレコードを持つゾーンに 対して権威を持つことは可能だが、権威部にNXTまたはDSレコードを追加する 処理は行わない。再帰検索ネームサーバー(キャッシュサーバー)についても 同じことが言える。実際に、あるものはDSまたはNXTレコードの通過を 拒否する可能性すらある。 Gudmundsson Standards Track [Page 10] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 2.4. DSレコードのワイヤーフォーマット DS(タイプ=43)レコードは以下のフィールドを含む。鍵タグ、アルゴリズム、 ダイジェストタイプ、子の頂点KEY RRセットに署名するために許可または 使用される公開鍵のKEYレコードのダイジェストである。他の鍵が 子の頂点KEY RRセットに署名してもよい(MAY)。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 鍵タグ | アルゴリズム |ダイジェストタイプ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ダイジェスト(長さはタイプに依存) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (SHA-1ダイジェストは20バイト) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 鍵タグはRFC2535で規定されたとおりに計算される。アルゴリズムはDNSデータに 署名することが許可されていなければならない(MUST)。ダイジェストタイプは、 使用されるダイジェストアルゴリズムの識別子である。ダイジェストは 委任されたドメイン名の正規名と、それに続くKEYレコードのRDATA(4フィールド 全て)について計算される。 ダイジェスト = ( KEY RRにおける正規のFQDN | KEY_RR_rdata) KEY_RR_rdata = フラグ | プロトコル | アルゴリズム | 公開鍵 ダイジェストタイプ値0は予約されており、値1はSHA-1である。その他の タイプを予約するためには、IETF標準化活動(*2)が必要である。相互運用上の 理由により、ダイジェストアルゴリズムの数は少ないまま維持することが強く 推奨される(RECOMMENDED)。新たにダイジェストタイプを予約する唯一の理由は セキュリティーの強化だけである。 《脚注》 *2: 「IETF標準化活動(standards action)」 ここでは、標準化過程(standards track)のRFCの発行をさす DSレコードは、DNSデータを認証することを許可されたゾーンKEYレコードを 指していなければならない(MUST)。指し示されたKEYレコードのプロトコル フィールドは3に設定されていなければならない(MUST)。また、フラグ フィールドの7ビット目は1に設定されなければならない(MUST)。 他のフラグビットの値は本文書の目的にとって意味のあるものではない。 タイプ1(SHA-1)のDS RDATAのサイズは鍵サイズに関係なく24バイトである。 新しいダイジェストタイプは、おそらくより大きなダイジェストを持つことに なるだろう。 Gudmundsson Standards Track [Page 11] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 2.4.1. フィールドの正当化 アルゴリズムフィールドと鍵タグフィールドは、リゾルバーが検査すべき KEYレコードの候補を速やかに識別できるようにするために提供される。 SHA-1は強力な暗号チェックサムである。攻撃者が同じSHA-1ダイジェストを 持つKEYレコードを生成することは、計算による方法では不可能である。 鍵の名前と鍵のrdataを組み合わせてダイジェストへの入力とすることに より、鍵の名前と要素のより強い結びつきが保証される。DSレコードが 鍵タグを持つことにより、SHA-1ダイジェストだけの場合よりもはるかに 優れた保証が付加される。2つの異なる変換関数が提供されるからである。 このフォーマットにより、子が使用する鍵の表現を簡潔にできるので、 委任に関する応答のメッセージサイズが小さくなり、DNSメッセージが オーバーフローする可能性が減少する。SHA-1ハッシュは鍵を一意に 識別するために充分な強度があり、PGP鍵のフットプリント(footprint)に 似たものである。ダイジェストタイプフィールドは将来の拡張に備えた ものである。 DSレコードは、設定ファイル内に記述されたセキュリティの島のための 信頼鍵をリストするのに非常に適している。 2.5. DSレコードの表記フォーマット DSレコードの表記フォーマットは3つの数値(鍵タグ、アルゴリズム、 ダイジェストタイプ)と、その後に続く16進数表記のダイジェストから 構成される。 example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890 2.6. 過去の方式を導入した環境の移行に関する問題 RFC2535に対する後方互換性は提供されない。 RFC2535に準拠したリゾルバーは、DSによって安全にされた委任を、全て 局所的に安全であるとみなす。これは好ましくないことだが、DNSEXTワーキング グループは、RFC2535の手法によって安全にされたゾーンとDSによって 安全にされたゾーンの両者を扱うよりは、速やかにDSを導入するほうが 望ましいと判断した。したがって、早期にRFC2535の手法を導入した場合の 唯一の選択肢は、できる限り早くDSによる手法に更新することである。 2.6.1. RFC2535およびRFC1035との後方互換性 本セクションでは、リゾルバーが委任のタイプを決定する手法について 記述する。 Gudmundsson Standards Track [Page 12] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 RFC1035の委任(親側の場合)は以下のとおりである。 RFC 1035 NS RFC2535は以下の2つの場合を追加する。 安全なRFC2535: NS + NXT + SIG(NXT) NXTビットマップの内容: NS SIG NXT 安全でないRFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT) NXTビットマップの内容: NS SIG KEY NXT KEYはNULL鍵でなければならない。 DSに対応したDNSSECは以下の2つの状態を持つ。 安全なDS: NS + DS + SIG(DS) NXTビットマップの内容: NS SIG NXT DS 安全でないDS: NS + NXT + SIG(NXT) NXTビットマップの内容: NS SIG NXT リゾルバーにとって、ある委任が安全なRFC2535か安全でないDSかを 判断することは困難である。この問題は、NXTビットマップにフラグを 追加することによって解決できるかもしれないが、そのフラグを解釈できる のは、いずれにせよ更新されたリゾルバーだけである。1つのKEY RRセットが 親と子の両方の署名を持つことにより、古いリゾルバーにゾーンを 安全であると認識させられるかもしれない。しかし、これを長期に渡って 実施するコストは、単に子の頂点でRFC2535形式の署名を禁止し、DS対応の ネームサーバーとリゾルバーの速やかに普及を強制させるコストよりも はるかに大きくなる。 理論的には、RFC2535とDSは並行して展開することができる。しかし、 そのためにはリゾルバーがRFC2535の設定を永久に扱う必要がある。 本文書では親ゾーンにおけるNULL KEYを廃止するが、これは一斉の変更が 必要なものであり、充分に困難な変更である。 2.7. KEYと対応するDSレコードの例 これはKEYレコードと対応するDSレコードの例である。 dskey.example. KEY 256 3 1 ( AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj 4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt ) ; key id = 28668 DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE Gudmundsson Standards Track [Page 13] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 3. リゾルバー 3.1. DSの例 信頼の連鎖を形成するため、リゾルバーは信頼されたKEYからDS、 DSからKEYへと辿っていく。 ドメイン"example."から取得した鍵は信頼されていると仮定する。 ゾーン"example."は少なくとも以下のレコードを含む。 example. SOA example. NS ns.example. example. KEY <構成要素> example. NXT secure.example. NS SOA KEY SIG NXT example. SIG(SOA) example. SIG(NS) example. SIG(NXT) example. SIG(KEY) secure.example. NS ns1.secure.example. secure.example. DS tag=12345 alg=3 digest_type=1 secure.example. NXT unsecure.example. NS SIG NXT DS secure.example. SIG(NXT) secure.example. SIG(DS) unsecure.example NS ns1.unsecure.example. unsecure.example. NXT example. NS SIG NXT unsecure.example. SIG(NXT) ゾーン"secure.example."には以下のレコードが存在する。 secure.example. SOA secure.example. NS ns1.secure.example. secure.example. KEY secure.example. KEY secure.example. NXT secure.example. SIG(KEY) secure.example. SIG(SOA) secure.example. SIG(NS) secure.example. SIG(NXT) この例では、"example."に関する秘密鍵で"secure.example"に関する DSレコードに署名することにより、委任を安全にしている。 DSレコードは"secure.example."のKEY RRセットに署名することが期待される 鍵を提示する。ここで、"secure.example."はDS RRセット内で識別される KEYで自身のKEY RRセットに署名する。したがって、そのKEY RRセットは 有効であり、信頼される。 この例では子はDSレコードを1つしか持たないが、鍵の更新や複数のKEY アルゴリズムを可能にするために、親は複数のDSレコードを許容しなければ ならない(MUST)。 Gudmundsson Standards Track [Page 14] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 リゾルバーは、"unsecure.example."の安全性を、親ゾーンのこの名前に 対するNXTレコードを検査することによって判断する。DSビットが欠落している ということは、安全でない委任を意味する。NXTレコードは、対応する署名を 検証した後に検査されるべき(SHOULD)ことに注意されたい。 3.2. DSレコードに関するリゾルバーのコスト評価 RFC2535の再帰検索リゾルバーの考え方は、1つの応答を得るために辿る 委任それぞれについて、1つのKEY RRセットが検証されなければならない。 局地的なポリシーによっては、付加的なRRセット(例えばNS RRセットの内容)の 検証が必要な場合がある。一旦リゾルバーが適切な委任に到達した後は、 応答の検証のために1つ以上の署名の検証が必要になるかもしれない。 単純なAレコード検索には、少なくともN個の委任の検証と1つのRRセットが 必要となる。DS対応リゾルバーの場合、このコストは2N+1となる。 MXレコード検索の場合、MXレコードの指し示す先がMXレコードと同じゾーン内に ある場合には、コストはRFC2535の場合N+2で、DSの場合は2N+2となる。 否定応答の場合も同じ割合になる。 再帰検索リゾルバーはDSレコードを取得するために余分な問い合わせを しなければならず、その場合は名前解決の全体的なコストが増大する。 しかし、RFC2535式DNSSECのように、親から得たNULL KEYレコードを 追跡するよりは絶対に悪化しない。 DSはリゾルバーの処理オーバーヘッドを増大させ、委任の応答サイズも 増加させる。しかし、親ゾーンに署名を保存する場合よりははるかに小さい。 4. セキュリティに関する考察 本文書はDNSSECにおけるKEYレコードの検証の連鎖について変更を提案する。 この変更はシステム全体のセキュリティを低下させるものではないと確信する。 RFC2535方式のDNSSECにおいては、子ゾーンは親に鍵を伝達する必要があり、 用心深い親はその処理の際に何らかの認証を要求するだろう。修正後の プロトコルでも同じ認証を必要とするが、子が自身のKEY RRセットに対して 行使する制御の裁量が大きくなる。 攻撃者が全てのDSフィールドまたは固有のDSセットに一致する有効なKEYを 生成し、子から得られるデータを偽造するわずかな可能性が存在する。 しかし、この可能性は非現実的である。一致する鍵を発見するまでに、 平均して 2 ^ (160 - ) の数の鍵を生成しなければならないからである。 Gudmundsson Standards Track [Page 15] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 攻撃者がDSレコードのどれか1つに一致する鍵を見つけたいとした場合でも、 平均して2^80個の鍵を生成しなければならない。 DSレコードはDNSSECプロトコルに対する変更である。一方でDNSSEC実装を 導入したサーバーが存在し、従来の方式で安全な委任を設定する方法について 書かれた教科書も存在する。DSレコードを理解しない実装はKEYからDS、 DSからKEYへの連鎖を辿ることができないため、DS方式で安全にした全ての ゾーンを安全でないとみなすだろう。 5. IANAに関する考察 IANAは標準のRRタイプ空間からDS用のRRタイプコードを割り振った(その タイプは43である)。 IANAはダイジェストアルゴリズム用に、DS RRタイプの新しいレジストリーを 構築した。定義されているタイプは以下のとおりである。 0は予約済 1はSHA-1 新しい予約を行うためには、IETF標準化活動が必要である。 6. 知的所有権に関する表記 IETFは、実装に関する特許の主張や本文書に記述された技術を利用する 他の権利、そのような権利の下で利用可能または利用不可能なライセンスの 範囲について主張される可能性がある知的所有権のあらゆる範囲または 有効性に関して、何ら立場を表明しない。また、そのような権利を識別する ために何らかの努力をしてきたわけでもない。標準化過程と標準化に関連した 文書における権利に関するIETFの手続きについての情報は、BCP-11として 得ることができる。本仕様の実装者または利用者によって行われた作業の 結果として生じた、公開された特許の権利主張のコピー、その権利を 利用可能にするためのあらゆるライセンスの証書、一般的ライセンスまたは 所有権を行使する許可を得ようとする試み等についてはIETF事務局から 得ることができる。 IETFは、あらゆる関係者に対し、あらゆる著作権、特許または特許の実施、 本標準を実践するために必要とされる可能性がある技術をカバーした 所有権等に注目を寄せるよう呼びかける。IETF理事(Executeive Director)に その情報を寄せていただきたい。 Gudmundsson Standards Track [Page 16] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 7. 謝辞 過去数年間にわたり、数多くの人々が本文書に採り入れたアイディアを 提供してくれた。1つの鍵をKEY RRセットに署名するためだけに使用するという 中心的着想は、1つのルート(root)鍵をどのように全てのリゾルバーに 提示するかについての、Bill ManningとPerry Metzgerとの議論から生まれた ものである。Alexis Yushin、Brian Wellington、Sam Weiler、Paul Vixie、 Jakob Schlyter、Scott Rose、Edward Lewis、Lars-Johan Liman、Matt Larson、Mark Kosters、Dan Massey、Olaf Kolman、Phillip Hallam-Baker、 Miek Gieben、Havard Eidnes、Donald Eastlake 3rd.、Randy Bush、David Blacka、Steve Bellovin、Rob Austein、Derek Atkins、Roy Arends、Mark Andrews、Harald Alvestrand、および他の人々は有用なコメントを提供して くれた。 8. 参考文献 8.1. 必須の参考文献 [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. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) Signing Authority", RFC 3008, November 2000. [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone Status", RFC 3090, March 2001. [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001. [RFC3445] Massey, D. and S. Rose, "Limiting the scope of the KEY Resource Record (RR)", RFC 3445, December 2002. 8.2. 有用な参考文献 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001. Gudmundsson Standards Track [Page 17] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 9. 著者の連絡先 Olafur Gudmundsson 3821 Village Park Drive Chevy Chase, MD, 20815 EMail: ds-rfc@ogud.com Gudmundsson Standards Track [Page 18] RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 10. 完全な著作権表示 Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 謝辞 RFCエディターの活動に対する資金は現在Internet Societyによって 提供されている。 Gudmundsson Standards Track [Page 19] RFC3658-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Service Co., Ltd. http://jprs.jp/tech/