idnits 2.17.1 draft-ietf-dhc-dhcp-dns-03.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 6 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 (March 1997) is 9903 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) == Outdated reference: A later version (-10) exists of draft-ietf-dnsind-dynDNS-09 Summary: 12 errors (**), 0 flaws (~~), 3 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: September 1997 March 1997 6 Interaction between DHCP and DNS 7 draft-ietf-dhc-dhcp-dns-03.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 should set the RCODE1 and RCODE2 fields in the Client FQDN 142 option to 0 when sending the option. 144 Whether the client wants to be responsible for updating the FQDN to 145 IP address mapping, or whether the client wants to delegate this 146 responsibility to a server is a local to the client matter. The 147 choice between the two alternatives may be based on a particular 148 security model that is used with the Dynamic DNS Update protocol 149 (e.g., only a client may have sufficient credentials to perform 150 updates to the FQDN to IP address mapping for its FQDN). 152 If a client releases its address lease prior to the lease expiration 153 time, and the client is responsible for updating its A RR(s), the 154 client should delete the A RR (following the procedures described in 155 [DynDNS]) associated with the leased address before sending DHCP 156 RELEASE message. 158 4.3. DHCP Server behavior 160 When a server receives a DHCPREQUEST message from a client, if the 161 message contains the Client FQDN option, and the server replies to 162 the message with a DHCPACK message, the server shall originate an 163 update for the PTR RR (associated with the address leased to the 164 client). The server shall originate the update before the server 165 sends the DHCPACK message to the client. The update shall be 166 originated following the procedures described in [DynDNS]. The RCODE 167 from the update [DynDNS] should be carried to the client in the 168 RCODE1 field of the Client FQDN option in the DHCPACK message. The 169 RCODE2 field should be set to 0. 171 In addition, if the Client FQDN option carried in the DHCPREQUEST 172 message has its Flags field set to 1, then the server shall originate 173 an update for the A RR (associated with the FQDN carried in the 174 option). The server shall originate the update before the server 175 sends the DHCPACK message to the client. The update shall be 176 originated following the procedures described in [DynDNS]. The RCODE 177 from the update [DynDNS] should be carried to the client in the 178 RCODE2 field of the Client FQDN option in the DHCPACK message. 180 Even, if the Client FQDN option carried in the DHCPREQUEST message 181 has its Flags field set to 0 (indicating that the client wants to 182 update the A RR), the server could (under configuration control) 183 update the A RR. The server shall originate the update before the 184 server sends the DHCPACK message to the client. The update shall be 185 originated following the procedures described in [DynDNS]. The RCODE 186 from the update [DynDNS] should be carried to the client in the 187 RCODE2 field of the Client FQDN option in the DHCPACK message. The 188 Flags field in the Client FQND option shall be set to 3. 190 Whether a DHCP server is always responsible for updating the FQDN to 191 IP address mapping (in addition to updating the IP to FQDN mapping), 192 regarless of the wishes of a DHCP client, is a local to the server 193 matter. The choice between the two alternatives may be based on a 194 particular security model. 196 When a server receives a DHCPREQUEST message from a client, and the 197 message contains the Client FQDN option, the server shall ignore the 198 value carried in the RCODE1 and RCODE2 fields of the option. 200 When a DHCP server sends the Client FQDN option to a client in the 201 DHCPACK message, the server shall copy the Domain Name fields from 202 the Client FQDN option that the client sent to the server in the 203 DHCPREQUEST message. 205 If the DHCPREQUST message received by a DHCP server from a DHCP 206 client doesn't carry the Client FQDN option, and the DHCP client 207 acquires its FQDN from a DHCP server (as part of a normal DHCP 208 transaction), then the server may be configured to update both A and 209 PTR RRs. In this scenario the DHCPOFFER message originated by the 210 server shall carry the Domain Name option, and the client 211 acknowledges the use of the FQDN carried in this option by including 212 the option (with the FQDN) in the DHCPREQUEST originated by the 213 client. The updates shall be originated following the procedures 214 described in [DynDNS]. 216 If a server originates updates for both the A and PTR RRs, then the 217 order in which the updates are generated is not significant. 219 If a server detects that a lease on an address that the server leases 220 to a client expires, the server should delete the PTR RR associated 221 with the address. In addition, if the client authorized the server to 222 update its A RR, the server should also delete the A RR. The deletion 223 should follow the procedures described in [DynDNS]. 225 If a server terminates a lease on an address prior to the lease 226 expiration time, the server should delete the PTR RR associated with 227 the address. In addition, if the client (that leased the address) 228 authorized the server to update its A RR, the server should also 229 delete the A RR. The deletion should follow the procedures described 230 in [DynDNS]. 232 5. Updating other RRs 234 The procedures described in this document cover updates only to the A 235 and PTR RRs. Updating other types of RRs is outside the scope of this 236 document. 238 6. Security Considerations 240 Security issues are not discussed in this document. 242 7. References 244 [RFC1034] P. Mockapetris, "Domain names - concepts and facilities", 245 RFC1034, 11/01/1987 247 [RFC1035] P. Mockapetris, "Domain names - implementation and 248 specification", RFC1035, 11/01/1987 250 [RFC1541] R. Droms, "Dynamic Host Configuration Protocol", RFC1541, 251 10/27/1993 253 [RFC1594] A. Marine, J. Reynolds, G. Malkin, "FYI on Questions and 254 Answer Answers to Commonly asked ``New Internet User'' Questions", 255 RFC1594, 03/11/1994 257 [DynDNS] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates 258 in the Domain Name System (DNS UPDATE)", draft-ietf-dnsind-dynDNS- 259 09.txt 260 8. Acknowledgements 262 Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Peter Ford, Edie 263 Gunter, Michael Lewis, Michael Patton, and Glenn Stump for their 264 review and comments. 266 9. Author Information 268 Yakov Rekhter 269 cisco Systems, Inc. 270 170 Tasman Dr. 271 San Jose, CA 95134 272 Phone: (914) 528-0090 273 email: yakov@cisco.com