Network Working Group A. Durand
Request for Comments: 3901 SUN Microsystems, Inc.
BCP: 91 J. Ihren
Category: Best Current Practice Autonomica
September 2004
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）互联网协会（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
由于所有DNS数据只能通过IPv4传输，所以一切都很简单。IPv4冲突解决程序可以使用预期的机制，即在IPv6冲突解决程序必须工作时，从根目录和根目录向下执行引用
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.
由于所有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.
然而，第二种情况在可预见的将来不会出现。相反，将从仅IPv4过渡到IPv4和IPv6的混合，根据信息是否仅通过IPv4传输、是否仅通过IPv6或两者都可用，将有三类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名称服务器”表示通过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.
如今，公共互联网上只有少数几个DNS“区域”可通过IPv6传输使用，其中大多数可被视为“实验性的”。但是，一旦根域和顶级域通过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区域应至少由一个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.
注意：区域验证过程应确保至少有一个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 10351987年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.和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.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-202号网络圈UMPK17-202，邮编94025
EMail: Alain.Durand@sun.com
EMail: Alain.Durand@sun.com
Johan Ihren Autonomica Bellmansgatan 30 SE-118 47 Stockholm Sweden
瑞典斯德哥尔摩约翰·伊赫伦自治区贝尔曼斯加坦30 SE-118 47
EMail: johani@autonomica.se
EMail: 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.
本文件及其包含的信息是按“原样”提供的，贡献者、其代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。