idnits 2.17.1 draft-ietf-dhc-dhcp-dns-02.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-26) 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 5 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 (October 1996) is 10055 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: April 1997 October 1996 6 Interaction between DHCP and DNS 7 draft-ietf-dhc-dhcp-dns-02.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 | TBD | n | 0/1 | | | ... 105 +------+------+------+------+------+------+-- 107 The Flags field allows a DHCP client to indicate to a DHCP server 108 whether the client wants the server to be responsible for updating 109 the FQDN to IP address mapping (if Flags is set to 1), or whether the 110 client wants to take this responsibility (if Flags is set to 0). 112 The RCODE1 and RCODE2 fields are used by a DHCP server to indicate to 113 a DHCP client the Response Code from Dynamic DNS Updates. 115 The Domain Name part of the option carries FQDN of a client. 117 4.2. DHCP Client behavior 119 If a client wants to be responsible for updating the FQDN to IP 120 address mapping for the FQDN and address(es) used by the client, then 121 the client shall include the Client FQDN option in the DHCPREQUEST 122 message originated by the client. The Flags field in the option shall 123 be set to 0. Once the client's DHCP configuration is completed (the 124 client receives a DHCPACK message, and successfully completed a final 125 check on the parameters passed in the message), the client shall 126 originate an update for the A RR (associated with the client's FQDN). 128 The update shall be originated following the procedures described in 129 [DynDNS]. 131 If a client does not want to be responsible for updating the FQDN to 132 IP address mapping for the FQDN and address(es) used by the client, 133 then the client shall include the Client FQDN option in the 134 DHCPREQUEST message originated by the client. The Flags field in the 135 option shall be set to 1. 137 A client should set the RCODE1 and RCODE2 fields in the Client FQDN 138 option to 0 when sending the option. 140 Whether the client wants to be responsible for updating the FQDN to 141 IP address mapping, or whether the client wants to delegate this 142 responsibility to a server is a local to the client matter. The 143 choice between the two alternatives may be based on a particular 144 security model that is used with the Dynamic DNS Update protocol 145 (e.g., only a client may have sufficient credentials to perform 146 updates to the FQDN to IP address mapping for its FQDN). 148 If a client releases its address lease prior to the lease expiration 149 time, and the client is responsible for updating its A RR(s), the 150 client should delete the A RR (following the procedures described in 151 [DynDNS]) associated with the leased address before sending DHCP 152 RELEASE message. 154 4.3. DHCP Server behavior 156 When a server receives a DHCPREQUEST message from a client, if the 157 message contains the Client FQDN option, and the server replies to 158 the message with a DHCPACK message, the server shall originate an 159 update for the PTR RR (associated with the address leased to the 160 client). The server shall originate the update before the server 161 sends the DHCPACK message to the client. The update shall be 162 originated following the procedures described in [DynDNS]. The RCODE 163 from the update [DynDNS] should be carried to the client in the 164 RCODE1 field of the Client FQDN option in the DHCPACK message. The 165 RCODE2 field should be set to 0. 167 In addition, if the Client FQDN option carried in the DHCPREQUEST 168 message has its Flags field set to 1, then the server shall originate 169 an update for the A RR (associated with the FQDN carried in the 170 option). The server shall originate the update before the server 171 sends the DHCPACK message to the client. The update shall be 172 originated following the procedures described in [DynDNS]. The RCODE 173 from the update [DynDNS] should be carried to the client in the 174 RCODE2 field of the Client FQDN option in the DHCPACK message. 176 When a server receives a DHCPREQUEST message from a client, and the 177 message contains the Client FQDN option, the server shall ignore the 178 value carried in the RCODE1 and RCODE2 fields of the option. 180 When a DHCP server sends the Client FQDN option to a client in the 181 DHCPACK message, the server should copy the Flags and the Domain Name 182 fields from the Client FQDN option that the client sent to the server 183 in the DHCPREQUEST message. 185 If a server originates updates for both the A and PTR RRs, then the 186 order in which the updates are generated is not significant. 188 If a server detects that a lease on an address that the server leases 189 to a client expires, the server should delete the PTR RR associated 190 with the address. In addition, if the client authorized the server to 191 update its A RR, the server should also delete the A RR. The deletion 192 should follow the procedures described in [DynDNS]. 194 If a server terminates a lease on an address prior to the lease 195 expiration time, the server should delete the PTR RR associated with 196 the address. In addition, if the client (that leased the address) 197 authorized the server to update its A RR, the server should also 198 delete the A RR. The deletion should follow the procedures described 199 in [DynDNS]. 201 5. Updating other RRs 203 The procedures described in this document cover updates only to the A 204 and PTR RRs. Updating other types of RRs is outside the scope of this 205 document. 207 6. Security Considerations 209 Security issues are not discussed in this document. 211 7. References 213 [RFC1034] P. Mockapetris, "Domain names - concepts and facilities", 214 RFC1034, 11/01/1987 216 [RFC1035] P. Mockapetris, "Domain names - implementation and 217 specification", RFC1035, 11/01/1987 219 [RFC1541] R. Droms, "Dynamic Host Configuration Protocol", RFC1541, 220 10/27/1993 222 [RFC1594] A. Marine, J. Reynolds, G. Malkin, "FYI on Questions and 223 Answer Answers to Commonly asked ``New Internet User'' Questions", 224 RFC1594, 03/11/1994 226 [DynDNS] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates 227 in the Domain Name System (DNS UPDATE)", draft-ietf-dnsind-dynDNS- 228 09.txt 230 8. Acknowledgements 232 Many thanks to Mark Beyer (Tandem), Jim Bound (DEC), Ralph Droms 233 (Bucknell University), Edie Gunter (IBM), Michael Lewis (Chevron), 234 and Michael Patton (BBN) for their review and comments. 236 9. Author Information 238 Yakov Rekhter 239 cisco Systems, Inc. 240 170 Tasman Dr. 241 San Jose, CA 95134 242 Phone: (914) 528-0090 243 email: yakov@cisco.com