idnits 2.17.1 draft-ietf-dhc-host-option-considerations-02.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 5 instances of lines with control characters in the document. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2132, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 110 has weird spacing: '...alifled full...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC2132, updated by this document, for RFC5378 checks: 1995-06-01) -- 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 (September 2003) is 7527 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 1533 (ref. '1') (Obsoleted by RFC 2132) == Outdated reference: A later version (-13) exists of draft-ietf-dhc-fqdn-option-05 == Outdated reference: A later version (-12) exists of draft-ietf-dhc-ddns-resolution-05 Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group Carl Smith 3 Internet Draft Sun Microsystems, Inc. 4 Ted Lemon 5 Nominum, Inc. 6 Updates: RFC 2132 March 2003 7 Expires September 2003 9 Considerations for the use of the Host Name option 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 To view the entire list of current Internet-Drafts, please check the 26 1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 28 Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim), 29 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 31 Abstract 33 This document clarifies the use of the DHCP Host Name option. The 34 primary point of this clarification addresses the use of the option 35 by clients to request proxy DNS updates by DHCP servers. 37 1. Introduction 39 The initial concept of the Host Name option, as documented in RFC 40 1533[1] and duplicated in RFC 2132 [2], was simply to allow a DHCP 41 server to supply a client with its name (``This option specifies the 42 name of the client''). The DHCP client was merely a consumer of the 43 option information. Even in this case, confusion has been reported 44 in interactions with various domain name options. 46 Behavior of client and server when the client supplies the option 47 was, and still is, unspecified. In the intervening years, the 48 ability to easily update Domain Name Service information [3] has 49 encouraged the use of this option by DHCP clients as a way to request 50 that DHCP servers issue proxy DNS updates on their behalf. Lack of a 51 document describing its exact usage has led, as one would surely 52 expect, to interoperability problems. It is the purpose of this 53 document to outline the expectations that clients and servers should 54 have when using the Host Name option. 56 2. Definitions 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 60 document are to be interpreted as described in RFC 2119 [4]. This 61 document also uses the following terms: 63 "DHCP client" 65 DHCP client or "client" is an Internet host using DHCP to 66 obtain configuration parameters such as a network address. 68 "DHCP server" 70 A DHCP server or "server" is an Internet host that returns 71 configuration parameters to DHCP clients. 73 "FQDN" 75 A fully-qualified name, including the host part and Domain Name 76 system domain. 78 3. Interactions with Name Services 80 RFC 2132 [2] indicates that the value supplied in the Host Name 81 option may or may not be fully-qualified, suggesting the use of the 82 Domain Name option to retrieve the domain name. This, plus the 83 possibility of interactions between DNS (RFC 1034 [5] and RFC 1035 84 [6]) and other naming services motivates us to clarify and expand the 85 description of the expected behavior: 87 if a DHCP server supplies both Host Name and Domain Name options 88 to a client, the host name SHOULD NOT be fully-qualified 90 if a DHCP server supplies only a Host Name option, the host name 91 SHOULD be fully qualified; the server MUST append only DNS domain 92 names in forming a fully-qualified name 94 a client MUST check to see whether a Host Name option contains a 95 fully-qualified name and if so, MUST NOT append the value of the 96 Domain Name option (if present) in forming its fully-qualified 97 domain name 99 since a Host Name option's value may be fully-qualified only by 100 supplying the DNS domain name, a client that receives a fully- 101 qualified name in the Host Name option MAY infer the DNS domain 102 name from the suffix of the supplied host name. This inference 103 remains valid even in the presence of client configuration infor- 104 mation or policies that prefer other name services in favor of, or 105 in place of, DNS. 107 In summary, 109 Host Name Host Name 110 not fully-qualifled fully-qualified 111 _____________________________________________ 112 Domain Name | no derivable FQDN | infer Domain Name | 113 option absent | | from Host Name suffix | 114 |____________________|________________________| 115 Domain Name | derive FQDN by | Domain Name MUST be a | 116 option present | Host and Domain | suffix of Host Name | 117 | Name concatenation | | 118 |____________________|________________________| 120 4. DNS Updates for DHCP Clients 122 DNS maintains Resource Records (RRs) for mapping between IP addresses 123 FQDNs. Specifically, A records map FQDNs to IP addresses and PTR 124 records map IP addresses to FQDNs. Several options are available to 125 DHCP clients interested in updating A and PTR records: 127 issuing direct updates to DNS 129 using the DHCP client FQDN option [7] 131 using the DHCP Host Name option 133 Either of the first two methods has the advantage of offering the 134 client a number of approaches for fine-tuning DNS update requests as 135 well as direct feedback on the success or failure of the intended 136 operations. Both are to be preferred over the latter: use of the 137 Host Name option does not even guarantee that the DHCP server will 138 attempt any DNS updates on a client's behalf. It should be con- 139 sidered deprecated. Nevertheless, support for this method of 140 requesting proxy DNS updates is widespread and it may be viewed as 141 appropriate for situations in which there are no requirements for 142 other finely-tunable methods. 144 4.1 DHCP Client Considerations and Behavior 146 A DHCP client that uses the Host Name option to request a DNS update 147 MUST be prepared to independently verify the success or failure of 148 the request before using the name in a manner that would imply its 149 validity. If a DHCP server returns the requested name in the 150 DHCPACK's Host Name option, the client MAY infer that the server has 151 honored its request. 153 There are a number of reasons that a DHCP server may fail to return a 154 Host Name option; nothing should be inferred from the option's 155 absence in the DHCPACK. The client MAY supply the option on subse- 156 quent RENEW operations as a method of retrying the request. However, 157 if the Host Name option is absent in the DHCPACK, the client MUST NOT 158 use the requested name until it has verified the validity of the 159 association between it and the IP address supplied in the yiaddr 160 field. Moreover, if the name returned in the DHCPACK is different 161 from the one requested, the client MUST use the new name. 163 A DHCP client MAY send either an unqualified or fully-qualified name 164 in the Host Name option. Clients sending unqualified names are 165 implicitly relying on DHCP servers to associate the clients with the 166 appropriate zones before issuing any updates to DNS. A DHCP client 167 in INIT state SHOULD fill in the requested host name in the DHCPDIS- 168 COVER packet. It MUST do so in its subsequent DHCPREQUEST packet. 170 Clients in states other than INIT SHOULD avoid ambiguity in their 171 requests by supplying the same Host Name option value on subsequent 172 DHCPREQUESTs as was supplied on their original (INIT state) DHCPRE- 173 QUEST. 175 A client that wishes to change its host name MAY request it by sup- 176 plying a Host Name option with the new name in a subsequent RENEW 177 request. As with the initial request, a client MUST NOT use the 178 newly-requested name until it has verified that it is now valid. 180 4.2 DHCP Server Considerations and Behavior 182 Use of the FQDN option makes it possible to easily separate update 183 operations into pieces corresponding to what are thought of as the 184 traditional ownership boundaries: DHCP servers own the addresses 185 they lease, while the clients own their names. This boundary is not 186 present when the Host Name option is used: the implied proxy update 187 request assumes that the DHCP server has sufficient privilege to 188 change both the A and PTR records. That is, it ``owns'' both. 190 For this and other reasons, use of the FQDN option is preferred: a 191 DHCP server that receives both a Host Name option and a client FQDN 192 option MUST prefer the FQDN option. In such a case, the server 193 SHOULD behave as if the Host Name option is not present. 195 A DHCP server MAY use the value of the Host Name option in a DHCPDIS- 196 COVER packet in some limited ways: it may check to see whether the 197 requested name belongs to an address that ls leaseable to the client, 198 saving the need for a DNS update, or it may begin preparation of an 199 update request. The server MUST wait for the DHCPREQUEST before ini- 200 tiating any update operations. 202 DNS updates may not complete in a timely manner, forcing the DHCP 203 server to reply to a client before the update has finished. Alterna- 204 tively, an error may be reported in response to the update request. 205 It is not possible to distinguish these cases for the client's bene- 206 fit, and the the DHCP server simply omits the Host Name option from 207 its DHCPACK. For simplicity of implementation, servers may choose to 208 ``orphan'' any outstanding requests, taking no note of subsequent 209 reports of success or failure. Servers that choose to keep track of 210 the results of update requests SHOULD use successful completion 211 reports to avoid subsequent unnecessary work; those servers SHOULD 212 ignore reports of soft, transitory errors. Hard errors SHOULD be 213 logged by the server so that corrective action, if any, may be taken 214 by an administrator. Servers MAY choose to not cache hard failures, 215 retrying on subsequent DHCPREQUESTs in the hope that the errors 216 logged have led to a remedy. 218 Issuing DNS updates on behalf of DHCP clients is an inherently state- 219 ful operation. A DHCP server MUST commit to stable storage the 220 necessary information regarding any updates it successfully makes on 221 behalf of its clients. This state may be needed 223 when a lease expires 225 when communicating with a failover partner 227 on subsequent lease renewals 229 and may need to be recovered when the server is restarted. 231 When a lease expires, a DHCP server MAY use this stored information 232 to expunge the name-to-address association it created on the client's 233 behalf. Because the use of the Host Name option cedes the ownership 234 of the name to the server, a server MAY instead choose to allow the 235 association to continue, saving itself work now and possibly sparing 236 the need for a future update. 238 A server SHOULD reevaluate the Host Name option each time a client 239 sends a RENEW request via a DHCPREQUEST, or the server MAY choose to 240 view the update request as an action to be taken once, upon initial 241 lease of an address. Servers that take the former view offer their 242 clients the possibility of changing the name associated with a 243 currently valid lease, but may incur additional processing costs 244 because of it. Servers taking the latter view do not afford clients 245 the opportunity to change names, but more importantly do not allow 246 them to retry failed requests, possibly even with different host 247 names. For this reason, the former behavior is preferred: servers 248 SHOULD reevaluate the Host Name option on each RENEW. 250 Some servers interpret a Host Name option on the initial DHCPREQUEST, 251 followed by the absence of the option on subsequent RENEW DHCPRE- 252 QUESTs as a request by the client to delete a name-to-address associ- 253 ation. Because clients that expect DNS updates to apply for the 254 duration of their leases may not send Host Name options when RENEW- 255 ing, servers should be cautious when interpreting the absence of the 256 option as a request for deletion of the association; if they choose 257 such behavior, servers SHOULD offer an administrative facility for 258 disabling it. Servers that do not normally operate in this manner 259 MAY similarly choose to offer an administrative facility to enable 260 it. 262 5. Security Considerations 264 Use of the Host Name option to petition DHCP servers to do proxy DNS 265 updates is undeniably convenient for the clients but it also opens 266 the door for denial of service attacks and identity impersonation. 267 Administrators MUST carefully evaluate the balance between offering 268 the convenience of proxy DNS updates and the attendant risks. 270 Clients using the Host Name option to request a DNS update will 271 likely lack a means of authenticating themselves (otherwise, they 272 might have dealt directly, and securely, with DNS). DHCP servers 273 SHOULD use all means at their disposal to verify the requests. Use 274 of DHCP Authentication ([8]) is far from common but other means, such 275 as previous authentication to a network access server via PPP or 276 proprietary controls such as exist in many broadband cable systems, 277 may be available. 279 A DHCP server must be prepared to arbitrate between multiple clients 280 that all claim the same fully-qualified name. It SHOULD give prefer- 281 ence to a client whose identity it can verify. Failing that, it MUST 282 use the method described in [9] to ensure that an association made on 283 behalf of one client is not inadvertently changed by another. 285 6. Normative References 287 [1] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor 288 Extensions", RFC 1533, October 1993. 289 [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor 290 Extensions", RFC 2132, March 1997. 291 [3] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates 292 in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. 293 [4] Bradner, S., "Key words for use in RFCs to indicate requirement 294 levels", RFC 2119, March 1997. 295 [6] Mockapetris, P., "Domain names - Implementation and Specifica- 296 tion", RFC 1035, November 1987. 297 [7] Stapp, M. and Rekhter, Y., "The DHCP Client FQDN Option", draft- 298 ietf-dhc-fqdn-option-05.txt, November 2002. 299 [8] Droms, R. and Arbaugh, W., "Authentication for DHCP Messages", 300 RFC 3118, June 2001. 301 [9] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients", 302 draft-ietf-dhc-ddns-resolution-05.txt, November 2002. 304 7. Informative References 306 [5] Mockapetris, P., "Domain names - Concepts and Facilities", RFC 307 1034, November 1987. 309 8. Author Information 311 Carl Smith 312 Sun Microsystems, Inc. 313 901 San Antonio Road 314 Palo Alto, CA 94043 315 USA 316 email: cs@Eng.Sun.COM 318 Ted Lemon 319 Nominum, Inc. 320 950 Charter Street 321 Redwood City, CA 94043 322 USA 323 email: Ted.Lemon@nominum.com 325 9. Expiration 327 This document will expire on September 3, 2003. 329 10. Full Copyright Statement 331 Copyright (C) The Internet Society (1999). All Rights Reserved. 333 This document and translations of it may be copied and furnished to 334 others, and derivative works that comment on or otherwise explain it 335 or assist in its implementation may be prepared, copied, published 336 and distributed, in whole or in part, without restriction of any 337 kind, provided that the above copyright notice and this paragraph are 338 included on all such copies and derivative works. However, this 339 document itself may not be modified in any way, such as by removing 340 the copyright notice or references to the Internet Society or other 341 Internet organizations, except as needed for the purpose of develop- 342 ing Internet standards in which case the procedures for copyrights 343 defined in the Internet Standards process must be followed, or as 344 required to translate it into languages other than English. 346 The limited permissions granted above are perpetual and will not be 347 revoked by the Internet Society or its successors or assigns. 349 This document and the information contained herein is provided on an 350 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 351 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 352 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 353 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 354 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.