idnits 2.17.1 draft-ietf-dhc-dhcp-dns-05.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-04-25) 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 7 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. 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 (November 1997) is 9658 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 1541 (Obsoleted by RFC 2131) ** Obsolete normative reference: RFC 1594 (Obsoleted by RFC 2664) Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yakov Rekhter 3 Internet Draft Cisco Systems 4 Expiration Date: May 1998 November 1997 6 Interaction between DHCP and DNS 7 draft-ietf-dhc-dhcp-dns-05.txt 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 2. Abstract 29 DHCP provides a powerful mechanism for IP host autoconfiguration. 30 However, the autoconfiguration provided by DHCP does not include 31 updating DNS, and specifically updating the name to address and 32 address to name mappings maintained by DNS. 34 This document specifies how DHCP clients and servers should use the 35 Dynamic DNS Updates mechanism to update the DNS name to address and 36 address to name mapping, so that the mappings for DHCP clients would 37 be consistent with the IP addresses that the clients acquire via 38 DHCP. 40 3. Interaction between DHCP and DNS 42 DNS [RFC1034, RFC1035] maintains (among other things) the information 43 about mapping between hosts' Fully Qualified Domain Names (FQDNs) 44 [RFC1594] and IP addresses assigned to the hosts. The information is 45 maintained in two types of Resource Records (RRs): A and PTR. The A 46 RR contains mapping from a FQDN to an IP address; the PTR RR contains 47 mapping from an IP address to a FQDN. 49 DHCP [RFC1541] provides a mechanism by which a host (a DHCP client) 50 could acquire certain configuration information, and specifically its 51 IP address(es). However, DHCP does not provide any mechanisms to 52 update the DNS RRs that contain the information about mapping between 53 the host's FQDN and its IP address(es) (A and PTR RRs). Thus the 54 information maintained by DNS for a DHCP client may be incorrect - a 55 host (the client) could acquire its address by using DHCP, but the A 56 RR for the host's FQDN wouldn't reflect the address that the host 57 acquired, and the PTR RR for the acquired address wouldn't reflect 58 the host's FQDN. 60 Dynamic DNS Updates [DynDNS] is a mechanism that enables DNS 61 information to be updated DNS over a network. 63 The Dynamic DNS Update protocol can be used to maintain consistency 64 between the information stored in the A and PTR RRs and the actual 65 address assignment done via DHCP. When a host with a particular FQDN 66 acquires its IP address via DHCP, the A RR associated with the host's 67 FQDN would be updated (by using the Dynamic DNS Updates protocol) to 68 reflect the new address. Likewise, when an IP address gets assigned 69 to a host with a particular FQDN, the PTR RR associated with this 70 address would be updated (using the Dynamic DNS Updates protocol) to 71 reflect the new FQDN. 73 4. Models of operations 75 When a DHCP client acquires a new address, both the A RR (for the 76 client's FQDN) and the PTR RR (for the acquired address) have to be 77 updated. Therefore, we have two separate Dynamic DNS Update 78 transactions. Acquiring an address via DHCP involves two entities: a 79 DHCP client and a DHCP server. In principle each of these entities 80 could perform none, one, or both of the transactions. However, upon 81 some introspection one could realize that not all permutations make 82 sense. This document covers the possible design permutations: 84 (1) DHCP client updates the A RR, DHCP server updates the PTR 85 RR 86 (2) DHCP server updates both the A and the PTR RRs 88 One could observe that the only difference between these two cases is 89 whether the FQDN to IP address mapping is updated by a DHCP client or 90 by a DHCP server. The IP address to FQDN mapping is updated by a DHCP 91 server in both cases. 93 4.1. Client FQDN Option 95 To update the IP address to FQDN mapping a DHCP server needs to know 96 FQDN of the client to which the server leases the address. To allow 97 the client to convey its FQDN to the server this document defines a 98 new option, called "Client FQDN". 100 The code for this option is 81. Its minimum length is 4. 102 Code Len Flags RCODE1 RCODE2 Domain Name 103 +------+------+------+------+------+------+-- 104 | 81 | n | | | | ... 105 +------+------+------+------+------+------+-- 107 The Flags field allows a DHCP client to indicate to a DHCP server 108 whether (a) the client wants to be responsible for updating the FQDN 109 to IP address mapping (if Flags is set to 0), or (b) the client wants 110 the server to be responsible for updating the FQDN to IP address 111 mapping (if Flags is set to 1). The Flags field also allows a DHCP 112 server to indicate to a DHCP client that the server assumes the 113 responsibility for updating the FQDN to IP address mapping, even if 114 the client wants to be responsible for this update (if Flags is set 115 to 3). 117 The RCODE1 and RCODE2 fields are used by a DHCP server to indicate to 118 a DHCP client the Response Code from Dynamic DNS Updates. 120 The Domain Name part of the option carries FQDN of a client. 122 4.2. DHCP Client behavior 124 If a client wants to be responsible for updating the FQDN to IP 125 address mapping for the FQDN and address(es) used by the client, then 126 the client shall include the Client FQDN option in the DHCPREQUEST 127 message originated by the client. The Flags field in the option shall 128 be set to 0. Once the client's DHCP configuration is completed (the 129 client receives a DHCPACK message, and successfully completed a final 130 check on the parameters passed in the message), the client shall 131 originate an update for the A RR (associated with the client's FQDN). 132 The update shall be originated following the procedures described in 133 [DynDNS]. 135 If a client does not want to be responsible for updating the FQDN to 136 IP address mapping for the FQDN and address(es) used by the client, 137 then the client shall include the Client FQDN option in the 138 DHCPREQUEST message originated by the client. The Flags field in the 139 option shall be set to 1. 141 A client that delegates the responsibility for updating the FQDN to 142 IP address mapping to a server may not receive any indications 143 (either positive or negative) from the server whether the server was 144 able to perform the update. In this case the client may use DNS query 145 to check whether the mapping is updated. 147 A client should set the RCODE1 and RCODE2 fields in the Client FQDN 148 option to 0 when sending the option. 150 Whether the client wants to be responsible for updating the FQDN to 151 IP address mapping, or whether the client wants to delegate this 152 responsibility to a server is a local to the client matter. The 153 choice between the two alternatives may be based on a particular 154 security model that is used with the Dynamic DNS Update protocol 155 (e.g., only a client may have sufficient credentials to perform 156 updates to the FQDN to IP address mapping for its FQDN). 158 If a client releases its address lease prior to the lease expiration 159 time, and the client is responsible for updating its A RR(s), the 160 client should delete the A RR (following the procedures described in 161 [DynDNS]) associated with the leased address before sending DHCP 162 RELEASE message. 164 4.3. DHCP Server behavior 166 When a server receives a DHCPREQUEST message from a client, if the 167 message contains the Client FQDN option, and the server replies to 168 the message with a DHCPACK message, the server may originate an 169 update for the PTR RR (associated with the address leased to the 170 client). The update shall be originated following the procedures 171 described in Section 4.4. The server may originate the update before 172 the server sends the DHCPACK message to the client. In this case the 173 RCODE from the update [DynDNS] shall be carried to the client in the 174 RCODE1 field of the Client FQDN option in the DHCPACK message and the 175 RCODE2 field shall be set to 0. Alternatively, the server may send 176 the DHCPACK message to the client without waiting for the update to 177 be completed. In this case the RCODE1 field of the Client FQDN 178 option in the DHCPACK message shall be set to 255, and the RCODE2 179 field shall be set to 0. The choice between the two alternatives is 180 a local to a DHCP server matter. 182 In addition, if the Client FQDN option carried in the DHCPREQUEST 183 message has its Flags field set to 1, then the server shall originate 184 an update for the A RR (associated with the FQDN carried in the 185 option). The update shall be originated following the procedures 186 described in Section 4.4. The server may originate the update before 187 the server sends the DHCPACK message to the client. In this case the 188 RCODE from the update [DynDNS] shall be carried to the client in the 189 RCODE2 field of the Client FQDN option in the DHCPACK message. 190 Alternatively the server may send the DHCPACK message to the client 191 without waiting for the update to be completed. In this case the 192 RCODE2 field of the Client FQDN option in the DHCKACK message shall 193 be set to 255. The choice between the two alternatives is a local to 194 the server matter. 196 Even, if the Client FQDN option carried in the DHCPREQUEST message 197 has its Flags field set to 0 (indicating that the client wants to 198 update the A RR), the server could (under configuration control) 199 update the A RR. The update shall be originated following the 200 procedures described in Section 4.4. The server may originate the 201 update before the server sends the DHCPACK message to the client. In 202 this case the RCODE from the update [DynDNS] shall be carried to the 203 client in the RCODE2 field of the Client FQDN option in the DHCPACK 204 message, and the Flags field in the Client FQND option shall be set 205 to 3. Alternatively, the server may send the DHCPACK message to the 206 client without waiting for the update to be completed. In this case 207 the RCODE2 field of the Client FQDN option in the DHCKACK message 208 shall be set to 255, and the Flags field in the Client FQDN option 209 shall be set to 3. The choice between the two alternatives is a local 210 to the server matter. 212 Whether a DHCP server is always responsible for updating the FQDN to 213 IP address mapping (in addition to updating the IP to FQDN mapping), 214 regarless of the wishes of a DHCP client, is a local to the server 215 matter. The choice between the two alternatives may be based on a 216 particular security model. 218 When a server receives a DHCPREQUEST message from a client, and the 219 message contains the Client FQDN option, the server shall ignore the 220 value carried in the RCODE1 and RCODE2 fields of the option. 222 When a DHCP server sends the Client FQDN option to a client in the 223 DHCPACK message, the server shall copy the Domain Name fields from 224 the Client FQDN option that the client sent to the server in the 225 DHCPREQUEST message. 227 If the DHCPREQUST message received by a DHCP server from a DHCP 228 client doesn't carry the Client FQDN option, and the DHCP client 229 acquires its FQDN from a DHCP server (as part of a normal DHCP 230 transaction), then the server may be configured to update both A and 231 PTR RRs. In this scenario the DHCPOFFER message originated by the 232 server shall carry the Domain Name option, and the client 233 acknowledges the use of the FQDN carried in this option by including 234 the option (with the FQDN) in the DHCPREQUEST originated by the 235 client. The updates shall be originated following the procedures 236 described in Section 4.4. 238 If a server originates updates for both the A and PTR RRs, then the 239 order in which the updates are generated is not significant. 241 If a server detects that a lease on an address that the server leases 242 to a client expires, the server should delete the PTR RR associated 243 with the address. In addition, if the client authorized the server to 244 update its A RR, the server should also delete the A RR. The deletion 245 should follow the procedures described in [DynDNS]. 247 If a server terminates a lease on an address prior to the lease 248 expiration time, the server should delete the PTR RR associated with 249 the address. In addition, if the client (that leased the address) 250 authorized the server to update its A RR, the server should also 251 delete the A RR. The deletion should follow the procedures described 252 in [DynDNS]. 254 4.4. Procedures for performing DNS updates 256 When a DHCP server needs to update the PTR RR for a particular IP 257 address, the server just adds a new PTR RR for that address. 259 When a DHCP server needs to update the A RR for a particular FQDN, 260 the server first has to delete all the A RRs associated with that 261 FQDN, and then add a new A RR for that FQDN. Note that this rule 262 precludes the ability to support multi-homed hosts in the scenario 263 where A RRs are updated by a DHCP server. Therefore, multi-homed 264 hosts should perform updates to their A RRs by themselves. 266 Procedures for deleting and adding RRs are described in [DynDNS]. 268 5. Updating other RRs 270 The procedures described in this document cover updates only to the A 271 and PTR RRs. Updating other types of RRs is outside the scope of this 272 document. 274 6. Security Considerations 276 Security issues are not discussed in this document. 278 7. References 280 [RFC1034] P. Mockapetris, "Domain names - concepts and facilities", 281 RFC1034, 11/01/1987 283 [RFC1035] P. Mockapetris, "Domain names - implementation and 284 specification", RFC1035, 11/01/1987 286 [RFC1541] R. Droms, "Dynamic Host Configuration Protocol", RFC1541, 287 10/27/1993 289 [RFC1594] A. Marine, J. Reynolds, G. Malkin, "FYI on Questions and 290 Answer Answers to Commonly asked ``New Internet User'' Questions", 291 RFC1594, 03/11/1994 293 [DynDNS] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates 294 in the Domain Name System (DNS UPDATE)", RFC2136, April 1997 296 8. Acknowledgements 298 Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Peter Ford, Edie 299 Gunter, Stuart Kwan, Ted Lemon, Michael Lewis, Michael Patton, Mark 300 Stapp, and Glenn Stump for their review and comments. 302 9. Author Information 304 Yakov Rekhter 305 cisco Systems, Inc. 306 170 Tasman Dr. 307 San Jose, CA 95134 308 Phone: (914) 235-2128 309 email: yakov@cisco.com