RFC3901 日本語訳

Network Working Group                                          A. Durand
Request for Comments: 3901                        SUN Microsystems, Inc.
BCP: 91                                                         J. Ihren
Category: Best Current Practice                               Autonomica
                                                          September 2004

コメントを求めるワーキンググループA.ジュランドの要求をネットワークでつないでください: 3901太陽マイクロシステムズInc.BCP: 91J.Ihrenカテゴリ: 最も良い現在の練習Autonomica2004年9月

               DNS IPv6 Transport Operational Guidelines

DNS IPv6輸送運用指針

Status of this Memo

この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).

Copyright(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を操作するのにガイドラインとBest Current Practiceを提供します。

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階層構造は単にあるノードのための正式のネームサーバが、ある輸送の上でアクセスしやすいグラフに断片化し始めます。 関心はそれらの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

IPv4輸送の上で利用可能なだけのすべてのDNSデータでは、すべてが簡単です。 IPv6レゾルバが働かなければならない間、IPv4レゾルバは根と下であるのから次の紹介の意図しているメカニズムを使用できます。

Durand & Ihren           Best Current Practice                  [Page 1]

RFC 3901             DNS IPv6 Transport Guidelines        September 2004

ジュランドとIhrenの最も良い現在の習慣[1ページ]RFC3901DNS IPv6は2004年9月にガイドラインを輸送します。

   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データにアクセスできないので、「混載業者」としていわゆる「デュアルスタック」ホストの上で再帰的なネームサーバを使用しなければなりません。

   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の混合物までしか変遷がないでしょう、DNSデータの3つのカテゴリが情報が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だけホストに利用可能にする名前スペースを壊すのは許容できません。

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が1つだけを実行するために両方、しかし、実際に構成しました。

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だけネームサーバだけでそれらのゾーンを役立たせているのは、良い開発でないでしょう、これが以前にunfragmented IPv4名義のスペースを断片化して、それを避けるためにメカニズムを見つける強い理由があるので。

Durand & Ihren           Best Current Practice                  [Page 2]

RFC 3901             DNS IPv6 Transport Guidelines        September 2004

ジュランドとIhrenの最も良い現在の習慣[2ページ]RFC3901DNS IPv6は2004年9月にガイドラインを輸送します。

   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. DNS IPv6 Transportのお勧めのGuidelines

   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,

- あらゆる再帰的なネームサーバSHOULD、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だけネームサーバフォワードのチェーンがデュアルスタック再帰的なネームサーバが実際に働くセットにそれらの反復クエリーについて質問するところで1つは構成を設計するかもしれません。

      - every DNS zone SHOULD be served by at least one IPv4-reachable
        authoritative name server.

- あらゆるDNSがSHOULDを区分します。少なくとも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.

以下に注意してください。 SHOULDが確実にするゾーンの中にどんな子供委譲のネームサーバにも利用可能な少なくとも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.

このドキュメントは2001年以来IETFにおいてほかの場所でDNS共同体で起こった多くの会話の結果です。 その期間の間、多くのインターネット草稿が、危機にひんしている問題の種々相をはっきりさせるために発表されています。 このドキュメントはそれらの議論の結論に焦点を合わせます。

   The authors would like to acknowledge the role of Pekka Savola in his
   thorough review of the document.

作者は彼のドキュメントの徹底的なレビューでペッカSavolaの役割を承認したがっています。

Durand & Ihren           Best Current Practice                  [Page 3]

RFC 3901             DNS IPv6 Transport Guidelines        September 2004

ジュランドとIhrenの最も良い現在の習慣[3ページ]RFC3901DNS IPv6は2004年9月にガイドラインを輸送します。

7.  Normative References

7. 引用規格

   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
        13, RFC 1034, November 1987.

[1]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日

   [2]  Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.

[2]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日

   [3]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.

[3] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」

   [4]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998.

[4] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日

   [5]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
        Addressing Architecture", RFC 3513, April 2003.

[5]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、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、「バージョン6インチ、RFC3596、2003年10月をIPにサポートするDNS拡張子。」

8.  Authors' Addresses

8. 作者のアドレス

   Alain Durand
   SUN Microsystems, Inc
   17 Network circle UMPK17-202
   Menlo Park, CA, 94025
   USA

アラン・ジュランドSUNマイクロシステムズ、Inc17Network円のUMPK17-202Menlo Park、カリフォルニア94025米国

   EMail: Alain.Durand@sun.com

メール: Alain.Durand@sun.com

   Johan Ihren
   Autonomica
   Bellmansgatan 30
   SE-118 47 Stockholm
   Sweden

ジョハンIhren Autonomica Bellmansgatan30SE-118 47ストックホルムスウェーデン

   EMail: johani@autonomica.se

メール: johani@autonomica.se

Durand & Ihren           Best Current Practice                  [Page 4]

RFC 3901             DNS IPv6 Transport Guidelines        September 2004

ジュランドとIhrenの最も良い現在の習慣[4ページ]RFC3901DNS IPv6は2004年9月にガイドラインを輸送します。

9.  Full Copyright Statement

9. 完全な著作権宣言文

   Copyright (C) The Internet Society (2004).

Copyright(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.

彼が代理をするか、または(もしあれば)後援される/S、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄して、急行か暗示していて、含んでいる他はあらゆる保証です。「そのままで」という基礎と貢献者の上でこのドキュメントとここに含まれた情報を提供して、組織が彼である、情報の使用はここにどんな権利か市場性のどんな黙示的な保証か特定目的への適合性も侵害しないでしょう。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Durand & Ihren           Best Current Practice                  [Page 5]

ジュランドとIhrenの最も良い現在の習慣[5ページ]