ネットワークワーキンググループ A. Durand RFC: 3901 SUN Microsystems, Inc. BCP: 91 J. Ihren 分類: 現状の最良の方法(Best Current Practice) Autonomica 2004年10月 DNSのIPv6トランスポートに関する運用ガイドライン Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). 要旨 本文書は、IPv4とIPv6のネットワークが混在した環境において、問い合わせと 応答がやりとりされるDNSの運用に関するガイドラインと現状の最良の方法を 提供する。 1. 名前空間の断片化に関する問題の概要: 参照の連鎖の追跡 名前を検索しようと試みるリゾルバーは、ルートから作業を開始し、名前に 対して権威を持つネームサーバーへの参照に到達するまで、参照を追跡して いく。参照の連鎖の途中で、リゾルバーが使用できないトランスポートでしか アクセスできないネームサーバーが参照されている場合、リゾルバーは処理を 完了させることができない。 インターネットはIPv4からIPv4とIPv6の混在環境へと移行しているので、 このような事態が生じるのは時間の問題である。すべての情報がつながって いた完全なDNS階層は、特定のトランスポートでしかアクセスできない 権威ネームサーバーを持つ特定のノードで構成されたグラフへの断片化が 始まっている。懸念されることは、特定のバージョンのIPだけしかサポート しないリゾルバーが、同じバージョンのIPを使用する別ノードに関する 情報の問い合わせができなくなることである。なぜなら、名前解決プロセスの 間に連鎖的にアクセスされるべきサーバーのうち、一つ以上のものが 別バージョンのIPでしかアクセスできなくなるだろうからである。 すべてのDNSデータがIPv4トランスポートでしか利用できない場合、すべてが シンプルである。IPv4リゾルバーは、参照の追跡を行う所定の仕組みを ルートから下方へと使用することができる。 Durand & Ihren Best Current Practice [Page 1] RFC 3901 DNS IPv6 Transport Guidelines September 2004 これに対し、IPv6リゾルバーは、"トランスレーター"を介して動作しなければ ならない。言い換えると、IPv6リゾルバーは、DNSデータに直接アクセス できないため、いわゆる"デュアルスタック"ホスト上で動作する再帰ネーム サーバーを"フォワーダー"として使用しなければならない。 すべてのDNSデータがIPv6トランスポートでしか利用できない場合、同様にすべてが シンプルになるだろう。ただし、IPv4の再帰ネームサーバーは、フォワーダーを 使用する構成に切り替えなければならない。 しかし、予見できる将来において二つ目の状況が生じることはないだろう。 むしろ、IPv4だけの状況からIPv4とIPv6の混在状況へと推移し、DNSデータは、 利用できるトランスポートに応じて、IPv4トランスポートでしか利用できない もの、IPv6トランスポートでしか利用できないもの、両方で利用できるものの 三つに分類されることになるだろう。 両方のトランスポートで利用できるDNSデータを保持することが最善である。 主たる論点は、可能な限り早くそれを標準にすることをどのように保証するか である。しかし、一部のDNSデータが今後も長期に渡ってv4トランスポートで しか利用できないことが明らかである一方で、IPv4しかサポートしないホストに 利用可能な名前空間の断片化の回避が重要なことも明らかである。 例えば、移行期間中に、現時点でIPv4しかサポートしないホストに利用可能な 名前空間が分断されることは容認されない。 2. 用語 "IPv4のネームサーバー"という用語は、IPv4トランスポート上で利用可能な ネームサーバーを指す。この用語は、提供されるDNS[1,2]データが何かに ついては何も意味しない。同様に、"IPv6[4,5,6]のネームサーバー"は、 IPv6トランスポート上で利用可能なネームサーバーを指す。"デュアル スタックのネームサーバー"という用語は、IPv4とIPv6の両プロトコルで 実質的に動作するように設定されたネームサーバーを指す。ただ単に 両プロトコル対応のシステム上で稼働しているが、実質的には単一の プロトコルでしか機能しないように設定されたものは含まない。 3. ポリシーに基づく名前空間断片化の回避 今日、IPv6トランスポート上で利用可能な一般のインターネット上において、 DNSの"ゾーン"はごくわずかしか存在せず、その大半は"実験的"と見なすことが できるものである。しかし、ルートとトップレベルドメインがIPv6トランス ポート上で利用できるようになるとすぐに、IPv6のサーバーに提供される ゾーンを保持することがより一般的になると期待するのは妥当だろう。 IPv6しかサポートしないネームサーバーのみによって提供されるゾーンを 保持することは良い進展ではないだろう。なぜなら、これまで断片化されて いなかったIPv4の名前空間を断片化することになるからであり、それを回避 するための仕組みを見つける強い動機にもなっている。 Durand & Ihren Best Current Practice [Page 2] RFC 3901 DNS IPv6 Transport Guidelines September 2004 名前空間の連続性を維持するための推奨されるアプローチは、次セクションに 記述される管理ポリシーを使用することである。 4. DNSのIPv6トランスポートに関する推奨ガイドライン 名前空間の連続性を維持するために、以下の管理ポリシーが推奨される。 ・各再帰ネームサーバーは、IPv4だけをサポートするか、デュアル スタックかのどちらかにすべき(SHOULD)である。 これにより、IPv6だけをサポートする再帰サーバーを除外する。 しかし、IPv6しかサポートしない一連のネームサーバーが再帰 問い合わせを実際に実行させるために、その再帰問い合わせをデュアル スタックの再帰ネームサーバーに転送するといった構成は設計される かもしれない。 ・各DNSゾーンのゾーン情報を提供する権威ネームサーバーには、少なくとも 1台はIPv4到達性のあるものが含まれるべき(SHOULD)である。 これにより、IPv6しかサポートしない権威ネームサーバーだけで提供 されるDNSゾーンを除外する。 注：ゾーンの妥当性を検証する処理は、そのゾーンに含まれる委任の子側の ネームサーバーに関して、少なくとも一つのIPv4アドレスレコードが利用可能 であることを確認すべき(SHOULD)である。 5. セキュリティに関する考慮点 本文書に記述されるガイドラインは、DNSプロトコルまたは関連する 運用シナリオに対して新たなセキュリティに関する考慮点を何も導入 しない。 6. Acknowledgment This document is the result of many conversations that happened in the DNS community at IETF and elsewhere since 2001. During that period of time, a number of Internet drafts have been published to clarify various aspects of the issues at stake. This document focuses on the conclusion of those discussions. The authors would like to acknowledge the role of Pekka Savola in his thorough review of the document. Durand & Ihren Best Current Practice [Page 3] RFC 3901 DNS IPv6 Transport Guidelines September 2004 7. Normative References [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003. 8. Authors' Addresses Alain Durand SUN Microsystems, Inc 17 Network circle UMPK17-202 Menlo Park, CA, 94025 USA EMail: Alain.Durand@sun.com Johan Ihren Autonomica Bellmansgatan 30 SE-118 47 Stockholm Sweden EMail: johani@autonomica.se Durand & Ihren Best Current Practice [Page 4] RFC 3901 DNS IPv6 Transport Guidelines September 2004 9. Full Copyright Statement Copyright (C) The Internet Society (2004). 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/S HE 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 IETF's procedures with respect to rights in IETF 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. Durand & Ihren Best Current Practice [Page 5]