ネットワークワーキンググループ T. Hardie Request for Comments: 3258 Nominum, Inc. 分類: 情報提供 2002年4月 ユニキャストアドレスの共有による権威ネームサーバーの分配 本文書の位置づけ 本文書はインターネットコミュニティに対して情報を提供するものである。 本文書はいかなる種類のインターネット標準も規定していない。本文書の 配布は制限されない。 著作権表示 Copyright (C) The Internet Society (2002). All Rights Reserved. 要旨 本文書は、権威ネームサーバーの運用者(operator)が、複数の場所に設置 された、同じ名前を持つ単一の権威サーバーへのアクセスを提供可能にする 幾つかの方法について記述する。この手法を開発、展開する主な動機付けは、 ネットワークトポロジー的にDomain Name System (DNS) サーバーが 不十分な領域にサーバーの分配を増やすこと、およびその領域における DNSの問い合わせに対する応答待ち時間を減らすことである。 1. はじめに 本文書は、権威ネームサーバーの運用者が、複数の場所に設置された、 同じ名前を持つ単一の権威サーバーへのアクセスを提供可能にする幾つかの 方法について記述する。この手法を開発し、展開する主な動機付けは、 ネットワークトポロジー的にDNSサーバーが不十分な領域にサーバーの分配を 増やすこと、およびその領域におけるDNSの問い合わせに対する応答待ち時間を 減らすことである。本文書では、ある固有な名前を持つ権威サーバーと、 そのサーバーを管理する組織または個人(オペレーター)の間に1:1の対応が 成り立つことを前提としている。本文書は再帰検索ネームサーバー(キャッシュ サーバー)に関しては、ガイドラインも推奨も含まない。ここで記述される 共有ユニキャスト(shared unicast)システムは、IPv4に限定される。 IPv6への適用は今後の研究課題である。また、ここで記述されるシステムは [ANYCAST]で記述されるものと関係があるが、[ANYCAST]で書かれている 専用のアドレス空間確保、ルーティングの変更または完全なエニイキャスト インフラストラクチャーを構成する他の要素は必要としないことに注意 すべきである。 Hardie Informational [Page 1] RFC 3258 Distributing Authoritative Name Servers April 2002 2. アーキテクチャー 2.1 サーバーの要件 権威ネームサーバーの運用者は、権威ネームサーバーを適切に運用する 一般的なガイダンスとして、[SECONDARY]と[ROOT]を参照するだろう。 共有ユニキャストシステムに参加する各ホストは、標準的な権威ネーム サーバーとしての設定に加えて、2つのネットワークインターフェースを 持つように設定されるべきである。この2つのインターフェースは、物理的な 2つのインターフェースであってもよいし、1つの物理インターフェース上に 論理インターフェースを2つ設定したものであってもよい。2つのインター フェースのうちの1つは権威ネームサーバーに割り当てられたIPv4共有 ユニキャストアドレスを使用するべきである。もう1つのインターフェース (以後管理(administrative)インターフェースと呼ぶ)は、そのホスト固有の 別なIPv4アドレスを使用するべきである。ホストは共有ユニキャスト インターフェースに対して送信されたDNS問い合わせに対してだけ応答すべき である。エニイキャストホストのグループから返される応答群に一貫性を 持たせるために、そのインターフェースからの応答をホストが権威を持つ ゾーンに制限することは良い方法である。 2.2 ゾーンファイルの配送 man-in-the-middle攻撃のリスクを最小限にするために、ゾーンファイルは エニイキャストグループに参加しているサーバーの管理インターフェースに 配送されるべきである。安全なファイル転送方法と強力な認証が全ての転送に 対して使用されるべきである。エニイキャストグループ内のホストが保有する ゾーンを転送可能にする場合、管理インターフェースをゾーン転送のために 使用すべきである。これはセクション2.5で説明するTCPトラフィックの ルーティング変更に関する潜在的な問題を回避するためである。 2.3 同期 権威ネームサーバーは、運用組織によって設定される方法に応じて 緩やかに(loose)または厳密に(tight)同期する。後のセクション4.1.2で 記述するように、同じ共有ユニキャストアドレスを使用するサーバー間の 同期が不十分な場合、サービスを利用するユーザーに問題が生じる可能性が ある。このリスクを最小限にするために、あるデータセットから他の データセットへの切り替えは可能な限り整合が取られるべきである。 参加ホストが同期されたクロックを使用し、切り替え時刻を設定することに より、基本的なレベルの整合性が得られる。より完全な整合処理は以下を 必要とする。 a) 分配元ホストにおけるゾーンの受信 b) 受信したゾーンの完全性確認 c) エニイキャストグループ内にある全サーバーに対するゾーン分配 d) 各サーバーにおけるゾーンの完全性確認 Hardie Informational [Page 2] RFC 3258 Distributing Authoritative Name Servers April 2002 e) エニイキャストグループ内のサーバがデータを切り替える時刻の 整合を取る f) 正しいデータを受信しなかったか、新しいデータへの切り替えが できなかったサーバーが問題が解決されるまで問い合わせへの応答を 中断することを保証する処理失敗時のルール制定 エニイキャストグループのサイズによっては、分配元ホストはグループの 参加者であってもよい。つまり、権威サーバにとって、分配元ホストが ゾーン生成ホストであってもよい。 本文書では、通常のDNSフェイルオーバー手法(*1)がクライアントのデータの 到達性を保証するために使用される唯一の方法であると仮定する。 エニイキャストグループを利用してサーバーを分配している状況で障害が 発生した場合、本文書ではサーバーへの経路を消去するのではなく、代わりに DNSプロセスを停止し、他のアドレスを持つサーバーに問い合わせがなされる ようにすることを推奨する。この推奨はパフォーマンスとオペレーションの 複雑さの間における選択を反映したものである。 あるサーバー実体(server instance)が利用不能になった場合に、 そのサーバーへの経路を消去する処理は可能であると思われるが、 それが確実に実行されることを保証するためには相当に複雑な運用を 必要とする。既存のDNSフェイルオーバー手法に対してわずかな パフォーマンス改善しか得られないのであれば、フェイルオーバー手法を 使用するほとんどの場合に複雑さが追加されることを正当化するには 不十分である。 《脚注》 *1: 「通常のDNSフェイルオーバー手法」 それぞれ異なるIPアドレスを持つマスターサーバーとスレーブサーバーを 用意することにより、1台のサーバーが機能停止した場合においても DNSの仕組みを継続的に提供することを指す。DNSクライアントは、 問い合わせを行ったDNSサーバーから一定時間内に応答が得られなければ 別のDNSサーバーにあらためて問い合わせを行い、応答を得ようとする。 2.4 サーバーの配置 サーバー設置時に地理的な多様化を図ることは、局所的な問題による サービス中断を減らす効果があるが、この分配方式の推進力となって いるのはネットワークトポロジー的に多様化を図ることである。 サーバーの配置に際しては、このネットワークトポロジー的多様性を重要視 すべきである。理想的には、ネットワーク運用者が経路とトラフィックを他の ネットワークと交換しているポイント(*2)にトポロジー的に近い場所に サーバーを配置すべきである。 《脚注》 *2: 「経路とトラフィックを他のネットワークと交換しているポイント」 ISPのような1つの管理組織によって管理運用される独立したネットワークが 他の独立したネットワークと相互接続し、経路情報と顧客トラフィックを 交換する場所。ネットワーク同士が個別に相互接続する場合(プライベート ピアリングと呼ばれる)と、相互接続点(IX: Internet eXchange point)に おいて相互接続する場合、それらを混在する場合等が存在する。 2.5 ルーティング(*3) 《脚注》 *3: 「ルーティング」 本セクションはルーティングの基本的な概念および、ルーティング プロトコルの1つであるBGPに関する知識を必要とする。これらの情報に ついては、関連書籍またはRFCを参照のこと ユニキャストアドレスを共有するサーバーグループを管理する組織は、 AS番号を持ち、相互接続先に対してBGPを使用しなければならない。 これらの相互接続先に対し、組織はネームサーバーの共有ユニキャスト アドレスを含むネットワークへの経路を広報する。組織のボーダー ルーターは、ネームサーバーに向かうトラフィックを最寄のサーバーに 配送しなければならない。サーバーの管理インタフェースへのルーティングに ついては、管理組織は通常のルーティング手法を使用することができる。 共有ユニキャストアドレスを使用する場合の潜在的な問題として、共有 ユニキャストアドレスにトラフィックを転送するルーターが、それぞれ 異なる共有ユニキャストアドレス実体に到達する複数の有効な経路を持つ というものが考えられる。 Hardie Informational [Page 3] RFC 3258 Distributing Authoritative Name Servers April 2002 DNSのようなアプリケーション、つまり通信が典型的には独立した 要求メッセージと応答メッセージによって構成され、それぞれのメッセージは 単一のUDPパケットに入れられる場合は問題は発生しない。 他のアプリケーションで、複数のパケットが同じエンドポイントに 到達しなければならないようなもの(例えばTCP)は、ある状況下では 機能しない(fail)か、役に立たないほどのパフォーマンスになるかも しれない。送信先が別になる事象(split-destination failure)は、 ルーターが複数の等価なメトリックを持つエニイキャスト送信先に対して パケット単位の(またはラウンドロビン式の)負荷分散を行っている 場合や、同じエニイキャスト送信先に向かう2つのパスの相対的メトリックが 変化する場合などに発生し得る。 4つの事柄が、この問題の重大さを緩和する。1つめは、ネームサーバーへの 問い合わせトラフィックのかなりの割合を占めるのはUDPということである。 2つめは、本提案の意図はトポロジカルな配置の多様化にあることである。 つまり、サーバー設置の整合を取るということは、新しいネームサーバー実体は ほとんどのユーザーにとって既設のネームサーバー実体群とは明らかに異なる メトリックの場所に設置されることを保証するのである。 あるユーザーは新設の実体および既設の実体の真ん中になるかもしれないが、 そのような事例は相対的にまれであろう。3つめは、パケット単位の負荷分散の 仕組みは、考えられる負荷分散の仕組みのうちのたった1つの方法にすぎない ということである。他の仕組みの方がより一般的になってきている。 最後に、トラフィックがTCPであり、パケット単位の負荷分散が行われており、 ネームサーバーの異なる実体に向かう等コストの経路が利用可能である ような場合、サーバーのパフォーマンスを測定してサーバーを選択する DNS実装は全て、問題が起きないサーバーを迅速に選択する。 しかし、DNSのフェイルオーバーの仕組みが確実にこの問題を回避するために、 共有ユニキャストアドレスを利用したサーバー分配の仕組みを使用する場合、 ある特定のゾーンを保持するサーバー全てが同じ共有ユニキャストグループに 参加しないように注意しなければならない。複数の共有ユニキャストグループが それぞれ等コストの経路に沿ったパケット単位の負荷分散によって影響を受ける ユーザーの集合を持つ場合の防御策として、本手法を実装する組織は常に 最低1つは共有ユニキャストグループに参加していない権威サーバーを 提供するべきである。また、共有ユニキャストグループの仕組みを利用して サーバーの展開を行う場合、サーバー障害、パス障害、ある特定ホストまでの 経路消失が発生した場合には、そのホストはクライアントに到達できなくなる 場合があることに注意すべきである。しかし、これらのエラー条件は、 共有ユニキャストを利用して分配されたサーバー固有のものではなく、 標準的なユニキャストホストでも発生し得るものである。 ICMP応答パケットは、パケットを送信したサーバーとは異なるグループの メンバーに行くかもしれないため、共有ユニキャストアドレスを発信元 アドレスとして持つパケットは、パスMTUディスカバリーの使用を避ける べきである。 付録Aはこのシステムをシンプルに実装した例をASCII図として示している。 そこでは、奇数番号のルーターは共有ユニキャストインターフェース ネットワークへのトラフィックを配送しており、管理ネットワークからの トラフィックをフィルターしている。また、偶数番号のルーターは管理 ネットワークへのトラフィックを配送し、共有ユニキャストネットワーク からのトラフィックをフィルターしている。 Hardie Informational [Page 4] RFC 3258 Distributing Authoritative Name Servers April 2002 これらは説明を簡単にするために異なるルーターとして表現されて いるが、これは同じルーターの独立したインターフェースであっても よい。同様に、ルーターと同一の場所に設置されたNTP(*4)ソースは同期の ために記述されているが、必要とされる同期のレベルによっては、現地に 設置されたNTPサーバーの参照または遠隔に設置されたNTP stratum 1サーバーの 参照のどちらかは不要かもしれない。 《脚注》 *4: 「NTP」 Network Time Protocolの略。ネットワークを通してホストの時刻を正しく 設定する仕組み。ホスト上で動作するNTPクライアントプログラムからNTP サーバーを参照することにより、ホスト上の時刻のずれを修正する。 詳細については関連書籍またはRFCを参照のこと。 3. 管理 3.1 連絡先 このシステムを正しく管理するために重要なことは、問題を報告するための 連絡先を1つにするということである。このシステムの外部ユーザーが サービスに関連する問題の報告をする必要がある場合、連絡先の人間に ついて不明瞭な点があってはならない。内部の監視機構が問題を指摘しない 場合、どのサーバーがエラーを引き起こしているかを識別するために、 連絡を受けた者はその外部ユーザと協調して作業する必要がある。 4. セキュリティに関する考察 インターネットインフラストラクチャーのコア部分であるため、権威 ネームサーバーは攻撃の一般的な対象である。本文書で概説した手法は ある種の攻撃のリスクを増大させ、ある種のリスクを軽減する。 4.1 リスクの増大 4.1.1 物理的サーバー数の増加 本文書で概説したアーキテクチャーは、物理的なサーバー数を増加させる。 これは誤ったサーバー設定がセキュリティー侵害を許してしまう可能性を 増大させる。一般に、エニイキャストグループを管理する組織または個人は、 グループの単一メンバーに適用するパッチ、セキュリティを維持する仕組みが 他のグループメンバー全てにとっても適切であり、また実際に適用される ことを保証するべきである。"出自の多様化(genetic diversity)" (異なるコードベースを出自とするコード)は特定のコードベースに含まれる 脆弱性に基づく攻撃を回避する有用なセキュリティー施策になり得る。 しかし、単一の権威サーバーからの応答の一貫性を保証するために、 異なる共有ユニキャストグループの間か、共有ユニキャストグループと グループに属さないサーバーの間で多様化を図るべきである。 4.1.2 データ同期の問題 先に記述した全体の同期レベルは、各サーバに存在するデータの同期に よって補強されるべきである。 Hardie Informational [Page 5] RFC 3258 Distributing Authoritative Name Servers April 2002 DNSそれ自体は緩やかに結合されたシステムであるため、もし1つの ユニキャストアドレスを共有する2つの異なるサーバーが同じ問い合わせに 対して異なる応答を返すと、特定のゾーンに含まれるデータをデバッグ するという問題はより困難なものになる。例えば、www.example.comに 関連するデータが変更され、ドメイン管理者がexample.comの権威 ネームサーバーでその変更をテストする場合、その権威ネーム サーバーの実体をそれぞれチェックする必要があるようにすべきではない。 NTPの使用は切り替え処理用の同期した時刻を提供するため、この問題の 幾つかの部分は解消するが、切り替え処理中の障害に対処する仕組みは 必要である。特に、切り替えができなかったサーバーは前のバージョンに 戻してはならない。他のサーバー(*5)に問い合わせがなされるよう、 問い合わせへの応答を中断しなければならない。 《脚注》 *5: 「他のサーバー」 ある共有ユニキャストグループで使用するアドレスと異なるアドレスを 持つサーバーまたは別の共有ユニキャストグループを指す。 ある共有ユニキャストグループに属するサーバー実体の中の1台で データの切り替えに失敗した場合、そのサーバーは問い合わせへの 応答を中断する。すると、DNSのフェイルオーバーの仕組みに従って クライアントは別のアドレスを持つDNSサーバーに問い合わせを出す ため、問題は回避される。 4.1.3 ゾーン分配のリスク サーバー群にゾーンファイルを分配するために使用される仕組みが充分に 安全でない場合、man-in-the-middle攻撃により、虚偽の情報が注入される 可能性がある。電子署名はこのリスクを軽減するが、これに加えて暗号化された 通信路と厳格なアクセスリストが必要である。ゾーンファイルはグループ化された サーバーの管理インタフェースに分配されるため、ゾーンファイル分配用の アクセス制御リストにはサーバーまたはサーバー群の共有ユニキャスト アドレスではなく、管理インターフェースが含まれなければならない。 4.2 リスクの軽減 物理的サーバー数の増加により、サービス妨害(DoS: denial-of-service)攻撃が DNSインフラストラクチャーの大部分を破壊する危険性は少なくなる。 サーバー数の増加は、特定のマシンに依存するユーザーの数を減らすので、マシン クラッシュ、ファイバー切断の影響を軽減し、災害を局所化する。 5. 謝辞 以下の人々がこの作業に情報提供、助言および論評をくれた。 Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak, Mark Andrews, Robert Elz, Geoff Huston, Bill Norton, Akira Kato, Suzanne Woolf, Bernard Aboba, Casey Ajalat, Gunnar Lindberg。 著者は故Scott Tuckerの特別な貢献が忘れ去られないことを願う。 彼の広範囲にわたるシステムの経験とプレーンな常識両方が著者自身の 展開経験に多大な貢献をしたし、また彼を知る全ての人が彼がいないのを 寂しく思っている。 Hardie Informational [Page 6] RFC 3258 Distributing Authoritative Name Servers April 2002 6. 参考文献 [SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection and Operation of Secondary DNS Servers", BCP 16, RFC 2182, July 1997. [ROOT] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root Name Server Operational Requirements", BCP 40, RFC 2870, June 2000. [ANYCAST] Patridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. Hardie Informational [Page 7] RFC 3258 Distributing Authoritative Name Servers April 2002 付録A __________________ Peer 1-| | Peer 2-| | Peer 3-| スイッチ | Transit| | ___________ ___________ その他 | |--|ルーター1|---|----|------|ルーター2|---WAN-| | | ----------- | | ----------- | | | | | | | | | | | ------------------ [NTP] [DNS] | | | | | __________________ | Peer 1-| | | Peer 2-| | | Peer 3-| スイッチ | | Transit| | ___________ ___________ | その他 | |--|ルーター3|---|----|------|ルーター4|---WAN-| | | ----------- | | ----------- | | | | | | | | | | | ------------------ [NTP] [DNS] | | | | | __________________ | Peer 1-| | | Peer 2-| | | Peer 3-| スイッチ | | Transit| | ___________ ___________ | その他 | |--|ルーター5|---|----|------|ルーター6|---WAN-| | | ----------- | | ----------- | | | | | | | | | | | ------------------ [NTP] [DNS] | | | | | __________________ | Peer 1-| | | Peer 2-| | | Peer 3-| スイッチ | | Transit| | ___________ ___________ | その他 | |--|ルーター7|---|----|------|ルーター8|---WAN-| | | ----------- | | ----------- | | | | | | | | ------------------ [NTP] [DNS] Hardie Informational [Page 8] RFC 3258 Distributing Authoritative Name Servers April 2002 Hardie Informational [Page 9] RFC 3258 Distributing Authoritative Name Servers April 2002 7. 著者の連絡先 Ted Hardie Nominum, Inc. 2385 Bay Road. Redwood City, CA 94063 Phone: 1.650.381.6226 EMail: Ted.Hardie@nominum.com Hardie Informational [Page 10] RFC 3258 Distributing Authoritative Name Servers April 2002 8. 著作権表示の全文 Copyright (C) The Internet Society (2002). 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によって提供されて いる。 Hardie Informational [Page 11] RFC3258-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Service Co., Ltd. http://jprs.jp/tech/