idnits 2.17.1 draft-ietf-dhc-dhcp-dns-08.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 171: '...ient, then the client MUST include the...' RFC 2119 keyword, line 173: '...ld in the option MUST be set to 0. Onc...' RFC 2119 keyword, line 176: '...message), the client MUST originate an...' RFC 2119 keyword, line 178: '... MUST be originated following the procedures described in [RFC2136]....' RFC 2119 keyword, line 183: '...oice, the client MUST include the Clie...' (41 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 1998) is 9511 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) == Missing Reference: 'RFC1541' is mentioned on line 82, but not defined ** Obsolete undefined reference: RFC 1541 (Obsoleted by RFC 2131) == Unused Reference: 'RFC2131' is defined on line 364, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1594 (Obsoleted by RFC 2664) -- Possible downref: Non-RFC (?) normative reference: ref. 'DNSSEC' Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Yakov Rekhter 2 Internet Draft Cisco Systems 3 Expiration Date: September 1998 March 1998 5 Interaction between DHCP and DNS 6 draft-ietf-dhc-dhcp-dns-08.txt 8 1. Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 2. Abstract 28 DHCP provides a powerful mechanism for IP host autoconfiguration. 29 However, the autoconfiguration provided by DHCP does not include 30 updating DNS, and specifically updating the name to address and 31 address to name mappings maintained by DNS. 33 This document specifies how DHCP clients and servers should use the 34 Dynamic DNS Updates mechanism to update the DNS name to address and 35 address to name mapping, so that the mappings for DHCP clients would 36 be consistent with the IP addresses that the clients acquire via 37 DHCP. 39 3. Terminology 41 Throughout this document, the words that are used to define the 42 significance of particular requirements are capitalized. These words 43 are: 45 - "MUST" 46 This word or the adjective "REQUIRED" means that the item is an 47 absolute requirement of this specification. 49 - "MUST NOT" 50 This phrase means that the item is an absolute prohibition of 51 this specification. 53 - "SHOULD" 54 This word or the adjective "RECOMMENDED" means that there may 55 exist valid reasons in particular circumstances to ignore this 56 item, but the full implications should be understood and the 57 case carefully weighed before choosing a different course. 59 - "SHOULD NOT" 60 This phrase means that there may exist valid reasons in 61 particular circumstances when the listed behavior is acceptable 62 or even useful, but the full implications should be understood 63 and the case carefully weighed before implementing any behavior 64 described with this label. 66 - "MAY" 67 This word or the adjective "OPTIONAL" means that this item is 68 truly optional. One vendor may choose to include the item 69 because a particular marketplace requires it or because it 70 enhances the product, for example; another vendor may omit the 71 same item. 73 4. Interaction between DHCP and DNS 75 DNS [RFC1034, RFC1035] maintains (among other things) the information 76 about mapping between hosts' Fully Qualified Domain Names (FQDNs) 77 [RFC1594] and IP addresses assigned to the hosts. The information is 78 maintained in two types of Resource Records (RRs): A and PTR. The A 79 RR contains mapping from a FQDN to an IP address; the PTR RR contains 80 mapping from an IP address to a FQDN. 82 DHCP [RFC1541] provides a mechanism by which a host (a DHCP client) 83 could acquire certain configuration information, and specifically its 84 IP address(es). However, DHCP does not provide any mechanisms to 85 update the DNS RRs that contain the information about mapping between 86 the host's FQDN and its IP address(es) (A and PTR RRs). Thus the 87 information maintained by DNS for a DHCP client may be incorrect - a 88 host (the client) could acquire its address by using DHCP, but the A 89 RR for the host's FQDN wouldn't reflect the address that the host 90 acquired, and the PTR RR for the acquired address wouldn't reflect 91 the host's FQDN. 93 Dynamic DNS Updates [RFC2136] is a mechanism that enables DNS 94 information to be updated over a network. 96 The Dynamic DNS Update protocol can be used to maintain consistency 97 between the information stored in the A and PTR RRs and the actual 98 address assignment done via DHCP. When a host with a particular FQDN 99 acquires its IP address via DHCP, the A RR associated with the host's 100 FQDN would be updated (by using the Dynamic DNS Updates protocol) to 101 reflect the new address. Likewise, when an IP address gets assigned 102 to a host with a particular FQDN, the PTR RR associated with this 103 address would be updated (using the Dynamic DNS Updates protocol) to 104 reflect the new FQDN. 106 5. Models of operations 108 When a DHCP client acquires a new address, both the A RR (for the 109 client's FQDN) and the PTR RR (for the acquired address) have to be 110 updated. Therefore, we have two separate Dynamic DNS Update 111 transactions. Acquiring an address via DHCP involves two entities: a 112 DHCP client and a DHCP server. In principle each of these entities 113 could perform none, one, or both of the transactions. However, upon 114 some introspection one could realize that not all permutations make 115 sense. This document covers the possible design permutations: 117 (1) DHCP client updates the A RR, DHCP server updates the PTR 118 RR 120 (2) DHCP server updates both the A and the PTR RRs 122 One could observe that the only difference between these two cases is 123 whether the FQDN to IP address mapping is updated by a DHCP client or 124 by a DHCP server. The IP address to FQDN mapping is updated by a DHCP 125 server in both cases. 127 The reason these two are important, while others are unlikely, has to 128 do with authority over the respective DNS RRs. A client may be given 129 authority over mapping it's own A RRs, or that may be restricted to a 130 server to prevent the client from listing arbitrary addresses. In 131 all cases, the only reasonable place for the authority over the PTR 132 RRs associated with the address is in the DHCP server that allocates 133 them. 135 5.1. Client FQDN Option 137 To update the IP address to FQDN mapping a DHCP server needs to know 138 FQDN of the client to which the server leases the address. To allow 139 the client to convey its FQDN to the server this document defines a 140 new option, called "Client FQDN". 142 The code for this option is 81. Its minimum length is 4. 144 Code Len Flags RCODE1 RCODE2 Domain Name 145 +------+------+------+------+------+------+-- 146 | 81 | n | | | | ... 147 +------+------+------+------+------+------+-- 149 The Flags field allows a DHCP client to indicate to a DHCP server 150 whether (a) the client wants to be responsible for updating the FQDN 151 to IP address mapping (if Flags is set to 0), or (b) the client wants 152 the server to be responsible for updating the FQDN to IP address 153 mapping (if Flags is set to 1). The Flags field also allows a DHCP 154 server to indicate to a DHCP client that the server assumes the 155 responsibility for updating the FQDN to IP address mapping, even if 156 the client wants to be responsible for this update (if Flags is set 157 to 3). 159 The RCODE1 and RCODE2 fields are used by a DHCP server to indicate to 160 a DHCP client the Response Code from Dynamic DNS Updates. 162 The Domain Name part of the option carries FQDN of a client. 164 5.2. DHCP Client behavior 166 The following describes behavior of a DHCP client that implements the 167 Client FQDN option. 169 If a client that owns/maintains is own FQDN wants to be responsible 170 for updating the FQDN to IP address mapping for the FQDN and 171 address(es) used by the client, then the client MUST include the 172 Client FQDN option in the DHCPREQUEST message originated by the 173 client. The Flags field in the option MUST be set to 0. Once the 174 client's DHCP configuration is completed (the client receives a 175 DHCPACK message, and successfully completed a final check on the 176 parameters passed in the message), the client MUST originate an 177 update for the A RR (associated with the client's FQDN). The update 178 MUST be originated following the procedures described in [RFC2136]. 180 A client that owns/maintains its own FQDN can choose to delegate the 181 responsibility for updating the FQDN to IP address mapping for the 182 FQDN and address(es) used by the client to the server. In order to 183 inform the server of this choice, the client MUST include the Client 184 FQDN option in the DHCPREQUEST message originated by the client. The 185 Flags field in the option MUST be set to 1. In this case, the client 186 MAY supply an FQDN in the Client FQDN option, or it MAY leave that 187 field empty as a signal to the server to determine an FQDN for the 188 client in any manner the server chooses. 190 A client that delegates the responsibility for updating the FQDN to 191 IP address mapping to a server MAY not receive any indications 192 (either positive or negative) from the server whether the server was 193 able to perform the update. In this case the client SHOULD use DNS 194 query to check whether the mapping is updated. 196 A client MUST set the RCODE1 and RCODE2 fields in the Client FQDN 197 option to 0 when sending the option. 199 If a client releases its address lease prior to the lease expiration 200 time, and the client is responsible for updating its A RR(s), the 201 client SHOULD delete the A RR (following the procedures described in 202 [RFC2136]) associated with the leased address before sending DHCP 203 RELEASE message. 205 5.3. DHCP Server behavior 207 When a server receives a DHCPREQUEST message from a client, if the 208 message contains the Client FQDN option, and the server replies to 209 the message with a DHCPACK message, the server SHOULD originate an 210 update for the PTR RR (associated with the address leased to the 211 client). The update MUST be originated following the procedures 212 described in Section 5.4. The server MAY complete the update before 213 the server sends the DHCPACK message to the client. In this case the 214 RCODE from the update [RFC2136] MUST be carried to the client in the 215 RCODE1 field of the Client FQDN option in the DHCPACK message and the 216 RCODE2 field MUST be set to 0. Alternatively, the server MAY send the 217 DHCPACK message to the client without waiting for the update to be 218 completed. In this case the RCODE1 field of the Client FQDN option 219 in the DHCPACK message MUST be set to 255, and the RCODE2 field MUST 220 be set to 0. The choice between the two alternatives is a local to a 221 DHCP server matter. 223 In addition, if the Client FQDN option carried in the DHCPREQUEST 224 message has its Flags field set to 1, then the server MUST originate 225 an update for the A RR (associated with the FQDN carried in the 226 option). The update MUST be originated following the procedures 227 described in Section 5.4. The server MAY originate the update before 228 the server sends the DHCPACK message to the client. In this case the 229 RCODE from the update [RFC2136] MUST be carried to the client in the 230 RCODE2 field of the Client FQDN option in the DHCPACK message. 231 Alternatively the server MAY send the DHCPACK message to the client 232 without waiting for the update to be completed. In this case the 233 RCODE2 field of the Client FQDN option in the DHCKACK message MUST be 234 set to 255. The choice between the two alternatives is a local to the 235 server matter. 237 Even, if the Client FQDN option carried in the DHCPREQUEST message 238 has its Flags field set to 0 (indicating that the client wants to 239 update the A RR), the server MAY (under configuration control) update 240 the A RR. The update MUST be originated following the procedures 241 described in Section 5.4. The server MAY originate the update before 242 the server sends the DHCPACK message to the client. In this case the 243 RCODE from the update [RFC2136] MUST be carried to the client in the 244 RCODE2 field of the Client FQDN option in the DHCPACK message, and 245 the Flags field in the Client FQND option MUST be set to 3. 246 Alternatively, the server MAY send the DHCPACK message to the client 247 without waiting for the update to be completed. In this case the 248 RCODE2 field of the Client FQDN option in the DHCKACK message MUST be 249 set to 255, and the Flags field in the Client FQDN option MUST be set 250 to 3. The choice between the two alternatives is a local to the 251 server matter. 253 When a server receives a DHCPREQUEST message from a client, and the 254 message contains the Client FQDN option, the server MUST ignore the 255 value carried in the RCODE1 and RCODE2 fields of the option. 257 When a DHCP server sends the Client FQDN option to a client in the 258 DHCPACK message, the server MUST copy the Domain Name fields from the 259 Client FQDN option that the client sent to the server in the 260 DHCPREQUEST message. 262 If the DHCPREQUST message received by a DHCP server from a DHCP 263 client doesn't carry the Client FQDN option (e.g., the client doesn't 264 implement the Client FQDN option), and the DHCP client acquires its 265 FQDN from a DHCP server (as part of a normal DHCP transaction), then 266 the server MAY be configured to update both A and PTR RRs. The 267 updates MUST be originated following the procedures described in 268 Section 5.4. 270 If a server originates updates for both the A and PTR RRs, then the 271 order in which the updates are generated is not significant. 273 If a server detects that a lease on an address that the server leases 274 to a client expires, the server SHOULD delete the PTR RR associated 275 with the address. In addition, if the A RR (of the client) was 276 initially updated by the server, the server SHOULD also delete the A 277 RR. The deletion MUST follow the procedures described in [RFC2136]. 279 If a server terminates a lease on an address prior to the lease 280 expiration time, the server SHOULD delete the PTR RR associated with 281 the address. In addition, if the server (that leased the address) 282 initially updated the A RR (of the client), the server SHOULD also 283 delete the A RR. The deletion MUST follow the procedures described in 284 [RFC2136]. 286 5.4. Procedures for performing DNS updates 288 When a DHCP server needs to update the PTR RR for a particular IP 289 address, the server just adds a new PTR RR for that address. 291 When a DHCP server needs to update the A RR for a particular FQDN, 292 the server first has to delete all the A RRs associated with that 293 FQDN, and then add a new A RR for that FQDN. Note that this rule 294 precludes the ability to support multi-homed hosts in the scenario 295 where A RRs are updated by a DHCP server. Therefore, multi-homed 296 hosts SHOULD perform updates to their A RRs by themselves. 298 Procedures for deleting and adding RRs are described in [RFC2136]. 300 6. Updating other RRs 302 The procedures described in this document cover updates only to the A 303 and PTR RRs. Updating other types of RRs is outside the scope of this 304 document. 306 7. Security Considerations 308 Whether the client wants to be responsible for updating the FQDN to 309 IP address mapping, or whether the client wants to delegate this 310 responsibility to a server is a local to the client matter. The 311 choice between the two alternatives may be based on a particular 312 security model that is used with the Dynamic DNS Update protocol 313 (e.g., only a client may have sufficient credentials to perform 314 updates to the FQDN to IP address mapping for its FQDN). 316 Whether a DHCP server is always responsible for updating the FQDN to 317 IP address mapping (in addition to updating the IP to FQDN mapping), 318 regarless of the wishes of a DHCP client, is a local to the server 319 matter. The choice between the two alternatives may be based on a 320 particular security model. 322 The client SHOULD use some form of data origin authentication 323 procedures (e.g., DNSSEC [DNSSEC]) when performing DNS updates. 325 While the DHCP client SHOULD be the one to update the DNS A record, 326 in certain specialized cases a DHCP server MAY do so instead. In 327 this case, the DHCP server MUST be sure of both the name to use for 328 the client, as well as the identity of the client. 330 In the general case, both of these conditions are not satisfied -- 331 one needs to be mindful of the possibility of MAC address spoofing in 332 a DHCP packet. It is not difficult for a DHCP server to know 333 unambiguously the DNS name to use for a client, but only in certain 334 relatively unusual circumstances will the DHCP server know for sure 335 the identity of the client. One example of such a circumstance is 336 where the DHCP client is connected to a network through an MCNS cable 337 modem, and the CMTS (head-end) of the cable modem ensures that MAC 338 address spoofing simply does not occur. 340 Another example where the DHCP server would know the identity of the 341 client would be in a case where it was interacting with a remote 342 access server which encoded a client identification into the DHCP 343 client-id option. In this case, the remote access server as well as 344 the DHCP server would be operating within a trusted environment, and 345 the DHCP server could trust that the user authentication and 346 authorization procedure of the remote access server was sufficient, 347 and would therefore trust the client identification encoded within 348 the DHCP client-id. 350 In either of these cases, a DHCP server would be able to correctly 351 enter the DNS A record on behalf of a client, since it would know the 352 name associated with a client (through some administrative procedure 353 outside the scope of this protocol), and it would also know the 354 client's identity in a secure manner. 356 8. References 358 [RFC1034] P. Mockapetris, "Domain names - concepts and facilities", 359 RFC1034, 11/01/1987 361 [RFC1035] P. Mockapetris, "Domain names - implementation and 362 specification", RFC1035, 11/01/1987 364 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131, 365 March 1997 367 [RFC1594] A. Marine, J. Reynolds, G. Malkin, "FYI on Questions and 368 Answer Answers to Commonly asked ``New Internet User'' Questions", 369 RFC1594, 03/11/1994 371 [DNSSEC] 373 [RFC2136] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic 374 Updates in the Domain Name System (DNS UPDATE)", RFC2136, April 1997 376 9. Acknowledgements 378 Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Peter Ford, Edie 379 Gunter, Kim Kinnear, Stuart Kwan, Ted Lemon, Michael Lewis, Michael 380 Patton, Mark Stapp, and Glenn Stump for their review and comments. 382 10. Author Information 384 Yakov Rekhter 385 cisco Systems, Inc. 386 170 Tasman Dr. 387 San Jose, CA 95134 388 Phone: (914) 235-2128 389 email: yakov@cisco.com