idnits 2.17.1 draft-ietf-dhc-dhcp-dns-00.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 (February 1996) is 10298 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-06 Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: August 1996 February 1996 5 Interaction between DHCP and DNS 6 draft-ietf-dhc-dhcp-dns-00.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. Interaction between DHCP and DNS 41 DNS [RFC1034, RFC1035] maintains (among other things) the information 42 about mapping between hosts' Fully Qualified Domain Names (FQDNs) 43 [RFC1594] and IP addresses assigned to the hosts. The information is 44 maintained in two types of Resource Records (RRs): A and PTR. The A 45 RR contains mapping from a FQDN to an IP address; the PTR RR contains 46 mapping from an IP address to a FQDN. 48 DHCP [RFC1541] provides a mechanism by which a host (a DHCP client) 49 could acquire certain configuration information, and specifically its 50 IP address(es). However, DHCP does not provide any mechanisms to 51 update the DNS RRs that contain the information about mapping between 52 the host's FQDN and its IP address(es) (A and PTR RRs). Thus the 53 information maintained by DNS for a DHCP client may be incorrect - a 54 host (the client) could acquire its address by using DHCP, but the A 55 RR for the host's FQDN wouldn't reflect the address that the host 56 acquired, and the PTR RR for the acquired address wouldn't reflect 57 the host's FQDN. 59 Dynamic DNS Updates [DynDNS] is a mechanism that enables to update 60 DNS information over a network. 62 Use of the Dynamic DNS Updates protocol enables to maintain 63 consistency between the information stored in the A and PTR RRs and 64 the actual address assignment done via DHCP. When a host with a 65 particular FQDN acquires its IP address via DHCP, the A RR associated 66 with the host's FQDN would be updated (by using the Dynamic DNS 67 Updates protocol) to reflect the new address. Likewise, when an IP 68 address gets assigned to a host with a particular FQDN, the PTR RR 69 associated with this address would be updated (using the Dynamic DNS 70 Updates protocol) to reflect the new FQDN. 72 4. Models of operations 74 When a DHCP client acquires a new address, both the A RR (for the 75 client's FQDN) and the PTR RR (for the acquired address) have to be 76 updated. Therefore, we have two separate Dynamic DNS Update 77 transactions. Acquiring an address via DHCP involves two entities: a 78 DHCP client and a DHCP server. In principle each of these entities 79 could perform none, one, or both of the transactions. However, upon 80 some introspection one could realize that not all permutations make 81 sense. This document restricts the possible design permutations to 82 the following cases: 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 TBD. Its minimum length is 2. 102 Code Len Flags Domain Name 103 +-----+-----+-----+-----+-----+-----+-- 104 | TBD | n | 0/1 | d1 | d2 | d3 | ... 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 Domain Name part of the option carries FQDN of a client. 114 4.2. DHCP Client behavior 116 If a client wants to be responsible for updating the FQDN to IP 117 address mapping for the FQDN and address(es) used by the client, then 118 the client shall include the Client FQDN option in the DHCPREQUEST 119 message originated by the client. The Flags field in the option shall 120 be set to 0. Once the client's DHCP configuration is completed (the 121 client receives a DHCPACK message, and successfully completed a final 122 check on the parameters passed in the message), the client shall 123 originate an update for the A RR (associated with the client's FQDN). 124 The update shall be originated following the procedures described in 125 [DynDNS]. 127 If a client does not want to be responsible for updating the FQDN to 128 IP address mapping for the FQDN and address(es) used by the client, 129 then the client shall include the Client FQDN option in the 130 DHCPREQUEST message originated by the client. The Flags field in the 131 option shall be set to 1. 133 A client that delegates the responsibility for updating the FQDN to 134 IP address mapping to a server does not receive any indications 135 (either positive or negative) from the server whether the server was 136 able to perform the update. The client may use DNS query to check 137 whether the mapping is updated. 139 Whether the client wants to be responsible for updating the FQDN to 140 IP address mapping, or whether the client wants to delegate this 141 responsibility to a server is a local to the client matter. 143 4.3. DHCP Server behavior 145 When a server receives a DHCPREQUEST message from a client, if the 146 message contains the Client FQDN option, and the server replies to 147 the message with a DHCPACK message, the server shall originate an 148 update for the PTR RR (associated with the address leased to the 149 client). The server shall originate the update only after the server 150 sends the DHCPACK message to the client. The update shall be 151 originated following the procedures described in [DynDNS]. 153 In addition, if the Client FQDN option carried in the DHCPREQUEST 154 message has its Flags field set to 1, then the server shall originate 155 an update for the A RR (associated with the FQDN carried in the 156 option). The server shall originate the update only after the server 157 sends the DHCPACK message to the client. The update shall be 158 originated following the procedures described in [DynDNS]. 160 If a server originates updates for both the A and PTR RRs, then the 161 order in which the updates are generated is not significant. 163 [Discussion: should it be possible to configure a server to perform 164 updates for the FQDN to IP address mapping, even when a client 165 indicates to the server that the client wants to update this mapping 166 ?] 168 [Discussion: how should the duration of the lease be reflected in the 169 DNS updates ? At the minimum we can set TTL on the A and PTR RRs to 170 the value of the lease time. What else ?] 172 [Discussion: when a server detects that a lease on an address that 173 the server leases to a client expires, should the server delete the 174 PTR RR associated with the address ?] 176 [Discussion: if a server terminates a lease prior to the lease 177 expiration time, should the server update the associated PTR RR ? 178 Should the A RR be updated, and if yes, then by whom ? ] 180 5. Updating other RRs 182 The procedures described in this document cover updates only to the A 183 and PTR RRs. Updating other types of RRs is outside the scope of this 184 document. 186 6. Applicability to IPv6 188 The procedures described above are directly applicable to an IPv6 189 client. The only difference is that instead of updating its A RR(s) 190 the client has to update its AAAA RR(s). 192 7. Security Considerations 194 Security issues are not discussed in this document. 196 8. References 198 [RFC1034] P. Mockapetris, "Domain names - concepts and facilities", 199 RFC1034, 11/01/1987 201 [RFC1035] P. Mockapetris, "Domain names - implementation and 202 specification", RFC1035, 11/01/1987 204 [RFC1541] R. Droms, "Dynamic Host Configuration Protocol", RFC1541, 205 10/27/1993 207 [RFC1594] A. Marine, J. Reynolds, G. Malkin, "FYI on Questions and 208 Answer Answers to Commonly asked ``New Internet User'' Questions", 209 RFC1594, 03/11/1994 211 [DynDNS] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates 212 in the Domain Name System (DNS UPDATE)", draft-ietf-dnsind-dynDNS- 213 06.txt, Feb 1996 214 9. Acknowledgements 216 Many thanks to Ralph Droms for his review and comments. 218 10. Author Information 220 Yakov Rekhter 221 cisco Systems, Inc. 222 170 Tasman Dr. 223 San Jose, CA 95134 224 Phone: (914) 528-0090 225 email: yakov@cisco.com