この文書はRFC3234の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
この文書はインターネット共同体のための現時点のインターネット最良実践
を指定し、そして改良のために議論と提案を求めます。このメモの配布は無
制限です。
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.
このメモは問合せと応答がＩＰｖ４とＩＰｖ６ネットワークの入り混ざった
環境に載る世界でＤＮＳを運営することに対するガイドラインと現在最良実
践を供給します。
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.
インターネットがＩＰｖ４からＩＰｖ４とＩＰｖ６の混合に移行する時、こ
れが起き始めるのは時間の問題です。完全なＤＮＳ階層は、グラフのノード
の正式なネームサーバがあるトランスポート上でアクセス可能な所に分断し
始めます。懸念は特定のＩＰバージョンを使用するリゾルバと、あるＩＰバー
ジョンを使う他のノードの問合せ情報が、解決処理でアクセスするサーバ連
鎖のいくつかが他のＩＰバージョンでしか動かないため、動作しない事です。
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.
ＩＰｖ４トランスポート上ですべてのＤＮＳデータが利用可能な状態はすべ
てが単純です。ＩＰｖ４リゾルバがルートから紹介を伝う意図するメカニズ
ムを利用可能ですが、ＩＰｖ６リゾルバが「翻訳者」を通して働かなければ
なりません、つまりＤＮＳデータを直接アクセスできないので、「デュアル
スタック」と呼ばれるホストの再帰ネームサーバを転送者に使います。
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.
ＩＰｖ６トランスポートでのみ利用可能なＤＮＳデータで、ＩＰｖ４再帰ネー
ムサーバは転送に設定すればいいので、全てが単純です。
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.
しかしながら、２番目の状態は近い将来生じないでしょう。その代わりに、
移行はＩＰｖ４だけから、ＩＰｖ４とＩＰｖ６の混合へとなり、ＩＰｖ４ト
ランスポートのみか、ＩＰｖ６トランスポートのみか、両方かで、ＤＮＳデー
タの３つのカテゴリが生じるでしょう。
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.
両方のトランスポートで利用可能なＤＮＳデータを持つことは最も良い状態
です。主な質問はどのようにそれが可能な限り速く通常になることを保証す
るべきかです。しかしながら、あるＤＮＳデータが長期間ＩＰｖ４上でだけ
利用可能であることが明白で、ＩＰｖ４のみが利用可能なホストの名前空間
の分断を避けることが重要なのも同じく明白です。例えば、移行の間、現在
ＩＰｖ４のみのホストに利用可能である名前空間を壊すことは許容できませ
ん。
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.
用語「ＩＰｖ４ネームサーバ」はＩＰｖ４トランスポート上で利用可能なネー
ムサーバを示します。それは、どのＤＮＳ[1,2]データを供給するかについて
は何も暗示しません。同様に、「ＩＰｖ６[4,5,6]ネームサーバ」がＩＰｖ６
トランスポート上で利用可能なネームサーバを示します。用語「デュアルス
タックネームサーバ」はＩＰｖ４とＩＰｖ６の両プロトコルで動作するよう
に設定されたネームサーバを示し、単に両方で動作可能なシステム上の一方
だけを動作させているのを示しません。
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.
今日、ＩＰｖ６トランスポートで利用可能なＤＮＳの「ゾーン」はほんの少
しだけで、大部分が「実験的」と見なせます。しかしながら、ルートと最上
位ドメインがＩＰｖ６トランスポートで利用可能になるとすぐに、ＩＰｖ６
サーバのサポートするゾーンを持つことがより一般的になると思うことは合
理的です。
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.
ＩＰｖ６のみのネームサーバでサポートされるゾーンを持つことは、これが
ＩＰｖ４名前空間を分解し、これを避けるためにメカニズムを見いだす強い
理由があるので、良い展開ではないでしょう。
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. ＤＮＳＩＰｖ６トランスポート勧告ガイドライン
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,
- すべての再帰ネームサーバは、ＩＰｖ４のみか、デュアルスタックであ
るべきです。
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.
これはＩＰｖ６のみの再帰サーバを除外します。しかしながら、ＩＰｖ
６のみのネームサーバが再帰問合せを行うデュアルスタック再帰ネーム
サーバにを尋ねる設定を設計するかもしれません。
- every DNS zone SHOULD be served by at least one IPv4-reachable
authoritative name server.
- すべてのＤＮＳゾーンは少なくとも１つのＩＰｖ４到達可能な正式なネー
ムサーバによってサポートされるべきです。
This rules out DNS zones served only by IPv6-only authoritative
name servers.
これはＩＰｖ６だけの正式なネームサーバによってだけサポートされ
るＤＮＳゾーンを除外します。
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.
ノート：ゾーン承認プロセスは、ゾーンの子委任のネームサーバのに、利用
可能な少なくとも１つのＩＰｖ４アドレスレコードがあることを保証するべ
きです。
5. Security Considerations
5. セキュリティの考察
The guidelines described in this memo introduce no new security
considerations into the DNS protocol or associated operational
scenarios.
このメモで記述されたガイドラインはＤＮＳプロトコルあるいは関連づけら
れた運用上のシナリオに新しいセキュリティの考慮を導入しません。
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.
この文書はＩＥＴＦのＤＮＳ共同体や他のところで２００１年から起きた多
くの会話の結果です。その時期の間に、多くのインターネットドラフトが危
機にある問題の種々な局面を明確にするために出版されました。この文書は
それらの論議の結論に焦点を合わせます。
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).
著作権（Ｃ）インターネット学会（２００４）。
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.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。
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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/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-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。