Network Working Group B. Aboba
Request for Comments: 3397 Microsoft
Category: Standards Track S. Cheshire
Apple Computer, Inc.
November 2002
Network Working Group B. Aboba
Request for Comments: 3397 Microsoft
Category: Standards Track S. Cheshire
Apple Computer, Inc.
November 2002
Dynamic Host Configuration Protocol (DHCP) Domain Search Option
动态主机配置协议（DHCP）域搜索选项
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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to specify the domain search list used when resolving hostnames using DNS.
本文档定义了一个新的动态主机配置协议（DHCP）选项，该选项从DHCP服务器传递到DHCP客户端，以指定使用DNS解析主机名时使用的域搜索列表。
Table of Contents
目录
1. Introduction ................................................ 2
1.1 Terminology ............................................ 2
1.2 Requirements Language .................................. 2
2. Domain Search Option Format ................................. 2
3. Example ..................................................... 3
4. Security Considerations ..................................... 4
5. Normative References ........................................ 5
6. Informative References ...................................... 5
7. IANA Considerations ......................................... 6
8. Acknowledgments ............................................. 6
9. Intellectual Property Statement ............................. 6
10. Authors' Addresses .......................................... 7
11. Full Copyright Statement .................................... 8
1. Introduction ................................................ 2
1.1 Terminology ............................................ 2
1.2 Requirements Language .................................. 2
2. Domain Search Option Format ................................. 2
3. Example ..................................................... 3
4. Security Considerations ..................................... 4
5. Normative References ........................................ 5
6. Informative References ...................................... 5
7. IANA Considerations ......................................... 6
8. Acknowledgments ............................................. 6
9. Intellectual Property Statement ............................. 6
10. Authors' Addresses .......................................... 7
11. Full Copyright Statement .................................... 8
The Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a mechanism for host configuration. [RFC2132] and [RFC2937] allow DHCP servers to pass name service configuration information to DHCP clients. In some circumstances, it is useful for the DHCP client to be configured with the domain search list. This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to specify the domain search list used when resolving hostnames with DNS. This option applies only to DNS and does not apply to other name resolution mechanisms.
动态主机配置协议（DHCP）[RFC2131]为主机配置提供了一种机制。[RFC2132]和[RFC2937]允许DHCP服务器将名称服务配置信息传递给DHCP客户端。在某些情况下，使用域搜索列表配置DHCP客户端非常有用。本文档定义了一个新的DHCP选项，该选项从DHCP服务器传递到DHCP客户端，以指定使用DNS解析主机名时使用的域搜索列表。此选项仅适用于DNS，不适用于其他名称解析机制。
This document uses the following terms:
本文件使用以下术语：
DHCP client A DHCP client or "client" is an Internet host using DHCP to obtain configuration parameters such as a network address.
DHCP客户端DHCP客户端或“客户端”是使用DHCP获取配置参数（如网络地址）的Internet主机。
DHCP server A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients.
DHCP服务器DHCP服务器或“服务器”是向DHCP客户端返回配置参数的Internet主机。
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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照“RFC中用于指示需求水平的关键词”[RFC2119]中的描述进行解释。
The code for this option is 119.
此选项的代码为119。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 119 | Len | Searchstring...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Searchstring...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 119 | Len | Searchstring...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Searchstring...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the above diagram, Searchstring is a string specifying the searchlist. If the length of the searchlist exceeds the maximum permissible within a single option (255 octets), then multiple options MAY be used, as described in "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396].
在上图中，Searchstring是一个指定searchlist的字符串。如果搜索列表的长度超过单个选项（255个八位字节）内允许的最大长度，则可以使用多个选项，如“动态主机配置协议（DHCPv4）中的编码长选项”所述[RFC3396]。
To enable the searchlist to be encoded compactly, searchstrings in the searchlist MUST be concatenated and encoded using the technique described in section 4.1.4 of "Domain Names - Implementation And Specification" [RFC1035]. In this scheme, an entire domain name or a list of labels at the end of a domain name is replaced with a pointer to a prior occurrence of the same name. Despite its complexity, this technique is valuable since the space available for encoding DHCP options is limited, and it is likely that a domain searchstring will contain repeated instances of the same domain name. Thus the DNS name compression is both useful and likely to be effective.
为了使搜索列表能够紧凑地编码，必须使用“域名-实现和规范”[RFC1035]第4.1.4节中描述的技术连接和编码搜索列表中的搜索字符串。在该方案中，整个域名或域名末尾的标签列表被替换为指向先前出现的相同名称的指针。尽管它很复杂，但这种技术很有价值，因为可用于编码DHCP选项的空间有限，而且域搜索字符串很可能包含相同域名的重复实例。因此，DNS名称压缩既有用又可能有效。
For use in this specification, the pointer refers to the offset within the data portion of the DHCP option (not including the preceding DHCP option code byte or DHCP option length byte).
在本规范中使用时，指针指DHCP选项数据部分内的偏移量（不包括前面的DHCP选项代码字节或DHCP选项长度字节）。
If multiple Domain Search Options are present, then the data portions of all the Domain Search Options are concatenated together as specified in "Encoding Long DHCP Options in the Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396] and the pointer indicates an offset within the complete aggregate block of data.
如果存在多个域搜索选项，则所有域搜索选项的数据部分将按照“动态主机配置协议（DHCPv4）中的编码长DHCP选项”[RFC3396]中的规定连接在一起，指针指示完整聚合数据块内的偏移量。
Below is an example encoding of a search list consisting of "eng.apple.com." and "marketing.apple.com.":
下面是由“eng.apple.com.”和“marketing.apple.com.”组成的搜索列表的编码示例：
+---+---+---+---+---+---+---+---+---+---+---+
|119| 9 | 3 |'e'|'n'|'g'| 5 |'a'|'p'|'p'|'l'|
+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+
|119| 9 | 3 |'e'|'n'|'g'| 5 |'a'|'p'|'p'|'l'|
+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+
|119| 9 |'e'| 3 |'c'|'o'|'m'| 0 | 9 |'m'|'a'|
+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+
|119| 9 |'e'| 3 |'c'|'o'|'m'| 0 | 9 |'m'|'a'|
+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+
|119| 9 |'r'|'k'|'e'|'t'|'i'|'n'|'g'|xC0|x04|
+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+
|119| 9 |'r'|'k'|'e'|'t'|'i'|'n'|'g'|xC0|x04|
+---+---+---+---+---+---+---+---+---+---+---+
Note:
注:
i. The encoding has been split (for this example) into three Domain Search Options. All Domain Search Options are logically concatenated into one block of data before being interpreted by the client.
i. 编码已拆分为三个域搜索选项（在本例中）。在客户端解释之前，所有域搜索选项在逻辑上连接到一个数据块中。
ii. The encoding of "eng.apple.com." ends with a zero, the null root label, to mark the end of the name, as required by RFC 1035.
二,。根据RFC1035的要求，“eng.apple.com”的编码以零结尾，即空根标签，以标记名称的结尾。
iii. The encoding of "marketing" (for "marketing.apple.com.") ends with the two-octet compression pointer C004 (hex), which points to offset 4 in the complete aggregated block of Domain Search Option data, where another validly encoded domain name can be found to complete the name ("apple.com.").
iii.“marketing”（用于“marketing.apple.com”）的编码以两个八位压缩指针C004（十六进制）结束，该指针指向域搜索选项数据的完整聚合块中的偏移量4，其中可以找到另一个有效编码的域名来完成名称（“apple.com”）。
Every search domain name must end either with a zero or with a two-octet compression pointer. If the receiver is part-way through decoding a search domain name when it reaches the end of the complete aggregated block of the searchlist option data, without finding a zero or a valid two-octet compression pointer, then the partially read name MUST be discarded as invalid.
每个搜索域名必须以零或两个八位压缩指针结尾。如果接收器在搜索域名到达searchlist选项数据的完整聚合块的末尾时正在部分解码搜索域名，而未找到零或有效的两个八位字节压缩指针，则必须将部分读取的名称视为无效而丢弃。
Potential attacks on DHCP are discussed in section 7 of the DHCP protocol specification [RFC2131], as well as in the DHCP authentication specification [RFC3118]. In particular, using the domain search option, a rogue DHCP server might be able to redirect traffic to another site.
DHCP协议规范[RFC2131]第7节以及DHCP身份验证规范[RFC3118]中讨论了对DHCP的潜在攻击。特别是，使用域搜索选项，恶意DHCP服务器可能能够将流量重定向到另一个站点。
For example, a user requesting a connection to "myhost", expecting to reach "myhost.bigco.com" might instead be directed to "myhost.roguedomain.com". Note that support for DNSSEC [RFC2535] will not avert this attack, since the resource records for "myhost.roguedomain.com" might be legitimately signed. This makes the domain search option a more fruitful avenue of attack for a rogue DHCP server than providing an illegitimate DNS server option (described in [RFC2132]).
例如，请求连接到“myhost”的用户，希望访问“myhost.bigco.com”，可能会被定向到“myhost.roguedomain.com”。请注意，对DNSSEC[RFC2535]的支持不会避免此攻击，因为“myhost.roguedomain.com”的资源记录可能是合法签名的。这使得域搜索选项成为流氓DHCP服务器比提供非法DNS服务器选项（如[RFC2132]所述）更有效的攻击途径。
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] discusses security weaknesses related to implicit as well as explicit domain searchlists, and provides recommendations relating to resolver searchlist processing. [RFC1536] section 6 also addresses this vulnerability, and recommends that resolvers:
主机易受无效域搜索选项攻击的程度部分由DNS解析程序行为决定。[RFC1535]讨论了与隐式和显式域搜索列表相关的安全弱点，并提供了与解析器搜索列表处理相关的建议。[RFC1536]第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 local domain name (or searchlist if specified) 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:
为了尽量减少潜在的漏洞，建议：
[a] Hosts implementing the domain search option SHOULD also implement the searchlist recommendations of [RFC1536], section 6.
[a] 实现域搜索选项的主机还应实现[RFC1536]第6节中的搜索列表建议。
[b] Where DNS parameters such as the domain searchlist or DNS servers have been manually configured, these parameters SHOULD NOT be overridden by DHCP.
[b] 如果DNS参数（如域搜索列表或DNS服务器）已手动配置，则DHCP不应覆盖这些参数。
[c] Domain search option implementations MAY require DHCP authentication [RFC3118] prior to accepting a domain search option.
[c] 域搜索选项实施可能需要DHCP身份验证[RFC3118]才能接受域搜索选项。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P. and S. Miller, "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, October 1993.
[RFC1536]Kumar，A.，Postel，J.，Neuman，C.，Danzig，P.和S.Miller，“常见DNS实现错误和建议修复”，RFC 1536，1993年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118]Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[RFC3396]Lemon，T.和S.Cheshire，“动态主机配置协议（DHCPv4）中的长选项编码”，RFC 3396，2002年11月。
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, October 1993.
[RFC1535]Gavron，E.，“广泛部署DNS软件的安全问题和建议纠正”，RFC 1535，1993年10月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake，D.，“域名系统安全扩展”，RFC25351999年3月。
[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC 2937, September 2000.
[RFC2937]Smith，C.，“DHCP的名称服务搜索选项”，RFC 2937，2000年9月。
The IANA has assigned DHCP option code 119 to the Domain Search Option.
IANA已将DHCP选项代码119分配给域搜索选项。
The authors would like to thank Michael Patton, Erik Guttman, Olafur Gudmundsson, Thomas Narten, Mark Andrews, Erik Nordmark, Myron Hattig, Keith Moore, and Bill Manning for comments on this memo.
作者要感谢Michael Patton、Erik Guttman、Olafur Gudmundsson、Thomas Narten、Mark Andrews、Erik Nordmark、Myron Hattig、Keith Moore和Bill Manning对本备忘录的评论。
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执行董事。
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 706 6605
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
EMail: bernarda@microsoft.com
Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino California 95014 USA
Stuart Cheshire苹果电脑有限公司美国加利福尼亚州库珀蒂诺无限环路95014
Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org
Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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 assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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编辑功能的资金目前由互联网协会提供。