この文書は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エディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So