idnits 2.17.1 draft-ietf-dhc-host-option-considerations-00.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. == 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 a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == 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 == 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 (August 2002) is 7925 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-03 Summary: 6 errors (**), 0 flaws (~~), 5 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 February 2002 7 Expires August 2002 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 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 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 49 RFC DRAFT February 2002 51 ability to easily update Domain Name Service information [3] has 52 encouraged the use of this option by DHCP clients as a way to request 53 that DHCP servers issue proxy DNS updates on their behalf. Lack of a 54 document describing its exact usage has led, as one would surely 55 expect, to interoperability problems. It is the purpose of this 56 document to outline the expectations that clients and servers should 57 have when using the Host Name option. 59 2. Definitions 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119 [4]. This 64 document also uses the following terms: 66 "DHCP client" 68 DHCP client or "client" is an Internet host using DHCP to 69 obtain configuration parameters such as a network address. 71 "DHCP server" 73 A DHCP server or "server" is an Internet host that returns 74 configuration parameters to DHCP clients. 76 "FQDN" 78 A fully-qualified name, including the host part and Domain Name 79 system domain. 81 3. Interactions with Name Services 83 A DHCP client's use of the Host Name option should be fairly 84 straightforward, but users report problems, particularly with the 85 interactions between it and Domain Name option and between the DNS 86 (RFC 1034 [5] and RFC 1035 [6]) and other naming services so we 87 reiterate and expand the description of the expected behavior: 89 if a DHCP server supplies both Host Name and Domain Name options 90 to a client, the host name SHOULD NOT be fully-qualified 92 if a DHCP server supplies only a Host Name option, the host name 93 SHOULD be fully qualified; the server MUST append only DNS domain 94 names in forming a fully-qualified name 96 a client MUST check to see whether a Host Name option contains a 97 fully-qualified name and if so, MUST NOT append the value of the 98 Domain Name option (if present) in forming its fully-qualified 100 RFC DRAFT February 2002 102 domain name 104 since a Host Name option's value may be fully-qualified only by 105 supplying the DNS domain name, a client that receives a fully- 106 qualified name in the Host Name option MAY infer the DNS domain 107 name from the suffix of the supplied host name. This inference 108 remains valid even in the presence of client configuration infor- 109 mation or policies that prefer other name services in favor of, or 110 in place of, DNS. 112 4. DNS Updates for DHCP Clients 114 DNS maintains Resource Records (RRs) for mapping between IP addresses 115 FQDNs. Specifically, A records map FQDNs to IP addresses and PTR 116 records map IP addresses to FQDNs. Several options are available to 117 DHCP clients interested in updating A and PTR records: 119 issuing direct updates to DNS 121 using the DHCP client FQDN option [7] 123 using the DHCP Host Name option 125 Either of the first two methods has the advantage of offering the 126 client a number of approaches for fine-tuning DNS update requests as 127 well as direct feedback on the success or failure of the intended 128 operations. Both are to be preferred over the latter: use of the 129 Host Name option does not even guarantee that the DHCP server will 130 attempt any DNS updates on a client's behalf. Nevertheless, support 131 for this method of requesting proxy DNS updates is widespread and it 132 may be viewed as appropriate for situations in which there are no 133 requirements for other finely-tunable methods. 135 4.1 DHCP Client Considerations and Behavior 137 A DHCP client that uses the Host Name option to request a DNS update 138 MUST be prepared to independently verify the success or failure of 139 the request before using the name in a manner that would imply its 140 validity. If a DHCP server returns the requested name in the 141 DHCPACK's Host Name option, the client MAY infer that the server has 142 honored its request. 144 There are a number of reasons that a DHCP server may fail to return a 145 Host Name option, so nothing should be inferred from the option's 146 absence in the DHCPACK. The client MAY supply the option on subse- 147 quent RENEW operations as a method of retrying the request. However, 148 if the Host Name option is absent in the DHCPACK, the client MUST NOT 149 use the requested name until it has verified the validity of the 151 RFC DRAFT February 2002 153 association between it and the IP address supplied in the yiaddr 154 field. Moreover, if the name returned in the DHCPACK is different 155 from the one requested, the client MUST use the new name. 157 A DHCP client MAY send either an unqualified or fully-qualified name 158 in the Host Name option. Clients sending unqualified names are 159 implicitly relying on DHCP servers to associate the clients with the 160 appropriate zone before issuing any updates to DNS. A DHCP client in 161 INIT state SHOULD fill in the requested host name in the DHCPDISCOVER 162 packet. It MUST do so in its subsequent DHCPREQUEST packet. 164 Clients in states other than INIT SHOULD avoid ambiguity in their 165 requests by supplying the same Host Name option value on subsequent 166 DHCPREQUESTs as was supplied on their original (INIT state) DHCPRE- 167 QUEST. 169 A client that wishes to change its host name MAY request it by sup- 170 plying a Host Name option with the new name in a subsequent RENEW 171 request. As with the initial request, a client MUST NOT use the 172 newly-requested name until it has verified that it is now valid. 174 4.2 DHCP Server Considerations and Behavior 176 Use of the FQDN option makes it possible to easily separate update 177 operations into pieces corresponding to what are thought of as the 178 traditional ownership boundaries: DHCP servers own the addresses 179 they lease, while the clients own their names. This boundary is not 180 present when the Host Name option is used: the implied proxy update 181 request assumes that the DHCP server has sufficient privilege to 182 change both the A and PTR records. That is, it ``owns'' both. 184 For this and other reasons, use of the FQDN option is preferred: a 185 DHCP server that receives both a Host Name option and a client FQDN 186 option MUST prefer the FQDN option. In such a case, the server 187 SHOULD behave as if the Host Name option is not present. 189 A DHCP server MAY use the value of the Host Name option in a DHCPDIS- 190 COVER packet in some limited ways: it may check to see whether the 191 requested name belongs to an address that ls leaseable to the client, 192 saving the need for a DNS update, or it may begin preparation of an 193 update request. The server MUST wait for the DHCPREQUEST before ini- 194 tiating any update operations. 196 DNS updates may not complete in a timely manner, forcing the DHCP 197 server to reply to a client before the update has finished. Alterna- 198 tively, an error may be reported in response to the update request. 199 It is not possible to distinguish these cases for the client's bene- 200 fit, and the the DHCP server simply omits the Host Name option from 202 RFC DRAFT February 2002 204 its DHCPACK. For simplicity of implementation, servers may choose to 205 ``orphan'' any outstanding requests, taking no note of subsequent 206 reports of success or failure. Servers that choose to keep track of 207 the results of update requests SHOULD use successful completion 208 reports to avoid subsequent unnecessary work; those servers SHOULD 209 ignore reports of soft, transitory errors. Hard errors SHOULD be 210 logged by the server so that corrective action, if any, may be taken 211 by an administrator. Servers MAY choose to not cache hard failures, 212 retrying on subsequent DHCPREQUESTs in the hope that the errors 213 logged have led to a remedy. 215 Issuing DNS updates on behalf of DHCP clients is an inherently state- 216 ful operation. A DHCP server MUST commit to stable storage the 217 necessary information regarding any updates it successfully makes on 218 behalf of its clients. This state may be needed 220 when a lease expires 222 when communicating with a failover partner 224 on subsequent lease renewals 226 and may need to be recovered when the server is restarted. 228 When a lease expires, a DHCP server MAY use this stored information 229 to expunge the name-to-address association it created on the client's 230 behalf. Because the use of the Host Name option cedes the ownership 231 of the name to the server, a server MAY instead choose to allow the 232 association to continue, saving itself work now and possibly sparing 233 the need for a future update. 235 A server MAY choose to reevaluate the Host Name option each time a 236 client sends a RENEW request via a DHCPREQUEST, or the server MAY 237 choose to view the update request as an action to be taken once, upon 238 initial lease of an address. Servers that take the former view offer 239 their clients the possibility of changing the name associated with a 240 currently valid lease, but may incur additional processing costs 241 because of it. Servers taking the latter view do not afford clients 242 the opportunity to change names, but more importantly do not allow 243 them to retry failed requests, possibly even with different host 244 names. For this reason, the former behavior is preferred: servers 245 SHOULD reevaluate the Host Name option on each RENEW. 247 Some servers interpret a Host Name option on the initial DHCPREQUEST, 248 followed by the absence of the option on subsequent RENEW DHCPRE- 249 QUESTs as a request by the client to delete a name-to-address associ- 250 ation. Here we invoke the principle of least surprise: it is more 251 reasonable for a client to expect that DNS updates apply for the 253 RFC DRAFT February 2002 255 duration of a lease than it is to expect that a client will wish to 256 delete an update but retain the lease. Because clients that expect 257 DNS updates to apply for the duration of a lease may not send a Host 258 Name option when RENEWing, servers SHOULD NOT interpret the absence 259 of the option as a request for deletion of the association. 261 5. References 263 [1] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor 264 Extensions", RFC 1533, October 1993. 265 [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor 266 Extensions", RFC 2132, March 1997. 267 [3] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates 268 in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. 269 [4] Bradner, S., "Key words for use in RFCs to indicate requirement 270 levels", RFC 2119, March 1997. 271 [5] Mockapetris, P., "Domain names - Concepts and Facilities", RFC 272 1034, November 1987. 273 [6] Mockapetris, P., "Domain names - Implementation and Specifica- 274 tion", RFC 1035, November 1987. 275 [7] Stapp, M. and Rekhter, Y., "The DHCP Client FQDN Option", draft- 276 ietf-dhc-fqdn-option-03.txt, November 2001. 278 6. Author Information 280 Carl Smith 281 Sun Microsystems, Inc. 282 901 San Antonio Road 283 Palo Alto, CA 94043 284 USA 285 email: cs@Eng.Sun.COM 287 Ted Lemon 288 Nominum, Inc. 289 950 Charter Street 290 Redwood City, CA 94043 291 USA 292 email: Ted.Lemon@nominum.com 294 7. Expiration 296 This document will expire on August 22, 2002. 298 8. Full Copyright Statement 300 Copyright (C) The Internet Society (1999). All Rights Reserved. 302 This document and translations of it may be copied and furnished to 304 RFC DRAFT February 2002 306 others, and derivative works that comment on or otherwise explain it 307 or assist in its implementation may be prepared, copied, published 308 and distributed, in whole or in part, without restriction of any 309 kind, provided that the above copyright notice and this paragraph are 310 included on all such copies and derivative works. However, this 311 document itself may not be modified in any way, such as by removing 312 the copyright notice or references to the Internet Society or other 313 Internet organizations, except as needed for the purpose of develop- 314 ing Internet standards in which case the procedures for copyrights 315 defined in the Internet Standards process must be followed, or as 316 required to translate it into languages other than English. 318 The limited permissions granted above are perpetual and will not be 319 revoked by the Internet Society or its successors or assigns. 321 This document and the information contained herein is provided on an 322 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 323 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 324 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 325 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 326 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.