idnits 2.17.1 draft-ietf-dhc-ddns-resolution-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 1, 2002) is 7847 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) == Unused Reference: '7' is defined on line 412, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 416, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 422, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 425, but no explicit reference was found in the text -- No information found for draft-ietf-dhc-fqdn-option- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' -- No information found for draft-ietf-dnsext-dhcid-rr- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 1594 (ref. '7') (Obsoleted by RFC 2664) ** Obsolete normative reference: RFC 2535 (ref. '9') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '11') ** Obsolete normative reference: RFC 2845 (ref. '12') (Obsoleted by RFC 8945) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group M. Stapp 3 Internet-Draft Cisco Systems, Inc. 4 Expires: May 2, 2003 November 1, 2002 6 Resolution of DNS Name Conflicts Among DHCP Clients 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on May 2, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 DHCP provides a powerful mechanism for IP host configuration. 39 However, the configuration capability provided by DHCP does not 40 include updating DNS(RFC1034[1], RFC1035[2]), and specifically 41 updating the name to address and address to name mappings maintained 42 in the DNS. 44 The "Client FQDN Option"[3] specifies the client FQDN option, 45 through which DHCP clients and servers can exchange information 46 about client FQDNs. This document describes techniques for the 47 resolution of DNS name conflicts among DHCP clients. 49 Table of Contents 51 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Issues with DNS Update in DHCP Environments . . . . . . . . . 3 54 3.1 Client Mis-Configuration . . . . . . . . . . . . . . . . . . . 4 55 3.2 Multiple DHCP Servers . . . . . . . . . . . . . . . . . . . . 5 56 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 5 57 5. DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 6. Procedures for performing DNS updates . . . . . . . . . . . . 6 59 6.1 Adding A RRs to DNS . . . . . . . . . . . . . . . . . . . . . 6 60 6.2 Adding PTR RR Entries to DNS . . . . . . . . . . . . . . . . . 7 61 6.3 Removing Entries from DNS . . . . . . . . . . . . . . . . . . 7 62 6.4 Updating Other RRs . . . . . . . . . . . . . . . . . . . . . . 8 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 65 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 67 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11 69 1. Terminology 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119[4]. 75 2. Introduction 77 "The Client FQDN Option"[3] includes a description of the operation 78 of DHCP[5] clients and servers that use the client FQDN option. 79 Through the use of the client FQDN option, DHCP clients and servers 80 can negotiate the client's FQDN and the allocation of responsibility 81 for updating the DHCP client's A RR. This document identifies 82 situations in which conflicts in the use of FQDNs may arise among 83 DHCP clients, and describes a strategy for the use of the DHCID DNS 84 resource record[6] in resolving those conflicts. 86 In any case, whether a site permits all, some, or no DHCP servers 87 and clients to perform DNS updates into the zones that it controls 88 is entirely a matter of local administrative policy. This document 89 does not require any specific administrative policy, and does not 90 propose one. The range of possible policies is very broad, from 91 sites where only the DHCP servers have been given credentials that 92 the DNS servers will accept, to sites where each individual DHCP 93 client has been configured with credentials that allow the client to 94 modify its own domain name. Compliant implementations MAY support 95 some or all of these possibilities. Furthermore, this specification 96 applies only to DHCP client and server processes: it does not apply 97 to other processes that initiate DNS updates. 99 3. Issues with DNS Update in DHCP Environments 101 There are two DNS update situations that require special 102 consideration in DHCP environments: cases where more than one DHCP 103 client has been configured with the same FQDN, and cases where more 104 than one DHCP server has been given authority to perform DNS updates 105 in a zone. In these cases, it is possible for DNS records to be 106 modified in inconsistent ways unless the updaters have a mechanism 107 that allows them to detect anomolous situations. If DNS updaters can 108 detect these situations, site administrators can configure the 109 updaters' behavior so that the site's policies can be enforced. We 110 use the term "Name Conflict" to refer to cases where more than one 111 DHCP client wishes to be associated with a single FQDN. This 112 specification describes a mechanism designed to allow updaters to 113 detect these situations, and suggests that DHCP implementations use 114 this mechanism by default. 116 3.1 Client Mis-Configuration 118 At many (though not all) sites, administrators wish to maintain a 119 one-to-one relationship between active DHCP clients and domain 120 names, and to maintain consistency between a host's A and PTR RRs. 121 Hosts that are not represented in the DNS, or hosts which 122 inadvertently share an FQDN with another host may encounter 123 inconsistent behavior or may not be able to obtain access to network 124 resources. Whether each DHCP client is configured with a domain name 125 by its administrator or whether the DHCP server is configured to 126 distribute the clients' names, the consistency of the DNS data is 127 entirely dependent on the accuracy of the configuration procedure. 128 Sites that deploy Secure DNS[9] may configure credentials for each 129 host and its assigned name in a way that is more error-resistant, 130 but this level of pre-configuration is still rare in DHCP 131 environments. 133 Consider an example in which two DHCP clients in the "org.nil" 134 network are both configured with the name "foo". The clients are 135 permitted to perform their own DNS updates. The first client, client 136 A, is configured via DHCP. It adds an A RR to "foo.org.nil", and its 137 DHCP server adds a PTR RR corresponding to its IP address lease. 138 When the second client, client B, boots, it is also configured via 139 DHCP, and it also begins to update "foo.org.nil". 141 At this point, the "org.nil" administrators may wish to establish 142 some policy about DHCP clients' DNS names. If the policy is that 143 each client that boots should replace any existing A RR that matches 144 its name, Client B can proceed, though Client A may encounter 145 problems. In this example, Client B replaces the A RR associated 146 with "foo.org.nil". Client A must have some way to recognize that 147 the RR associated with "foo.org.nil" now contains information for 148 Client B, so that it can avoid modifying the RR. When Client A's 149 lease expires, for example, it should not remove an RR that reflects 150 Client B's DHCP lease. 152 If the policy is that the first DHCP client with a given name should 153 be the only client associated with that name, Client B needs to be 154 able to determine that it is not the client associated with 155 "foo.org.nil". It could be that Client A booted first, and that 156 Client B should choose another name. Or it could be that B has 157 booted on a new subnet, and received a new lease. It must either 158 retain persistent state about the last lease it held (in addition to 159 its current lease) or it must have some other way to detect that it 160 was the last updater of "foo.org.nil" in order to implement the 161 site's policy. 163 3.2 Multiple DHCP Servers 165 At many sites, the difficulties with distributing DNS update 166 credentials to all of the DHCP clients lead to the desire for the 167 DHCP servers to perform A RR updates on behalf of their clients. If 168 a single DHCP server managed all of the DHCP clients at a site, it 169 could maintain some database of the DNS names that it was managing, 170 and check that database before initiating a DNS update for a client. 171 Such a database is necessarily proprietary, however, and that 172 approach does not work once more than one DHCP server is deployed. 174 Consider an example in which DHCP Client A boots, obtains a DHCP 175 lease from Server S1, presenting the hostname "foo" in a Client FQDN 176 option[3] in its DHCPREQUEST message. Server S1 updates its domain 177 name, "foo.org.nil", adding an A RR that matches Client A's lease. 178 The client then moves to another subnet, served by Server S2. When 179 Client A boots on the new subnet, Server S2 will issue it a new 180 lease, and will attempt to add an A RR matching the new lease to 181 "foo.org.nil". At this point, without some communication mechanism 182 which S2 can use to ask S1 (and every other DHCP server that updates 183 the zone) about the client, S2 has no way to know whether Client A 184 is currently associated with the domain name, or whether A is a 185 different client configured with the same hostname. If the servers 186 cannot distinguish between these situations, they cannot enforce the 187 site's naming policies. 189 4. Use of the DHCID RR 191 A solution to both of these problems is for the updater (a DHCP 192 client or DHCP server) to be able to determine which DHCP client has 193 been associated with a DNS name, in order to offer administrators 194 the opportunity to configure updater behavior. 196 For this purpose, a DHCID RR, specified in [6], is used to associate 197 client identification information with a DNS name and the A or PTR 198 RR associated with that name. When either a client or server adds an 199 A or PTR RR for a client, it also adds a DHCID RR that specifies a 200 unique client identity, based on data from the client's DHCPREQUEST 201 message. In this model, only one A RR is associated with a given DNS 202 name at a time. 204 By associating this ownership information with each DNS name, 205 cooperating DNS updaters may determine whether their client is 206 currently associated with a particular DNS name and implement the 207 appropriately configured administrative policy. In addition, DHCP 208 clients which currently have domain names may move from one DHCP 209 server to another without losing their DNS names. 211 The specific algorithms utilizing the DHCID RR to signal client 212 ownership are explained below. The algorithms only work in the case 213 where the updating entities all cooperate -- this approach is 214 advisory only and is not a substitute for DNS security, nor is it 215 replaced by DNS security. 217 5. DNS RR TTLs 219 RRs associated with DHCP clients may be more volatile than 220 statically configured RRs. DHCP clients and servers that perform 221 dynamic updates should attempt to specify resource record TTLs which 222 reflect this volatility, in order to minimize the possibility that 223 there will be stale records in resolvers' caches. 225 A reasonable basis for RR TTLs is the lease duration itself. The RR 226 TTL on a DNS record added for with a DHCP lease SHOULD NOT exceed 227 1/3 of the lease time, and SHOULD be at least 10 minutes. We 228 recognize that individual administrators will have varying 229 requirements: DHCP servers and clients SHOULD allow administrators 230 to configure TTLs, either as an absolute time interval or as a 231 percentage of the lease time. In general, the TTLs or RRs added as a 232 result of DHCP lease activity SHOULD be less than the initial lease 233 time. 235 6. Procedures for performing DNS updates 237 6.1 Adding A RRs to DNS 239 When a DHCP client or server intends to update an A RR, it first 240 prepares a DNS UPDATE query that includes as a prerequisite the 241 assertion that the name does not exist. The update section of the 242 query attempts to add the new name and its IP address mapping (an A 243 RR), and the DHCID RR with its unique client-identity. 245 If this update operation succeeds, the updater can conclude that it 246 has added a new name whose only RRs are the A and DHCID RR records. 247 The A RR update is now complete (and a client updater is finished, 248 while a server might proceed to perform a PTR RR update). 250 If the first update operation fails with YXDOMAIN, the updater can 251 conclude that the intended name is in use. The updater then 252 attempts to confirm that the DNS name is not being used by some 253 other host. The updater prepares a second UPDATE query in which the 254 prerequisite is that the desired name has attached to it a DHCID RR 255 whose contents match the client identity. The update section of 256 this query deletes the existing A records on the name, and adds the 257 A record that matches the DHCP binding and the DHCID RR with the 258 client identity. 260 If this query succeeds, the updater can conclude that the current 261 client was the last client associated with the domain name, and that 262 the name now contains the updated A RR. The A RR update is now 263 complete (and a client updater is finished, while a server would 264 then proceed to perform a PTR RR update). 266 If the second query fails with NXRRSET, the updater must conclude 267 that the client's desired name is in use by another host. At this 268 juncture, the updater can decide (based on some administrative 269 configuration outside of the scope of this document) whether to let 270 the existing owner of the name keep that name, and to (possibly) 271 perform some name disambiguation operation on behalf of the current 272 client, or to replace the RRs on the name with RRs that represent 273 the current client. If the configured policy allows replacement of 274 existing records, the updater submits a query that deletes the 275 existing A RR and the existing DHCID RR, adding A and DHCID RRs that 276 represent the IP address and client-identity of the new client. 278 DISCUSSION: 279 The updating entity may be configured to allow the existing DNS 280 records on the domain name to remain unchanged, and to perform 281 disambiguation on the name of the current client in order to 282 attempt to generate a similar but unique name for the current 283 client. In this case, once another candidate name has been 284 generated, the updater should restart the process of adding an A 285 RR as specified in this section. 287 6.2 Adding PTR RR Entries to DNS 289 The DHCP server submits a DNS query that deletes all of the PTR RRs 290 associated with the lease IP address, and adds a PTR RR whose data 291 is the client's (possibly disambiguated) host name. The server MAY 292 also add a DHCID RR as specified in Section 4. 294 6.3 Removing Entries from DNS 296 The most important consideration in removing DNS entries is be sure 297 that an entity removing a DNS entry is only removing an entry that 298 it added, or for which an administrator has explicitly assigned it 299 responsibility. 301 When a lease expires or a DHCP client issues a DHCPRELEASE request, 302 the DHCP server SHOULD delete the PTR RR that matches the DHCP 303 binding, if one was successfully added. The server's update query 304 SHOULD assert that the name in the PTR record matches the name of 305 the client whose lease has expired or been released. 307 The entity chosen to handle the A record for this client (either the 308 client or the server) SHOULD delete the A record that was added when 309 the lease was made to the client. 311 In order to perform this delete, the updater prepares an UPDATE 312 query that contains two prerequisites. The first prerequisite 313 asserts that the DHCID RR exists whose data is the client identity 314 described in Section 4. The second prerequisite asserts that the 315 data in the A RR contains the IP address of the lease that has 316 expired or been released. 318 If the query fails, the updater MUST NOT delete the DNS name. It 319 may be that the client whose lease on has expired has moved to 320 another network and obtained a lease from a different server, which 321 has caused the client's A RR to be replaced. It may also be that 322 some other client has been configured with a name that matches the 323 name of the DHCP client, and the policy was that the last client to 324 specify the name would get the name. In these cases, the DHCID RR 325 will no longer match the updater's notion of the client-identity of 326 the host pointed to by the DNS name. 328 6.4 Updating Other RRs 330 The procedures described in this document only cover updates to the 331 A and PTR RRs. Updating other types of RRs is outside the scope of 332 this document. 334 7. Security Considerations 336 Unauthenticated updates to the DNS can lead to tremendous confusion, 337 through malicious attack or through inadvertent misconfiguration. 338 Administrators should be wary of permitting unsecured DNS updates to 339 zones that are exposed to the global Internet. Both DHCP clients and 340 servers SHOULD use some form of update request authentication (e.g., 341 TSIG[12]) when performing DNS updates. 343 Whether a DHCP client may be responsible for updating an FQDN to IP 344 address mapping, or whether this is the responsibility of the DHCP 345 server is a site-local matter. The choice between the two 346 alternatives may be based on the security model that is used with 347 the Dynamic DNS Update protocol (e.g., only a client may have 348 sufficient credentials to perform updates to the FQDN to IP address 349 mapping for its FQDN). 351 Whether a DHCP server is always responsible for updating the FQDN to 352 IP address mapping (in addition to updating the IP to FQDN mapping), 353 regardless of the wishes of an individual DHCP client, is also a 354 site-local matter. The choice between the two alternatives may be 355 based on the security model that is being used with dynamic DNS 356 updates. In cases where a DHCP server is performing DNS updates on 357 behalf of a client, the DHCP server should be sure of the DNS name 358 to use for the client, and of the identity of the client. 360 Currently, it is difficult for DHCP servers to develop much 361 confidence in the identities of their clients, given the absence of 362 entity authentication from the DHCP protocol itself. There are many 363 ways for a DHCP server to develop a DNS name to use for a client, 364 but only in certain relatively rare circumstances will the DHCP 365 server know for certain the identity of the client. If DHCP 366 Authentication[13] becomes widely deployed this may become more 367 customary. 369 One example of a situation that offers some extra assurances is one 370 where the DHCP client is connected to a network through an MCNS 371 cable modem, and the CMTS (head-end) of the cable modem ensures that 372 MAC address spoofing simply does not occur. Another example of a 373 configuration that might be trusted is one where clients obtain 374 network access via a network access server using PPP. The NAS itself 375 might be obtaining IP addresses via DHCP, encoding a client 376 identification into the DHCP client-id option. In this case, the 377 network access server as well as the DHCP server might be operating 378 within a trusted environment, in which case the DHCP server could be 379 configured to trust that the user authentication and authorization 380 processing of the remote access server was sufficient, and would 381 therefore trust the client identification encoded within the DHCP 382 client-id. 384 8. Acknowledgements 386 Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter 387 Ford, Olafur Gudmundsson, Edie Gunter, Andreas Gustafsson, R. Barr 388 Hibbs, Kim Kinnear, Stuart Kwan, Ted Lemon, Ed Lewis, Michael Lewis, 389 Josh Littlefield, Michael Patton, Glenn Stump, and Bernie Volz for 390 their review and comments. 392 References 394 [1] Mockapetris, P., "Domain names - Concepts and Facilities", RFC 395 1034, Nov 1987. 397 [2] Mockapetris, P., "Domain names - Implementation and 398 Specification", RFC 1035, Nov 1987. 400 [3] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option 401 (draft-ietf-dhc-fqdn-option-*.txt)", March 2001. 403 [4] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", RFC 2119, March 1997. 406 [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 407 March 1997. 409 [6] Stapp, M., Gustafsson, A. and T. Lemon, "A DNS RR for Encoding 410 DHCP Information (draft-ietf-dnsext-dhcid-rr-*)", March 2001. 412 [7] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and 413 Answers to Commonly asked ``New Internet User'' Questions", 414 RFC 1594, March 1994. 416 [8] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 417 Updates in the Domain Name System", RFC 2136, April 1997. 419 [9] Eastlake, D., "Domain Name System Security Extensions", RFC 420 2535, March 1999. 422 [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic 423 Update", RFC 3007, November 2000. 425 [11] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 426 April 1992. 428 [12] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 429 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 430 2845, May 2000. 432 [13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 433 RFC 3118, June 2001. 435 Author's Address 437 Mark Stapp 438 Cisco Systems, Inc. 439 250 Apollo Dr. 440 Chelmsford, MA 01824 441 USA 443 Phone: 978.244.8498 444 EMail: mjs@cisco.com 446 Full Copyright Statement 448 Copyright (C) The Internet Society (2002). All Rights Reserved. 450 This document and translations of it may be copied and furnished to 451 others, and derivative works that comment on or otherwise explain it 452 or assist in its implementation may be prepared, copied, published 453 and distributed, in whole or in part, without restriction of any 454 kind, provided that the above copyright notice and this paragraph 455 are included on all such copies and derivative works. However, this 456 document itself may not be modified in any way, such as by removing 457 the copyright notice or references to the Internet Society or other 458 Internet organizations, except as needed for the purpose of 459 developing Internet standards in which case the procedures for 460 copyrights defined in the Internet Standards process must be 461 followed, or as required to translate it into languages other than 462 English. 464 The limited permissions granted above are perpetual and will not be 465 revoked by the Internet Society or its successors or assigns. 467 This document and the information contained herein is provided on an 468 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 469 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 470 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 471 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 472 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 474 Acknowledgement 476 Funding for the RFC editor function is currently provided by the 477 Internet Society.