[要約] RFC 3901は、DNSのIPv6トランスポートに関するガイドラインであり、IPv6を使用したDNSトランスポートの運用に関する指針を提供します。このRFCの目的は、IPv6を使用したDNSトランスポートの運用におけるベストプラクティスを示し、インターネット上のIPv6ネットワークのパフォーマンスと信頼性を向上させることです。
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).
著作権（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を操作するためのガイドラインと最良の実践を提供します。
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を使用して別のノードに関する情報をクエリするリゾルバーは、解像度プロセス中にアクセスするサーバーのチェーンのどこかで、1つ以上のセルバーが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.
すべてのDNSデータがIPv4トランスポートでのみ利用可能で、すべてが簡単です。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.
すべてのDNSデータがIPv6トランスポートでのみ利用可能な場合、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またはその両方でのみ利用可能かどうかに応じて、3つのカテゴリのDNSデータがあります。
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 Name Server」というフレーズは、IPv4 Transportで利用可能な名前サーバーを示します。DNS [1,2]データが提供されるものについては何も意味しません。同様に、「IPv6 [4,5,6] Name Server」は、IPv6トランスポートで利用可能な名前サーバーを示します。「デュアルスタック名サーバー」というフレーズは、両方のプロトコル、IPv4、IPv6の両方を実行するように実際に構成されている名前のサーバーを示します。また、両方を実行できるシステムで実行しているサーバーだけでなく、実際には1つのみを実行するように構成されているサーバーを示します。
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.
次のセクションで説明するように、名前空間の継続性を維持するための推奨アプローチは、管理ポリシーを使用することです。
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.
これは、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アドレスレコードがあることを確認する必要があります。
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.
このドキュメントは、2001年以降、IETFおよび他の場所でDNSコミュニティで発生した多くの会話の結果です。その期間中、問題のさまざまな側面を明確にするために多くのインターネットドラフトが公開されています。このドキュメントは、これらの議論の結論に焦点を当てています。
The authors would like to acknowledge the role of Pekka Savola in his thorough review of the document.
著者は、文書の徹底的なレビューにおいて、Pekka 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] Bradner、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] Deering、S。and 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。and S. Deering、「インターネットプロトコルバージョン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] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「IPバージョン6をサポートするDNS拡張」、RFC 3596、2003年10月。
Alain Durand SUN Microsystems, Inc 17 Network circle UMPK17-202 Menlo Park, CA, 94025 USA
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
Johan Ihren Autonomica Bellmansgatan 30 Se-118 47 Stockholm Sweden
EMail: johani@autonomica.se
Copyright (C) The Internet Society (2004).
著作権（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.
この文書は、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.
このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
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エディター機能の資金は現在、インターネット協会によって提供されています。