idnits 2.17.1 draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 24, 2003) is 7545 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (ref. '2') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 2535 (ref. '4') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Downref: Normative reference to an Informational RFC: RFC 1536 (ref. '5') Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration Group R. Droms (ed.) 3 Internet-Draft Cisco Systems 4 Expires: February 22, 2004 August 24, 2003 6 DNS Configuration options for DHCPv6 7 draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on February 22, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document describes DHCPv6 options for passing a list of 38 available DNS recursive name servers and a domain search list to a 39 client. 41 1. Introduction 43 This document describes two options for passing configuration 44 information related to Domain Name Service (DNS) (RFC 1034 [6] and 45 RFC 1035 [1]) in DHCPv6 (RFC 3315 [2]). 47 2. Terminology 49 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 50 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 51 interpreted as described in RFC2119 [3]. 53 Throughout this document, unless otherwise specified, the acronym 54 DHCP refers to DHCP as specified in RFC 3315. 56 This document uses terminology specific to IPv6 and DHCP as defined 57 in section "Terminology" of RFC 3315. 59 3. DNS Recursive Name Server option 61 The DNS Recursive Name Server option provides a list of one or more 62 IPv6 addresses of DNS recursive recursive name servers to which a 63 client's DNS resolver MAY send DNS queries [1]. The DNS servers are 64 listed in the order of preference for use by the client resolver. 66 The format of the DNS Recursive Name Server option is: 68 0 1 2 3 69 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 70 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 71 | OPTION_DNS_SERVERS | option-len | 72 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 73 | | 74 | DNS-recursive-name-server (IPv6 address) | 75 | | 76 | | 77 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 78 | | 79 | DNS-recursive-name-server (IPv6 address) | 80 | | 81 | | 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 | ... | 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 option-code: OPTION_DNS_SERVERS (tbd) 88 option-len: Length of the list of DNS recursive name 89 servers in octets; must be a multiple of 16 91 DNS-recursive-name-server: IPv6 address of DNS recursive name server 93 4. Domain Search List option 95 The Domain Search List option specifies the domain search list the 96 client is to use when resolving hostnames with DNS. This option does 97 not apply to other name resolution mechanisms. 99 The format of the Domain Search List option is: 101 0 1 2 3 102 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 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | OPTION_DOMAIN_LIST | option-len | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | searchlist | 107 | ... | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 option-code: OPTION_DOMAIN_LIST (tbd) 112 option-len: Length of the 'searchlist' field in octets 114 searchlist: The specification of the list of domain names in the 115 Domain Search List 117 The list of domain names in the 'searchlist' MUST be encoded as 118 specified in section "Representation and use of domain names" of RFC 119 3315. 121 5. Appearance of these options 123 The DNS Recursive Name Server option MUST NOT appear in other than 124 the following messages: Solicit, Advertise, Request, Renew, Rebind, 125 Information-Request, Reply. 127 The Domain Search List option MUST NOT appear in other than the 128 following messages: Solicit, Advertise, Request, Renew, Rebind, 129 Information-Request, Reply. 131 6. Security Considerations 133 The DNS Recursive Name Server option may be used by an intruder DHCP 134 server to cause DHCP clients to send DNS queries to an intruder DNS 135 recursive name server. The results of these misdirected DNS queries 136 may be used to spoof DNS names. 138 To avoid attacks through the DNS Recursive Name Server option, the 139 DHCP client SHOULD require DHCP authentication (see section 140 "Authentication of DHCP messages" in RFC 3315) before installing a 141 list of DNS recursive name servers obtained through authenticated 142 DHCP . 144 The Domain Search List option may be used by an intruder DHCP server 145 to cause DHCP clients to search through invalid domains for 146 incompletely specified domain names. The results of these misdirected 147 searches may be used to spoof DNS names. Note that support for 148 DNSSEC [4] will not avert this attack, because the resource records 149 in the invalid domains may be legitimately signed. 151 The degree to which a host is vulnerable to attack via an invalid 152 domain search option is determined in part by DNS resolver behavior. 153 RFC1535 [7] contains a discussion of security weaknesses related to 154 implicit as well as explicit domain searchlists, and provides 155 recommendations relating to resolver searchlist processing. Section 6 156 of RFC1536 [5] also addresses this vulnerability, and recommends that 157 resolvers: 159 1. Use searchlists only when explicitly specified; no implicit 160 searchlists should be used. 162 2. Resolve a name that contains any dots by first trying it as an 163 FQDN and if that fails, with the names in the searchlist 164 appended. 166 3. Resolve a name containing no dots by appending with the 167 searchlist right away, but once again, no implicit searchlists 168 should be used. 170 In order to minimize potential vulnerabilities it is recommended 171 that: 173 1. Hosts implementing the domain search option SHOULD also implement 174 the searchlist recommendations of RFC1536, section 6. 176 2. Where DNS parameters such as the domain searchlist or DNS servers 177 have been manually configured, these parameters SHOULD NOT be 178 overridden by DHCP. 180 3. A host SHOULD require the use of DHCP authentication (see section 181 "Authentication of DHCP messages" in RFC 3315) prior to accepting 182 a domain search option. 184 7. IANA Considerations 186 IANA is requested to assign an option code to the DNS Recursive Name 187 Server option and to the Domain Search List option from the DHCP 188 option code space defined in section "IANA Considerations" of RFC 189 3315. 191 8. Acknowledgments 193 This option was originally part of the DHCPv6 specification, written 194 by Jim Bound, Mike Carney, Charlie Perkins, Ted Lemon, Bernie Volz 195 and Ralph Droms. 197 The analysis of the potential attack through the domain search list 198 is taken from the specification of the DHCPv4 Domain Search option, 199 RFC3397 [8]. 201 Thanks to Rob Austein, Alain Durand, Peter Koch, Tony Lindstrom and 202 Pekka Savola for their contributions to this document. 204 Normative References 206 [1] Mockapetris, P., "Domain names - implementation and 207 specification", STD 13, RFC 1035, November 1987. 209 [2] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. 210 Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 211 (DHCPv6)", RFC 3315, May 2003. 213 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 214 Levels", BCP 14, RFC 2119, March 1997. 216 [4] Eastlake, D., "Domain Name System Security Extensions", RFC 217 2535, March 1999. 219 [5] Kumar, A., Postel, J., Neuman, C., Danzig, P. and S. Miller, 220 "Common DNS Implementation Errors and Suggested Fixes", RFC 221 1536, October 1993. 223 Informative References 225 [6] Mockapetris, P., "Domain names - concepts and facilities", STD 226 13, RFC 1034, November 1987. 228 [7] Gavron, E., "A Security Problem and Proposed Correction With 229 Widely Deployed DNS Software", RFC 1535, October 1993. 231 [8] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol 232 (DHCP) Domain Search Option", RFC 3397, November 2002. 234 Author's Address 236 Ralph Droms (ed.) 237 Cisco Systems 238 1414 Massachusetts Ave. 239 Boxboro, MA 01719 240 USA 242 Phone: +1 978 936 1674 243 EMail: rdroms@cisco.com 245 Intellectual Property Statement 247 The IETF takes no position regarding the validity or scope of any 248 intellectual property or other rights that might be claimed to 249 pertain to the implementation or use of the technology described in 250 this document or the extent to which any license under such rights 251 might or might not be available; neither does it represent that it 252 has made any effort to identify any such rights. Information on the 253 IETF's procedures with respect to rights in standards-track and 254 standards-related documentation can be found in BCP-11. Copies of 255 claims of rights made available for publication and any assurances of 256 licenses to be made available, or the result of an attempt made to 257 obtain a general license or permission for the use of such 258 proprietary rights by implementors or users of this specification can 259 be obtained from the IETF Secretariat. 261 The IETF invites any interested party to bring to its attention any 262 copyrights, patents or patent applications, or other proprietary 263 rights which may cover technology that may be required to practice 264 this standard. Please address the information to the IETF Executive 265 Director. 267 Full Copyright Statement 269 Copyright (C) The Internet Society (2003). All Rights Reserved. 271 This document and translations of it may be copied and furnished to 272 others, and derivative works that comment on or otherwise explain it 273 or assist in its implementation may be prepared, copied, published 274 and distributed, in whole or in part, without restriction of any 275 kind, provided that the above copyright notice and this paragraph are 276 included on all such copies and derivative works. However, this 277 document itself may not be modified in any way, such as by removing 278 the copyright notice or references to the Internet Society or other 279 Internet organizations, except as needed for the purpose of 280 developing Internet standards in which case the procedures for 281 copyrights defined in the Internet Standards process must be 282 followed, or as required to translate it into languages other than 283 English. 285 The limited permissions granted above are perpetual and will not be 286 revoked by the Internet Society or its successors or assignees. 288 This document and the information contained herein is provided on an 289 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 290 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 291 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 292 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 293 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 295 Acknowledgment 297 Funding for the RFC Editor function is currently provided by the 298 Internet Society.