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
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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（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とIPv6の混合物へのIPv4からすると、インターネットに移動するこの現象が発生し始めるまで、それは時間の問題です。完全なDNSの階層は、特定のノードのための権威ネームサーバは、特定のトランスポート上でのみアクセス可能なグラフに断片化を開始します。懸念はどこかに解決プロセス中にアクセスサーバのチェーンで、そのうちの1つ以上がのみとなりますので、リゾルバ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データではすべてが簡単です。 IPv6のリゾルバは、「翻訳」を介して動作している間のIPv4リゾルバはつまり、彼らは "として、いわゆる「デュアルスタック」ホスト上の再帰ネームサーバーを使用する必要があり、ルートからとダウン以下の紹介の意図したメカニズムを使用することができます彼らは直接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の状況は、近い将来に発生しません。その代わりに、遷移は、DNSデータの3つのカテゴリの情報がIPv6のみまたは両方の上に、IPv4のみのトランスポートを介して利用可能であるかどうかに依存して、IPv4からのみIPv4とIPv6の混合物であろう。
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データのみを長時間v4のトランスポート上で利用可能になることは明らかである一方、しかし、IPv4ホストのみが利用可能な名前空間の断片化を避けることが重要であることも明らかです。たとえば、移行時には、我々は現在、IPv4のみのホストのために利用可能な名前空間を破ることは受け入れられません。
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を実行するように構成されており、単に実際に両方を実行できるが、システム上で実行しているサーバーが一つだけ実行されるように構成されていないネームサーバを示します。
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.
これは以前に断片化されていないIPv4の名前空間を断片化し、それを回避するためのメカニズムを見つけるための強力な理由があるため、これらのゾーンは、IPv6のみのネームサーバによってのみ提供持つことは、良い開発ではありません。
The recommended approach to maintain name space continuity is to use administrative policies, as described in the next section.
次のセクションで説明するように名前空間の連続性を維持するために推奨されるアプローチは、管理ポリシーを使用することです。
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のみの再帰的なサーバを除外する。しかし、一つは実際にそれらの再帰クエリを実行するデュアルスタック再帰ネームサーバーのセットにIPv6のみのネームサーバ前方クエリのチェーン構成を設計することがあります。
- 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.
これは、DNSゾーンがIPv6のみの権威ネームサーバによってのみ提供さ除外する。
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アドレスレコードがあることを確認する必要があります。
The guidelines described in this memo introduce no new security considerations into the DNS protocol or associated operational scenarios.
このメモで説明するガイドラインは、DNSプロトコルや関連する動作シナリオに全く新しいセキュリティの考慮事項を導入しません。
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.
作者は、ドキュメントの彼の徹底的な見直しにペッカSavolaの役割を認識したいと思います。
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[2] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[3]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[4]デアリング、S.とR. Hindenと "インターネットプロトコル、バージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[5] HindenとR.とS.デアリング、 "インターネットプロトコルバージョン6（IPv6）のアドレス指定アーキテクチャ"、RFC 3513、2003年4月。
[6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[6]トムソン、S.、のHuitema、C.、Ksinant、V.、およびM. Souissi、 "DNSの拡張機能IPバージョン6のサポートする"、RFC 3596を、2003年10月。
Alain Durand SUN Microsystems, Inc 17 Network circle UMPK17-202 Menlo Park, CA, 94025 USA
アラン・デュラン米国Sun Microsystems、Inc. 17ネットワーク円UMPK17-202メンロパーク、CA、94025 USA
EMail: Alain.Durand@sun.com
メールアドレス：Alain.Durand@sun.com
Johan Ihren Autonomica Bellmansgatan 30 SE-118 47 Stockholm Sweden
ヨハン・ごAutonomica Bellmansgatan 30 SE-118 47ストックホルムスウェーデン
EMail: johani@autonomica.se
メールアドレス：johani@autonomica.se
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78および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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。