Network Working Group R. Droms, Ed.
Request for Comments: 3646 Cisco Systems
Category: Standards Track December 2003
Network Working Group R. Droms, Ed.
Request for Comments: 3646 Cisco Systems
Category: Standards Track December 2003
DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
IPv6（DHCPv6）动态主机配置协议的DNS配置选项
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes Dynamic Host Configuration Protocol for IPv6 (DHCPv6) options for passing a list of available DNS recursive name servers and a domain search list to a client.
本文档介绍用于将可用DNS递归名称服务器列表和域搜索列表传递给客户端的IPv6动态主机配置协议（DHCPv6）选项。
This document describes two options for passing configuration information related to Domain Name Service (DNS) (RFC 1034 [6] and RFC 1035 [1]) in DHCPv6 (RFC 3315 [2]).
本文档描述了在DHCPv6（RFC 3315[2]）中传递与域名服务（DNS）相关的配置信息（RFC 1034[6]和RFC 1035[1]）的两个选项。
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14, RFC 2119 [3].
本文件中的关键词必须、不得、要求、应、不应、应、不应、建议、可和可选应按照BCP 14、RFC 2119[3]中的说明进行解释。
Throughout this document, unless otherwise specified, the acronym DHCP refers to DHCP for IPv6 (DHCPv6) as specified in RFC 3315.
在本文档中，除非另有规定，否则首字母缩写DHCP指RFC 3315中规定的IPv6 DHCP（DHCPv6）。
This document uses terminology specific to IPv6 and DHCP as defined in section "Terminology" of RFC 3315.
本文档使用RFC 3315“术语”一节中定义的IPv6和DHCP专用术语。
The DNS Recursive Name Server option provides a list of one or more IPv6 addresses of DNS recursive name servers to which a client's DNS resolver MAY send DNS queries [1]. The DNS servers are listed in the order of preference for use by the client resolver.
DNS递归名称服务器选项提供了一个DNS递归名称服务器的一个或多个IPv6地址列表，客户端的DNS解析程序可以将DNS查询发送到这些服务器[1]。DNS服务器按首选顺序列出，供客户端解析程序使用。
The format of the DNS Recursive Name Server option is:
DNS递归名称服务器选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_DNS_SERVERS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DNS-recursive-name-server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DNS-recursive-name-server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_DNS_SERVERS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DNS-recursive-name-server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DNS-recursive-name-server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_DNS_SERVERS (23)
选项代码：选项\u DNS\u服务器（23）
option-len: Length of the list of DNS recursive name servers in octets; must be a multiple of 16
选项len：DNS递归名称服务器列表的长度（以八位字节为单位）；必须是16的倍数
DNS-recursive-name-server: IPv6 address of DNS recursive name server
DNS递归名称服务器：DNS递归名称服务器的IPv6地址
The Domain Search List option specifies the domain search list the client is to use when resolving hostnames with DNS. This option does not apply to other name resolution mechanisms.
域搜索列表选项指定客户端在使用DNS解析主机名时要使用的域搜索列表。此选项不适用于其他名称解析机制。
The format of the Domain Search List option is:
域搜索列表选项的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_DOMAIN_LIST | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| searchlist |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_DOMAIN_LIST | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| searchlist |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_DOMAIN_LIST (24)
选项代码：选项域列表（24）
option-len: Length of the 'searchlist' field in octets
选项len：“搜索列表”字段的长度（以八位字节为单位）
searchlist: The specification of the list of domain names in the Domain Search List
searchlist：域名搜索列表中域名列表的规范
The list of domain names in the 'searchlist' MUST be encoded as specified in section "Representation and use of domain names" of RFC 3315.
“搜索列表”中的域名列表必须按照RFC 3315“域名的表示和使用”一节的规定进行编码。
The DNS Recursive Name Server option MUST NOT appear in any other than the following messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply.
DNS递归名称服务器选项只能出现在以下消息中：请求、播发、请求、续订、重新绑定、信息请求和回复。
The Domain Search List option MUST NOT appear in any other than the following messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply.
“域搜索列表”选项不得出现在除以下消息以外的任何消息中：请求、播发、请求、续订、重新绑定、信息请求和回复。
The DNS Recursive Name Server option may be used by an intruder DHCP server to cause DHCP clients to send DNS queries to an intruder DNS recursive name server. The results of these misdirected DNS queries may be used to spoof DNS names.
入侵者DHCP服务器可使用DNS递归名称服务器选项，使DHCP客户端向入侵者DNS递归名称服务器发送DNS查询。这些定向错误的DNS查询的结果可用于伪造DNS名称。
To avoid attacks through the DNS Recursive Name Server option, the DHCP client SHOULD require DHCP authentication (see section "Authentication of DHCP messages" in RFC 3315) before installing a list of DNS recursive name servers obtained through authenticated DHCP.
为避免通过DNS递归名称服务器选项进行攻击，DHCP客户端应在安装通过已验证DHCP获得的DNS递归名称服务器列表之前要求进行DHCP身份验证（请参阅RFC 3315中的“DHCP消息的身份验证”一节）。
The Domain Search List option may be used by an intruder DHCP server to cause DHCP clients to search through invalid domains for incompletely specified domain names. The results of these
入侵者DHCP服务器可能会使用“域搜索列表”选项，使DHCP客户端在无效域中搜索未完全指定的域名。这些研究的结果
misdirected searches may be used to spoof DNS names. Note that support for DNSSEC [4] will not avert this attack, because the resource records in the invalid domains may be legitimately signed.
定向错误的搜索可能被用于伪造DNS名称。请注意，对DNSSEC[4]的支持不会避免此攻击，因为无效域中的资源记录可能会被合法签名。
The degree to which a host is vulnerable to attack via an invalid domain search option is determined in part by DNS resolver behavior. RFC1535 [7] contains a discussion of security weaknesses related to implicit as well as explicit domain searchlists, and provides recommendations relating to resolver searchlist processing. Section 6 of RFC1536 [5] also addresses this vulnerability, and recommends that resolvers:
主机易受无效域搜索选项攻击的程度部分由DNS解析程序行为决定。RFC1535[7]讨论了与隐式和显式域搜索列表相关的安全弱点，并提供了与解析器搜索列表处理相关的建议。RFC1536[5]第6节也解决了此漏洞，并建议冲突解决程序：
1. Use searchlists only when explicitly specified; no implicit searchlists should be used.
1. 仅在明确指定时使用搜索列表；不应使用隐式搜索列表。
2. Resolve a name that contains any dots by first trying it as an FQDN and if that fails, with the names in the searchlist appended.
2. 首先尝试将包含任何点的名称作为FQDN解析，如果失败，则附加搜索列表中的名称。
3. Resolve a name containing no dots by appending with the searchlist right away, but once again, no implicit searchlists should be used.
3. 通过立即添加搜索列表来解析不包含点的名称，但再次强调，不应使用隐式搜索列表。
In order to minimize potential vulnerabilities it is recommended that:
为了尽量减少潜在的漏洞，建议：
1. Hosts implementing the domain search option SHOULD also implement the searchlist recommendations of RFC1536, section 6.
1. 实现域搜索选项的主机还应实现RFC1536第6节中的搜索列表建议。
2. Where DNS parameters such as the domain searchlist or DNS servers have been manually configured, these parameters SHOULD NOT be overridden by DHCP.
2. 如果DNS参数（如域搜索列表或DNS服务器）已手动配置，则DHCP不应覆盖这些参数。
3. A host SHOULD require the use of DHCP authentication (see section "Authentication of DHCP messages" in RFC 3315) prior to accepting a domain search option.
3. 在接受域搜索选项之前，主机应要求使用DHCP身份验证（请参阅RFC 3315中的“DHCP消息的身份验证”一节）。
IANA has assigned an option code to the DNS Recursive Name Server option (23) and to the Domain Search List option (24) from the DHCP option code space defined in section "IANA Considerations" of RFC 3315.
IANA已从RFC 3315“IANA注意事项”部分中定义的DHCP选项代码空间为DNS递归名称服务器选项（23）和域搜索列表选项（24）分配了选项代码。
This option was originally part of the DHCPv6 specification, written by Jim Bound, Mike Carney, Charlie Perkins, Ted Lemon, Bernie Volz and Ralph Droms.
该选项最初是DHCPv6规范的一部分，由Jim Bound、Mike Carney、Charlie Perkins、Ted Lemon、Bernie Volz和Ralph Droms编写。
The analysis of the potential attack through the domain search list is taken from the specification of the DHCPv4 Domain Search option, RFC3397 [8].
通过域搜索列表对潜在攻击的分析来自DHCPv4域搜索选项RFC3397[8]的规范。
Thanks to Rob Austein, Alain Durand, Peter Koch, Tony Lindstrom and Pekka Savola for their contributions to this document.
感谢Rob Austein、Alain Durand、Peter Koch、Tony Lindstrom和Pekka Savola对本文件的贡献。
[1] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[1] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[2] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, May 2003.
[2] Bound，J.，Carney，M.，Perkins，C.，Lemon，T.，Volz，B.和R.Droms（编辑），“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，2003年5月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[4] Eastlake，D.，“域名系统安全扩展”，RFC 25351999年3月。
[5] Kumar, A., Postel, J., Neuman, C., Danzig, P. and S. Miller, "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, October 1993.
[5] Kumar，A.，Postel，J.，Neuman，C.，Danzig，P.和S.Miller，“常见DNS实现错误和建议修复”，RFC 1536，1993年10月。
[6] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[6] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[7] Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, October 1993.
[7] Gavron，E.“一个安全问题和广泛部署的DNS软件的修正建议”，RFC 1535，1993年10月。
[8] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, November 2002.
[8] Aboba，B.和S.Cheshire，“动态主机配置协议（DHCP）域搜索选项”，RFC 3397，2002年11月。
Intellectual Property Statement
知识产权声明
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Author's Address
作者地址
Ralph Droms, Editor Cisco Systems 1414 Massachusetts Ave. Boxboro, MA 01719 USA
Ralph Droms，美国马萨诸塞州Boxboro马萨诸塞大道1414号思科系统编辑，01719
Phone: +1 978 936 1674
EMail: rdroms@cisco.com
Phone: +1 978 936 1674
EMail: rdroms@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。