この文書はRFC3234の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
Network Working Group A. Durand Request for Comments: 3901 SUN Microsystems, Inc. BCP: 91 J. Ihren Category: Best Current Practice Autonomica September 2004 DNS IPv6 Transport Operational Guidelines 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). Abstract 要約 This memo provides guidelines and Best Current Practice for operating DNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. このメモは問合せと応答がIPv4とIPv6ネットワークの入り混ざった 環境に載る世界でDNSを運営することに対するガイドラインと現在最良実 践を供給します。 1. Introduction to the Problem of Name Space Fragmentation: following the referral chain 1. 名前空間分裂の問題への導入:紹介連鎖に従うこと A resolver that tries to look up a name starts out at the root, and follows referrals until it is referred to a name server that is authoritative for the name. If somewhere down the chain of referrals it is referred to a name server that is only accessible over a transport which the resolver cannot use, the resolver is unable to finish the task. 名前を検索しようとするリゾルバがルートから開始し、検索する名前の正式 な名前サーバを知るまで、照会を続けます。もしリゾルバが使うことができ ないトランスポートでだけアクセス可能な名前サーバを参照して、紹介連鎖 が途絶えるなら、リゾルバはタスクを終えることが不可能です。 When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is only a matter of time until this starts to happen. The complete DNS hierarchy then starts to fragment into a graph where authoritative name servers for certain nodes are only accessible over a certain transport. The concern is that a resolver using only a particular version of IP and querying information about another node using the same version of IP can not do it because somewhere in the chain of servers accessed during the resolution process, one or more of them will only be accessible with the other version of IP. インターネットがIPv4からIPv4とIPv6の混合に移行する時、こ れが起き始めるのは時間の問題です。完全なDNS階層は、グラフのノード の正式なネームサーバがあるトランスポート上でアクセス可能な所に分断し 始めます。懸念は特定のIPバージョンを使用するリゾルバと、あるIPバー ジョンを使う他のノードの問合せ情報が、解決処理でアクセスするサーバ連 鎖のいくつかが他のIPバージョンでしか動かないため、動作しない事です。 With all DNS data only available over IPv4 transport everything is simple. IPv4 resolvers can use the intended mechanism of following referrals from the root and down while IPv6 resolvers have to work through a "translator", i.e., they have to use a recursive name server on a so-called "dual stack" host as a "forwarder" since they cannot access the DNS data directly. IPv4トランスポート上ですべてのDNSデータが利用可能な状態はすべ てが単純です。IPv4リゾルバがルートから紹介を伝う意図するメカニズ ムを利用可能ですが、IPv6リゾルバが「翻訳者」を通して働かなければ なりません、つまりDNSデータを直接アクセスできないので、「デュアル スタック」と呼ばれるホストの再帰ネームサーバを転送者に使います。 With all DNS data only available over IPv6 transport everything would be equally simple, with the exception of IPv4 recursive name servers having to switch to a forwarding configuration. IPv6トランスポートでのみ利用可能なDNSデータで、IPv4再帰ネー ムサーバは転送に設定すればいいので、全てが単純です。 However, the second situation will not arise in the foreseeable future. Instead, the transition will be from IPv4 only to a mixture of IPv4 and IPv6, with three categories of DNS data depending on whether the information is available only over IPv4 transport, only over IPv6 or both. しかしながら、2番目の状態は近い将来生じないでしょう。その代わりに、 移行はIPv4だけから、IPv4とIPv6の混合へとなり、IPv4ト ランスポートのみか、IPv6トランスポートのみか、両方かで、DNSデー タの3つのカテゴリが生じるでしょう。 Having DNS data available on both transports is the best situation. The major question is how to ensure that it becomes the norm as quickly as possible. However, while it is obvious that some DNS data will only be available over v4 transport for a long time it is also obvious that it is important to avoid fragmenting the name space available to IPv4 only hosts. For example, during transition it is not acceptable to break the name space that we presently have available for IPv4-only hosts. 両方のトランスポートで利用可能なDNSデータを持つことは最も良い状態 です。主な質問はどのようにそれが可能な限り速く通常になることを保証す るべきかです。しかしながら、あるDNSデータが長期間IPv4上でだけ 利用可能であることが明白で、IPv4のみが利用可能なホストの名前空間 の分断を避けることが重要なのも同じく明白です。例えば、移行の間、現在 IPv4のみのホストに利用可能である名前空間を壊すことは許容できませ ん。 2. Terminology 2. 用語 The phrase "IPv4 name server" indicates a name server available over IPv4 transport. It does not imply anything about what DNS [1,2] data is served. Likewise, "IPv6 [4,5,6] name server" indicates a name server available over IPv6 transport. The phrase "dual-stack name server" indicates a name server that is actually configured to run both protocols, IPv4 and IPv6, and not merely a server running on a system capable of running both but actually configured to run only one. 用語「IPv4ネームサーバ」はIPv4トランスポート上で利用可能なネー ムサーバを示します。それは、どのDNS[1,2]データを供給するかについて は何も暗示しません。同様に、「IPv6[4,5,6]ネームサーバ」がIPv6 トランスポート上で利用可能なネームサーバを示します。用語「デュアルス タックネームサーバ」はIPv4とIPv6の両プロトコルで動作するよう に設定されたネームサーバを示し、単に両方で動作可能なシステム上の一方 だけを動作させているのを示しません。 3. Policy Based Avoidance of Name Space Fragmentation 3. 名前空間分裂のポリシベースの回避 Today there are only a few DNS "zones" on the public Internet that are available over IPv6 transport, and most of them can be regarded as "experimental". However, as soon as the root and top level domains are available over IPv6 transport, it is reasonable to expect that it will become more common to have zones served by IPv6 servers. 今日、IPv6トランスポートで利用可能なDNSの「ゾーン」はほんの少 しだけで、大部分が「実験的」と見なせます。しかしながら、ルートと最上 位ドメインがIPv6トランスポートで利用可能になるとすぐに、IPv6 サーバのサポートするゾーンを持つことがより一般的になると思うことは合 理的です。 Having those zones served only by IPv6-only name server would not be a good development, since this will fragment the previously unfragmented IPv4 name space and there are strong reasons to find a mechanism to avoid it. IPv6のみのネームサーバでサポートされるゾーンを持つことは、これが IPv4名前空間を分解し、これを避けるためにメカニズムを見いだす強い 理由があるので、良い展開ではないでしょう。 The recommended approach to maintain name space continuity is to use administrative policies, as described in the next section. 名前空間連続性を持続する推薦された方法は、次の章で記述されるように、 管理上のポリシを使う事です。 4. DNS IPv6 Transport recommended Guidelines 4. DNSIPv6トランスポート勧告ガイドライン In order to preserve name space continuity, the following administrative policies are recommended: 名前空間連続性を維持するために、次の管理上のポリシが勧められます: - every recursive name server SHOULD be either IPv4-only or dual stack, - すべての再帰ネームサーバは、IPv4のみか、デュアルスタックであ るべきです。 This rules out IPv6-only recursive servers. However, one might design configurations where a chain of IPv6-only name server forward queries to a set of dual stack recursive name server actually performing those recursive queries. これはIPv6のみの再帰サーバを除外します。しかしながら、IPv 6のみのネームサーバが再帰問合せを行うデュアルスタック再帰ネーム サーバにを尋ねる設定を設計するかもしれません。 - every DNS zone SHOULD be served by at least one IPv4-reachable authoritative name server. - すべてのDNSゾーンは少なくとも1つのIPv4到達可能な正式なネー ムサーバによってサポートされるべきです。 This rules out DNS zones served only by IPv6-only authoritative name servers. これはIPv6だけの正式なネームサーバによってだけサポートされ るDNSゾーンを除外します。 Note: zone validation processes SHOULD ensure that there is at least one IPv4 address record available for the name servers of any child delegations within the zone. ノート:ゾーン承認プロセスは、ゾーンの子委任のネームサーバのに、利用 可能な少なくとも1つのIPv4アドレスレコードがあることを保証するべ きです。 5. Security Considerations 5. セキュリティの考察 The guidelines described in this memo introduce no new security considerations into the DNS protocol or associated operational scenarios. このメモで記述されたガイドラインはDNSプロトコルあるいは関連づけら れた運用上のシナリオに新しいセキュリティの考慮を導入しません。 6. Acknowledgment 6. 謝辞 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. この文書はIETFのDNS共同体や他のところで2001年から起きた多 くの会話の結果です。その時期の間に、多くのインターネットドラフトが危 機にある問題の種々な局面を明確にするために出版されました。この文書は それらの論議の結論に焦点を合わせます。 The authors would like to acknowledge the role of Pekka Savola in his thorough review of the document. 著者は文書の徹底的な批評に対してPekka Savolaの役割を認めたいです。 7. Normative References 7. 参照する参考文献 [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 8. 著者のアドレス 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 9. Full Copyright Statement 9. 著作権表示全文 Copyright (C) The Internet Society (2004). 著作権(C)インターネット学会(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. この文書はBCP78に含まれる権利と許可と制限の適用を受け、そして この中に明らかにされる以外は著者がすべての権利を維持します。 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. この文書に記述された実装や技術に関して主張される知的財産権や他の権利の 正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不 可能かの範囲について、IETFは何の立場もとりません;この様な権利を 認識する独立の調査をしたとは述べません。RFC文書の権利に関する手続 きの情報はBCP78とBCP79を見てください。 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. IETF事務局に公開されたIPRの写しと、利用可能な許可証と、仕様書 の実装者や利用者によってされた一般的な許可書や許可を得るためにされた 試みの結果は、http://www.ietf.org/iprにあるIETFオンライン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. IETFは興味を持った誰からでもこの標準を実行するのに必要な技術をカ バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求 めます。どうかietf-ipr@ietf.orgのIETFに情報を伝えてください。 Acknowledgement 謝辞 Funding for the RFC Editor function is currently provided by the Internet Society. RFCエディタ機能のための資金供給が現在インターネット学会によって 供給されます。