summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3397.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3397.txt')
-rw-r--r--doc/rfc/rfc3397.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3397.txt b/doc/rfc/rfc3397.txt
new file mode 100644
index 0000000..d8cb7f5
--- /dev/null
+++ b/doc/rfc/rfc3397.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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
+
+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.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+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.
+
+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
+
+
+
+
+
+
+
+
+Aboba & Cheshire Standards Track [Page 1]
+
+RFC 3397 DHCP Domain Search Option November 2002
+
+
+1. Introduction
+
+ 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.
+
+1.1. Terminology
+
+ 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 server
+ A DHCP server or "server" is an Internet host that returns
+ configuration parameters to DHCP clients.
+
+1.2. Requirements Language
+
+ 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].
+
+2. Domain Search Option Format
+
+ The code for this option is 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...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ 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].
+
+
+
+Aboba & Cheshire Standards Track [Page 2]
+
+RFC 3397 DHCP Domain Search Option November 2002
+
+
+ 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.
+
+ 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).
+
+ 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.
+
+3. Example
+
+ Below is an example encoding of a search list consisting of
+ "eng.apple.com." and "marketing.apple.com.":
+
+ +---+---+---+---+---+---+---+---+---+---+---+
+ |119| 9 | 3 |'e'|'n'|'g'| 5 |'a'|'p'|'p'|'l'|
+ +---+---+---+---+---+---+---+---+---+---+---+
+
+ +---+---+---+---+---+---+---+---+---+---+---+
+ |119| 9 |'e'| 3 |'c'|'o'|'m'| 0 | 9 |'m'|'a'|
+ +---+---+---+---+---+---+---+---+---+---+---+
+
+ +---+---+---+---+---+---+---+---+---+---+---+
+ |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.
+
+ 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.
+
+
+
+Aboba & Cheshire Standards Track [Page 3]
+
+RFC 3397 DHCP Domain Search Option November 2002
+
+
+ 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.").
+
+ 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.
+
+4. Security Considerations
+
+ 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.
+
+ 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]).
+
+ 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:
+
+ [1] Use searchlists only when explicitly specified; no implicit
+ searchlists should be used.
+
+ [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.
+
+ [3] Resolve a name containing no dots by appending with the
+ searchlist right away, but once again, no implicit searchlists
+ should be used.
+
+
+
+
+Aboba & Cheshire Standards Track [Page 4]
+
+RFC 3397 DHCP Domain Search Option November 2002
+
+
+ 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.
+
+ [b] Where DNS parameters such as the domain searchlist or DNS
+ servers have been manually configured, these parameters SHOULD
+ NOT be overridden by DHCP.
+
+ [c] Domain search option implementations MAY require DHCP
+ authentication [RFC3118] prior to accepting a domain search
+ option.
+
+5. Normative References
+
+ [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+ Specification", STD 13, RFC 1035, November 1987.
+
+ [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P. and S.
+ Miller, "Common DNS Implementation Errors and Suggested
+ Fixes", RFC 1536, October 1993.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
+ 2131, March 1997.
+
+ [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
+ Messages", RFC 3118, June 2001.
+
+ [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the
+ Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
+ November 2002.
+
+6. Informative References
+
+ [RFC1535] Gavron, E., "A Security Problem and Proposed Correction
+ With Widely Deployed DNS Software", RFC 1535, October
+ 1993.
+
+ [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP
+ Vendor Extensions", RFC 2132, March 1997.
+
+
+
+
+
+
+Aboba & Cheshire Standards Track [Page 5]
+
+RFC 3397 DHCP Domain Search Option November 2002
+
+
+ [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
+ 2937, September 2000.
+
+7. IANA Considerations
+
+ The IANA has assigned DHCP option code 119 to the Domain Search
+ Option.
+
+8. Acknowledgments
+
+ 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.
+
+9. 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Cheshire Standards Track [Page 6]
+
+RFC 3397 DHCP Domain Search Option November 2002
+
+
+10. Authors' Addresses
+
+ Bernard Aboba
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+
+ Phone: +1 425 706 6605
+ EMail: bernarda@microsoft.com
+
+
+ Stuart Cheshire
+ Apple Computer, Inc.
+ 1 Infinite Loop
+ Cupertino
+ California 95014
+ USA
+
+ Phone: +1 408 974 3207
+ EMail: rfc@stuartcheshire.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Cheshire Standards Track [Page 7]
+
+RFC 3397 DHCP Domain Search Option November 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Cheshire Standards Track [Page 8]
+