ネットワークワーキンググループ B. Wellington Request for Comments: 3007 Nominum 更新: 2535, 2136 2000年11月 廃止: 2137  分類: 標準化過程   セキュアドメインネームシステム(DNS)の動的更新 この文書の位置づけ この文書は、インターネットコミュニティのためにインターネット標準化過程プロ トコルを規定するとともに、改善のための議論や提案を求めるものである。このプ ロトコルの標準化の段階と状態については、「Internet Official Protocol Standards」(STD 1)の最新版を参照されたい。この文書の配布は制限されない。 著作権表示 Copyright (C) The Internet Society (2000). All Rights Reserved. 要約 この文書では、セキュアドメインネームシステム(DNS)の動的更新の実行方法を提 案する。ここに記述された方法は、柔軟性と実用性が高く、プロトコルへの変更が できるだけ少なくてすむように考案された。動的更新メッセージの認証は、その後 のデータのDNSSEC検査とは区別される。認証済みの要求とトランザクションとに基 づく安全な通信を使用して、認可が行われる。 この文書で使用されるキーワード「しなければならない(MUST)」、「してはならな い(MUST NOT)」、「要求されている(REQUIRED)」、「するものとする(SHALL)」、 「しないものとする(SHALL NOT)」、「するほうがよい(SHOULD)」、「しないほう がよい(SHOULD NOT)」、「推奨される(RECOMMENDED)」、「してもよい(MAY)」、「 選択できる(OPTIONAL)」は、[RFC2119]の記述にしたがい解釈される。 1. はじめに この文書では、権限を与えられたソースだけがゾーンの内容を変更できるように、 ドメインネームシステム(DNS)の動的更新を保護する手段を定義する。この研究の 基礎となったのは、既存の保護されていない動的更新操作である。 DNSシステム[RFC1034、RFC1035]と動的更新[RFC2136]に精通しているとこの文書の 理解に役立ち、これがこの文書では前提とされている。その他に、DNSセキュリテ ィ拡張[RFC2535]、SIG(0)トランザクションセキュリティ[RFC2535、RFC2931]、 TSIGトランザクションセキュリティ[RFC2845]に関する知識も推奨される。 Wellington Standards Track [Page 1] RFC 3007 Secure Dynamic Update November 2000 この文書は、RFC 2535の一部(特にセクション3.1.2)とRFC 2136の一部を更新する ものである。この文書の公表により、安全な動的更新に関する別の提案であるRFC 2137は、実装経験の理由から廃止される。 1.1 - DNS動的更新の概要 DNS動的更新は、新しいDNS演算コードと、その演算コードが使用される場合のDNS メッセージの新しい解釈とを定義する。更新は、データの挿入や削除を、更新の 発生に必要な前提条件とともに指定することができる。DNS更新要求に対するテス トと変更はすべて、ゾーン1つだけに制限され、そのゾーン用のプライマリサーバ で実行される。動的ゾーン用のプライマリサーバは、更新が発生する際またはSOA が次に検索される前に、そのゾーンのSOAシリアル番号をインクリメントしなけれ ばならない。 1.2 - DNSトランザクションセキュリティの概要 TSIG [RFC2845]レコードかSIG(0) [RFC2535、RFC2931]レコードを含むDNSメッセ ージの交換により、2つのDNSエンティティは、それらの間でやり取りされるDNS要 求と応答を認証できるようになる。TSIG MAC (メッセージ認証コード)は共有秘密 鍵から生成され、SIG(0)は、対応する公開鍵がDNSに保存されるプライベート鍵か ら生成される。どちらの場合も、メッセージの署名/MACを含むレコードが、最後の リソースレコードとしてDNSメッセージに追加される。TSIGに使用される鍵付きハ ッシュは、計算と検証に費用がかからない。SIG(0)に使用される公開鍵暗号化は、 公開鍵がDNSに保存されるため、スケーラビリティが高い。 1.3 - データ認証とメッセージ認証の比較 TSIGかSIG(0)を使用したメッセージに基づく認証は、1回の署名と1回の検証でメッ セージ全体を保護でき、TSIGの場合、これは比較的費用がかからないMACの生成と チェックである。更新要求については、この署名は、ポリシーか鍵のネゴシエー ションに基づいて、要求を出す権限を確立できる。 DNSSEC SIGレコードを使用すると、DNSメッセージ中の個々のRRやRRsetの完全性を ゾーンの所有者の権限で保護できる。しかし、これによって動的更新要求を十分に 保護することはできない。 SIGレコードを使用して更新要求中のRRsetを保護することは、後述するように更新 のデザインとの整合性がなく、いかなる場合にも、費用がかかる公開鍵署名と検証 を複数回行うことが必要になるだろう。 Wellington Standards Track [Page 2] RFC 3007 Secure Dynamic Update November 2000 SIGレコードは、レコードカウントを含むメッセージヘッダをカバーしない。した がって、悪意をもって更新要求中にRRsetを挿入したり更新要求中のRRsetを削除し たりしても、検証が失敗しないようにすることが、可能である。 SIGレコードを使用して前提条件部を保護したとしても、そのSIG自体が前提条件な のか、それともそのSIGは検査のためだけに使用されているのかを判別することは 不可能だろう。 更新要求の更新部で、RRset追加の要求に署名することは簡単であり、[RFC2535]に 明記されているように、この署名はそのデータの保護に永続的に使用することがで きるだろう。しかし、RRsetが削除された場合は、SIGがカバーすべきデータはなく なる。 1.4 - データとメッセージの署名 [RFC3008]に明記されているように、リゾルバが実行するDNSSEC検査プロセスは、 ローカルポリシーに規定されている場合以外は、どんな非ゾーン鍵も処理しては ならない。安全な動的更新を実行する際は、署名されたゾーン内で変更されたゾ ーンデータはすべて、関連するゾーン鍵で署名されなければならない。これによ って、更新要求の認証とデータ自体の認証は完全に分離される。 DNSSECに関しホスト鍵とユーザー鍵が最も役に立つのは、動的更新を含むメッセー ジを認証する点である。したがって、ホスト鍵とユーザー鍵は、更新を認証するた めのSIG(0)レコードの生成に使用してもよいし、TSIG共有秘密鍵の生成のために TKEY [RFC2930]中で使用してもよい。どちらの場合にも、ローカルポリシーに規定 されている場合以外は、非ゾーン鍵によって生成されるSIGレコードがDNSSEC検査 プロセスに使用されることはない。 データの認証は、それがDNS中に存在する場合には、DNSSECゾーン鍵と、DNSSECゾ ーン鍵によって生成された署名だけが関与する。 1.5 - 署名組織(signatory)の強度 [RFC2535のセクション3.1.2]は、鍵の署名組織フィールドをフラグフィールドの最 後の4ビットと定義しているが、その値は定義していない。この提案は、このフィー ルドを未定義のままにする。[RFC2535]を更新した点は、このフィールドをKEYレコ ード中で0にセットするほうがよいことと、無視しなければならないことである。 2 - 認証 TSIGレコードかSIG(0)レコードを、安全な動的更新メッセージのすべてに含めなけ ればならない。こうすれば、サーバはメッセージの発信者を検証可能な方法で決定 できるようになる。メッセージがSIG(0)の形式の認証を含む場合は、送信者(すな わちプリンシパル)の身元は、そのSIG(0)を生成したKEY RRの所有者である。メッ セージが、静的に設定された共有秘密鍵によって生成されたTSIGを含む場合は、プ リンシパルは共有秘密鍵名と同じか、共有秘密鍵名から生成される。 Wellington Standards Track [Page 3] RFC 3007 Secure Dynamic Update November 2000 メッセージが、動的に設定された共有秘密鍵によって生成されたTSIGを含む場合 は、プリンシパルはTKEYプロセスを認証したものと同じである。TKEYプロセスが認 証されなかった場合は、プリンシパルに関する情報は何も分からず、関連するTSIG 共有秘密鍵を安全な動的更新に使用してはならない。 トランザクションを開始するのはホストかユーザーであってゾーンではないため、 SIG(0)署名はゾーン鍵によって生成しないほうがよい。 DNSSEC SIGレコード(SIG(0)以外)は更新メッセージに含めてもよいが、更新要求の 認証に使用してはならない。 認証されていない鍵によって署名されたために更新が失敗した場合は、サーバは RCODE REFUSEDと一緒にメッセージを返して失敗を知らせなければならない。他の TSIGエラーやSIG(0)エラー、動的更新エラーは、該当するプロトコルに明記されて いるように返される。 3 - ポリシー どのポリシーもゾーンの管理者によって設定され、ゾーンのプライマリネームサー バによって実施される。ポリシーは、認証されたプリンシパルが実行できる認可さ れたアクションを規定する。ポリシーチェックは、プリンシパルと必要なアクショ ンとに基づいて実施され、プリンシパルはメッセージ署名鍵(message signing key) から生成され、その鍵で署名された動的更新メッセージに適用される。 サーバのポリシーが定義する判断基準によって、要求された更新を実行すること を、更新に署名する際に使用された鍵に許可するかが決定される。デフォルトで は、ゾーンデータを変更する許可をプリンシパルに与えてはならない。どんな許可 も、設定を通して与えなければならない。 いくつかの理由から、ポリシーはプライマリゾーンサーバの設定に完全に実装され る。一つは、これにより、ポリシーを符号化して固定長のフィールド(たとえば、 KEY RRの署名組織フィールド)に入れることによって課される制約がなくなること である。ポリシーはそれを適用するサーバの内部でだけ意味があるため、ポリシー を公開する理由がないこともある。最後は、ポリシーの変更や新しいタイプのポリ シーの使用によって、DNSプロトコルやデータフォーマットが影響を受けたり、イ ンターオペラビリティに障害が発生したりしないほうがよいことである。 3.1 - 標準ポリシー 実装は、プリンシパルを認可トークンとして使用することをアクセス制御に許可す るほうがよく、また、プリンシパルにかかわらず署名付きメッセージにパーミッシ ョンを与えることをポリシーに許可してもよい。 Wellington Standards Track [Page 4] RFC 3007 Secure Dynamic Update November 2000 一般に行われるのは、プリンシパルのパーミッションをドメイン名ごとに制限する ことだろう。すなわち、1つ以上のドメイン名に対応するエントリを追加したり削 除したり変更したりすることをプリンシパルに許可することができるだろう。実装 は、名前ごとのアクセス制御を許可するほうがよく、また、プリンシパルの所有者 名とそのサブドメイン、ゾーン内のすべての名前を簡潔に表現するほうがよい。 さらに、プリンシパルが特定の名前のところで特定のレコードタイプを追加したり 削除したり変更したりできるように、サーバはRRのタイプ別に更新を制限可能にす るほうがよい。実装は、タイプごとのアクセス制御を許可するほうがよく、また、 すべてのタイプとすべての「ユーザー」タイプを簡潔に表現するほうがよい。ここ で、ユーザータイプは、DNS自体の動作には影響しないものとして定義される。 3.1.1 - ユーザータイプ ユーザータイプは、SOA、NS、SIG、NXT以外のすべてのデータタイプを含む。SOAと NSタイプは、委譲点を作成したり変更したりするため、通常のユーザーはこれらの タイプのレコードを変更しないほうがよい。SIGレコードを追加すると攻撃を招く 可能性があり、その結果、余分な作業負荷がリゾルバに加わる。また、SIGレコー ドを削除すると、ゾーンのSIGが削除された場合には、サーバに余分な作業を強い る結果になることがある。注意を要する点は、これらのレコードは禁止されてはい ないが、通常のユーザーには推奨されないことである。 NXTレコードを更新するとプロトコルが不安定になることがあるため、NXTレコード を動的更新によって作成したり変更したり削除したりしてはならない。これは、RF C 2136に対する更新である。 KEYレコードの更新に関する問題は、「セキュリティに関する検討」のセクション で議論する。 3.2 - その他のポリシー ユーザーは、どんなポリシーでも自由に実装できる。ポリシーは、その必要性によ って特殊なものであってもよいし一般的なものであってもよい。また、複雑度もそ の必要性によって変わる。ポリシーは、署名されたメッセージのプリンシパルやそ の他の特性に依存することがある。 4 - DNSSECとのインタラクション このプロトコルはゾーンを保護するための更新を処理する方法を変えるものではな いが、明確にすべき問題がいくつかある。 Wellington Standards Track [Page 5] RFC 3007 Secure Dynamic Update November 2000 4.1 - SIGの追加 認可された更新要求は、各RRsetを持つSIGレコードを含んでもよい。SIGレコード (SIG(0)レコード以外)は、更新メッセージの認証に使用してはならないため、必要 とされない。 SIGレコードを更新する権限がプリンシパルに与えられている場合に、更新中にSIG レコードがある場合は、それらのSIGレコードは検証なしに追加される。サーバは SIGレコードを検査して、有効期間を過ぎたSIGを廃棄してもよい。 4.2 - SIGの削除 SIGレコードを更新する権限がプリンシパルに与えられている場合に、更新がSIGレ コードの削除を指定する場合は、サーバは権限を無効にすることを選択してその更 新を拒否してもよい。たとえば、サーバは、ゾーン鍵によって生成されていない SIGレコードをすべて削除することを許可してもよい。 4.3 - SIGに対する非明示的更新 更新されたゾーンが保護されている場合、更新操作の影響を受けるRRsetに、更新 の終了時に、そのゾーンの署名ポリシーにしたがって署名しなければならない。こ れには、プライベート要素がオンラインでなければならない1つ以上のゾーン鍵に よって、1つ以上のSIGレコードを生成することが、通常は必要になる[RFC3008]。 RRsetの内容が更新されると、関連するSIGレコードは有効でなくなるため、サーバ はこれらのレコードをすべて削除してもよい。 4.4 - ゾーンへの影響 変更が行われる場合、サーバは必要なら新しいSOAレコードと新しいNXTレコードを 生成して、適切なゾーン鍵でこれらに署名しなければならない。安全な動的更新に よるNXTレコードへの変更は、明示的に禁止されている。SOAパラメータの維持は DNSプロトコルの範囲外であるため、SOA更新は許可される。 5 - セキュリティに関する検討 この文書は、ゾーン鍵や他の暗号秘密鍵情報(cryptographic secret material)を オンライン状態のネットワーク接続されたホスト(たいていはネームサーバ)に置く ことを要求する。この情報が秘密鍵であり続けるかは、ホストのセキュリティに左 右される。この秘密鍵を公開すると、DNSデータがなりすまし攻撃を受ける危険が ある。攻撃を受ける危険があるのは、マシンのサービスを受けるゾーンにあるデー タと、このマシンから委譲されたゾーンにあるデータである。 Wellington Standards Track [Page 6] RFC 3007 Secure Dynamic Update November 2000 KEYレコードの更新を許可すると、望ましくない結果になることがある。プライベ ート鍵を持たずに公開鍵を挿入する権限が、プリンシパルに与えられていることが あるためで、鍵の所有者になりすますことも考えられる。 6 - 謝辞 著書は、レビューや有益なコメントを提供してくださった次の方々(アルファベッ ト順)に感謝の意を表する。 Harald Alvestrand Donald Eastlake Olafur Gudmundsson Andreas Gustafsson Bob Halley Stuart Kwan Ed Lewis 7 - 参考文献 [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. [RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System", RFC 2136, April 1997. [RFC2137] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997. [RFC2535] Eastlake, G., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Signatures for DNS (TSIG)", RFC 2845, May 2000. [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s)", RFC 2931, September 2000. [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) Signing Authority", RFC 3008, November 2000. Wellington Standards Track [Page 7] RFC 3007 Secure Dynamic Update November 2000 8 - 著者の連絡先 Brian Wellington Nominum, Inc. 950 Charter Street Redwood City, CA 94063 Phone: +1 650 381 6022 EMail: Brian.Wellington@nominum.com Wellington Standards Track [Page 8] RFC 3007 Secure Dynamic Update November 2000 9 - 著作権表示の全文 Copyright (C) The Internet Society (2000). 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 assigns. 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によって提 供されている。 Wellington Standards Track [Page 9] RFC3007-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Service Co., Ltd. http://jprs.jp/tech/