idnits 2.17.1 draft-ietf-dhc-dhcp-dns-11.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages 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 ([5]), 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2136' on line 380 -- Looks like a reference, but probably isn't: 'TBD' on line 532 ** Obsolete normative reference: RFC 1594 (ref. '4') (Obsoleted by RFC 2664) ** Obsolete normative reference: RFC 2535 (ref. '7') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- No information found for draft-ietf-dnsind-tsig- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '8' -- No information found for draft-ietf-dhc-authentication- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' -- No information found for draft-ietf-dnsind-simple-secure-update- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '10' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Group M. Stapp 2 Internet-Draft Y. Rekhter 3 Expires: April 2000 Cisco Systems, Inc. 4 October, 1999 6 Interaction between DHCP and DNS 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 April, 2000. 32 Copyright Notice 34 Copyright (C) The Internet Society (1999). 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, and specifically updating the name to address 41 and address to name mappings maintained in the DNS. 43 This document specifies how DHCP clients and servers should use the 44 Dynamic DNS Updates mechanism in RFC2136[5] to update the DNS name 45 to address and address to name mappings so that the mappings for 46 DHCP clients will be consistent with the IP addresses that the 47 clients acquire via DHCP. 49 Table of Contents 51 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Models of Operation . . . . . . . . . . . . . . . . . . . . 3 54 4. Client FQDN Option . . . . . . . . . . . . . . . . . . . . . 4 55 4.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 5 56 4.2 The RCODE Fields . . . . . . . . . . . . . . . . . . . . . . 6 57 4.3 The Domain Name Field . . . . . . . . . . . . . . . . . . . 6 58 5. DHCP Client behavior . . . . . . . . . . . . . . . . . . . . 6 59 6. DHCP Server behavior . . . . . . . . . . . . . . . . . . . . 8 60 7. Procedures for performing DNS updates . . . . . . . . . . . 10 61 7.1 Name Collisions . . . . . . . . . . . . . . . . . . . . . . 10 62 7.2 Multiple DHCP servers . . . . . . . . . . . . . . . . . . . 11 63 7.3 Use of the KEY RR . . . . . . . . . . . . . . . . . . . . . 11 64 7.3.1 Format of the KEY RR . . . . . . . . . . . . . . . . . . . . 12 65 7.4 DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . 12 66 7.5 Adding A RRs to DNS . . . . . . . . . . . . . . . . . . . . 13 67 7.6 Adding PTR RR Entries to DNS . . . . . . . . . . . . . . . . 14 68 7.7 Removing Entries from DNS . . . . . . . . . . . . . . . . . 14 69 7.8 Updating other RRs . . . . . . . . . . . . . . . . . . . . . 14 70 8. Security Considerations . . . . . . . . . . . . . . . . . . 15 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 72 References . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 74 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 76 1. Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119[6]. 82 2. Introduction 84 DNS RFC1034[1], RFC1035[2] maintains (among other things) the 85 information about mapping between hosts' Fully Qualified Domain 86 Names (FQDNs) RFC1594[4] and IP addresses assigned to the hosts. The 87 information is maintained in two types of Resource Records (RRs): A 88 and PTR. The A RR contains mapping from a FQDN to an IP address; the 89 PTR RR contains mapping from an IP address to a FQDN. The Dynamic 90 DNS Updates specification RFC2136[5] describes a mechanism that 91 enables DNS information to be updated over a network. 93 DHCP RFC2131[3] provides a mechanism by which a host (a DHCP client) 94 can acquire certain configuration information, along with its IP 95 address(es). However, DHCP does not provide any mechanisms to update 96 the DNS RRs that contain the information about mapping between the 97 host's FQDN and its IP address(es) (A and PTR RRs). Thus the 98 information maintained by DNS for a DHCP client may be incorrect - a 99 host (the client) could acquire its address by using DHCP, but the A 100 RR for the host's FQDN wouldn't reflect the address that the host 101 acquired, and the PTR RR for the acquired address wouldn't reflect 102 the host's FQDN. 104 The Dynamic DNS Update protocol can be used to maintain consistency 105 between the information stored in the A and PTR RRs and the actual 106 address assignment done via DHCP. When a host with a particular FQDN 107 acquires its IP address via DHCP, the A RR associated with the 108 host's FQDN would be updated (by using the Dynamic DNS Updates 109 protocol) to reflect the new address. Likewise, when an IP address 110 is assigned to a host with a particular FQDN, the PTR RR associated 111 with this address would be updated (using the Dynamic DNS Updates 112 protocol) to reflect the new FQDN. 114 Although this document refers to the A and PTR DNS record types and 115 to DHCP assignment of IPv4 addresses, the same procedures and 116 requirements apply for updates to the analogous RR types that are 117 used when clients are assigned IPv6 addresses via DHCPv6. 119 3. Models of Operation 121 When a DHCP client acquires a new address, a site's administrator 122 may desire that one or both of the A RR for the client's FQDN and 123 the PTR RR for the acquired address be updated. Therefore, two 124 separate Dynamic DNS Update transactions occur. Acquiring an address 125 via DHCP involves two entities: a DHCP client and a DHCP server. In 126 principle each of these entities could perform none, one, or both of 127 the transactions. However, in practice not all permutations make 128 sense. This document covers these possible design permutations: 130 1. DHCP client updates the A RR, DHCP server updates the PTR RR 131 2. DHCP server updates both the A and the PTR RRs 133 The only difference between these two cases is whether the FQDN to 134 IP address mapping is updated by a DHCP client or by a DHCP server. 135 The IP address to FQDN mapping is updated by a DHCP server in both 136 cases. 138 The reason these two are important, while others are unlikely, has 139 to do with authority over the respective DNS domain names. A DHCP 140 client may be given authority over mapping its own A RRs, or that 141 authority may be restricted to a server to prevent the client from 142 listing arbitrary addresses or associating its address with 143 arbitrary domain names. In all cases, the only reasonable place for 144 the authority over the PTR RRs associated with the address is in the 145 DHCP server that allocates the address. 147 In any case, whether a site permits all, some, or no DHCP servers 148 and clients to perform DNS updates into the zones which it controls 149 is entirely a matter of local administrative policy. This document 150 does not require any specific administrative policy, and does not 151 propose one. The range of possible policies is very broad, from 152 sites where only the DHCP servers have been given credentials that 153 the DNS servers will accept, to sites where each individual DHCP 154 client has been configured with credentials which allow the client 155 to modify its own domain name. Compliant implementations MAY support 156 some or all of these possibilities. Furthermore, this specification 157 applies only to DHCP client and server processes: it does not apply 158 to other processes which initiate dynamic DNS updates. 160 This document describes a new DHCP option which a client can use to 161 convey all or part of its domain name to a DHCP server. 162 Site-specific policy determines whether DHCP servers use the names 163 that clients offer or not, and what DHCP servers may do in cases 164 where clients do not supply domain names. 166 4. Client FQDN Option 168 To update the IP address to FQDN mapping a DHCP server needs to know 169 the FQDN of the client to which the server leases the address. To 170 allow the client to convey its FQDN to the server this document 171 defines a new DHCP option, called "Client FQDN". The FQDN Option 172 also contains Flags and RCode fields which DHCP servers can use to 173 convey information about DNS updates to clients. 175 Clients MAY send the FQDN option, setting appropriate Flags values, 176 in both their DISCOVER and REQUEST messages. If a client sends the 177 FQDN option in its DISCOVER message, it MUST send the option in 178 subsequent REQUEST messages. 180 The code for this option is 81. Its minimum length is 4. 182 Code Len Flags RCODE1 RCODE2 Domain Name 183 +------+------+------+------+------+------+-- 184 | 81 | n | | | | ... 185 +------+------+------+------+------+------+-- 187 4.1 The Flags Field 189 0 1 2 3 4 5 6 7 190 +-+-+-+-+-+-+-+-+ 191 | MBZ |E|O|S| 192 +-+-+-+-+-+-+-+-+ 194 When a DHCP client sends the FQDN option in its DHCPDISCOVER and/or 195 DHCPREQUEST messages, it sets the right-most bit (labelled "S") to 196 indicate that it will not perform any Dynamic DNS updates, and that 197 it expects the DHCP server to perform any FQDN-to-IP (the A RR) DNS 198 update on its behalf. If this bit is clear, the client indicates 199 that it intends to maintain its own FQDN-to-IP mapping update. 201 If a DHCP server intends to take responsibility for the A RR update 202 whether or not the client sending the FQDN option has set the "S" 203 bit, it sets both the "O" bit and the "S" bit, and sends the FQDN 204 option in its DHCPOFFER and/or DHCPACK messages. 206 The data in the Domain Name field may appear in one of two formats: 207 ASCII, or DNS-style binary encoding (without compression, of 208 course), as described in RFC1035[2]. A client which sends the FQDN 209 option MUST set the "E" bit to indicate that the data in the Domain 210 Name field is DNS-encoded. If a server receives an FQDN option from 211 a client, and intends to include an FQDN option in its reply, it 212 MUST use the same encoding that the client used. The DNS encoding is 213 recommended. The use of ASCII-encoded domain-names is fragile, and 214 the use of ASCII encoding in this option should be considered 215 deprecated. 217 The remaining bits in the Flags field are reserved for future 218 assignment. DHCP clients and servers which send the FQDN option MUST 219 set the MBZ bits to 0, and they MUST ignore values in the part of 220 the field labelled "MBZ". 222 4.2 The RCODE Fields 224 The RCODE1 and RCODE2 fields are used by a DHCP server to indicate 225 to a DHCP client the Response Code from any A or PTR RR Dynamic DNS 226 Updates it has performed. The server also uses these fields to 227 indicate whether it has attempted such an update before sending the 228 DHCPACK message. Each of these fields is one byte long. 230 4.3 The Domain Name Field 232 The Domain Name part of the option carries the FQDN of a DHCP 233 client. A client may be configured with a fully-qualified domain 234 name, or with a partial name that is not fully-qualified. If a 235 client knows only part of its name, it MAY send a single label, 236 indicating that it knows part of the name but does not necessarily 237 know the zone in which the name is to be embedded. The data in the 238 Domain Name field may appear in one of two formats: ASCII (with no 239 terminating NULL), or DNS encoding as specified in RFC1035[2]. If 240 the DHCP client wishes to use DNS encoding, it MUST set the 241 third-from-rightmost bit in the Flags field (the "E" bit); if it 242 uses ASCII encoding, it must clear the "E" bit. 244 A DHCP client that can only send a single label using ASCII encoding 245 includes a series of ASCII characters in the Domain Name field, 246 excluding the "." (dot) character. The client SHOULD follow the 247 character-set recommendations of RFC1034[1] and RFC1035[2]. A client 248 using DNS encoding which wants to suggest part of its FQDN MAY send 249 a non-terminal sequence of labels in the Domain Name part of the 250 option. 252 5. DHCP Client behavior 254 The following describes the behavior of a DHCP client that 255 implements the Client FQDN option. 257 If a client that owns/maintains its own FQDN wants to be responsible 258 for updating the FQDN to IP address mapping for the FQDN and 259 address(es) used by the client, then the client MUST include the 260 Client FQDN option in the DHCPREQUEST message originated by the 261 client. A DHCP client MAY choose to include the Client FQDN option 262 in its DISCOVER messages as well as its REQUEST messages. The 263 rightmost ("S") bit in the Flags field in the option MUST be set to 264 0. Once the client's DHCP configuration is completed (the client 265 receives a DHCPACK message, and successfully completes a final check 266 on the parameters passed in the message), the client MAY originate 267 an update for the A RR (associated with the client's FQDN). The 268 update MUST be originated following the procedures described in 269 RFC2136[5], and Section 7. If the DHCP server from which the client 270 is requesting a lease includes the FQDN option in its ACK message, 271 and if the server sets both the "S" and the "O" (the two rightmost) 272 bits in the option's flags field, the DHCP client MUST NOT initiate 273 an update for the name in the Domain Name field. 275 A client can choose to delegate the responsibility for updating the 276 FQDN to IP address mapping for the FQDN and address(es) used by the 277 client to the server. In order to inform the server of this choice, 278 the client SHOULD include the Client FQDN option in its DHCPREQUEST 279 message. The rightmost (or "S") bit in the Flags field in the option 280 MUST be set to 1. A client which delegates this responsibility MUST 281 NOT attempt to perform a Dynamic DNS update for the name in the 282 Domain Name field of the FQDN option. The client MAY supply an FQDN 283 in the Client FQDN option, or it MAY supply a single label (the 284 most-specific label), or it MAY leave that field empty as a signal 285 to the server to generate an FQDN for the client in any manner the 286 server chooses. 288 Since there is a possibility that the DHCP server may be configured 289 to complete or replace a domain name that the client was configured 290 to send, the client might find it useful to send the FQDN option in 291 its DISCOVER messages. If the DHCP server returns different Domain 292 Name data in its OFFER message, the client could use that data in 293 performing its own eventual A RR update, or in forming the FQDN 294 option that it sends in its REQUEST message. There is no requirement 295 that the client send identical FQDN option data in its DISCOVER and 296 REQUEST messages. In particular, if a client has sent the FQDN 297 option to its server, and the configuration of the client changes so 298 that its notion of its domain name changes, it MAY send the new name 299 data in an FQDN option when it communicates with the server again. 300 This may allow the DHCP server to update the name associated with 301 the PTR record, and, if the server updated the A record representing 302 the client, to delete that record and attempt an update for the 303 client's current domain name. 305 A client that delegates the responsibility for updating the FQDN to 306 IP address mapping to a server might not receive any indication 307 (either positive or negative) from the server whether the server was 308 able to perform the update. In this case the client MAY use a DNS 309 query to check whether the mapping is updated. 311 A client MUST set the RCODE1 and RCODE2 fields in the Client FQDN 312 option to 0 when sending the option. 314 If a client releases its lease prior to the lease expiration time 315 and the client is responsible for updating its A RR, the client 316 SHOULD delete the A RR (following the procedures described in 317 Section 7) associated with the leased address before sending a DHCP 318 RELEASE message. Similarly, if a client was responsible for updating 319 its A RR, but is unable to renew its lease, the client SHOULD 320 attempt to delete the A RR before its lease expires. A DHCP client 321 which has not been able to delete an A RR which it added (because it 322 has lost the use of its DHCP IP address) should attempt to notify 323 its administrator. 325 6. DHCP Server behavior 327 When a server receives a DHCPREQUEST message from a client, if the 328 message contains the Client FQDN option, and the server replies to 329 the message with a DHCPACK message, the server may be configured to 330 originate an update for the PTR RR (associated with the address 331 leased to the client). Any such update MUST be originated following 332 the procedures described in Section 7. The server MAY complete the 333 update before the server sends the DHCPACK message to the client. In 334 this case the RCODE from the update MUST be carried to the client in 335 the RCODE1 field of the Client FQDN option in the DHCPACK message. 336 Alternatively, the server MAY send the DHCPACK message to the client 337 without waiting for the update to be completed. In this case the 338 RCODE1 field of the Client FQDN option in the DHCPACK message MUST 339 be set to 255. The choice between the two alternatives is entirely 340 determined by the configuration of the DHCP server. Servers SHOULD 341 support both configuration options. 343 When a server receives a DHCPREQUEST message containing the Client 344 FQDN option, the server MUST ignore the values carried in the RCODE1 345 and RCODE2 fields of the option. 347 In addition, if the Client FQDN option carried in the DHCPREQUEST 348 message has the "S" bit in its Flags field set, then the server MAY 349 originate an update for the A RR (associated with the FQDN carried 350 in the option) if it is configured to do so by the site's 351 administrator, and if it has the necessary credentials. The server 352 MAY be configured to use the name supplied in the client's FQDN 353 option, or it MAY be configured to modify the supplied name, or 354 substitute a different name. 356 Any such update MUST be originated following the procedures 357 described in Section 7. The server MAY originate the update before 358 the server sends the DHCPACK message to the client. In this case the 359 RCODE from the update [RFC2136] MUST be carried to the client in the 360 RCODE2 field of the Client FQDN option in the DHCPACK message. 361 Alternatively the server MAY send the DHCPACK message to the client 362 without waiting for the update to be completed. In this case the 363 RCODE2 field of the Client FQDN option in the DHCPACK message MUST 364 be set to 255. The choice between the two alternatives is entirely 365 up to the DHCP server. In either case, if the server intends to 366 perform the DNS update and the client's REQUEST message included the 367 FQDN option, the server SHOULD include the FQDN option in its ACK 368 message, and MUST set the "S" bit in the option's Flags field. 370 Even if the Client FQDN option carried in the DHCPREQUEST message 371 has the "S" bit in its Flags field clear (indicating that the client 372 wants to update the A RR), the server MAY be configured by the local 373 administrator to update the A RR on the client's behalf. A server 374 which is configured to override the client's preference SHOULD 375 include an FQDN option in its ACK message, and MUST set both the "O" 376 and "S" bits in the FQDN option's Flags field. The update MUST be 377 originated following the procedures described in Section 7. The 378 server MAY originate the update before the server sends the DHCPACK 379 message to the client. In this case the RCODE from the update 380 [RFC2136] MUST be carried to the client in the RCODE2 field of the 381 Client FQDN option in the DHCPACK message. Alternatively, the server 382 MAY send the DHCPACK message to the client without waiting for the 383 update to be completed. In this case the RCODE2 field of the Client 384 FQDN option in the DHCPACK message MUST be set to 255. Whether the 385 DNS update occurs before or after the DHCPACK is sent is entirely up 386 to the DHCP server's configuration. 388 When a DHCP server sends the Client FQDN option to a client in the 389 DHCPACK message, the DHCP server SHOULD send its notion of the 390 complete FQDN for the client in the Domain Name field. The server 391 MAY simply copy the Domain Name field from the Client FQDN option 392 that the client sent to the server in the DHCPREQUEST message. The 393 DHCP server MAY be configured to complete or modify the domain name 394 which a client sent, or it MAY be configured to substitute a 395 different name. If the server initiates a DDNS update which is not 396 complete until after the server has replied to the DHCP client, the 397 server's The server MUST use the same encoding format (ASCII or 398 DNS-encoding) that the client used in the FQDN option in its 399 DHCPREQUEST, and MUST set the "E" bit in the option's Flags field 400 accordingly. 402 If a client's DHCPREQUEST message doesn't carry the Client FQDN 403 option (e.g., the client doesn't implement the Client FQDN option), 404 the server MAY be configured to update either or both of the A and 405 PTR RRs. The updates MUST be originated following the procedures 406 described in Section 7. 408 If a server detects that a lease on an address that the server 409 leases to a client has expired, the server SHOULD delete any PTR RR 410 which it added via dynamic update. In addition, if the server added 411 an A RR on the client's behalf, the server SHOULD also delete the A 412 RR. The deletion MUST follow the procedures described in Section 7. 414 If a server terminates a lease on an address prior to the lease's 415 expiration time, for instance by sending a DHCPNAK to a client, the 416 server SHOULD delete any PTR RR which it associated with the address 417 via DNS Dynamic Update. In addition, if the server took 418 responsibility for an A RR, the server SHOULD also delete that A RR. 419 The deletion MUST follow the procedures described in Section 7. 421 7. Procedures for performing DNS updates 423 There are two principal issues that need to be addressed concerning 424 A RR DNS updates: 426 7.1 Name Collisions 428 If the entity updating the A RR (either the DHCP client or DHCP 429 server) attempts to perform a DNS update to a domain name that has 430 an A RR which is already in use by a different DHCP client, what 431 should be done? Similarly, should a DHCP client or server update a 432 domain name which has an A RR that has been configured by an 433 administrator? In either of these cases, the domain name in question 434 would either have an additional A RR, or would have its original A 435 RR replaced by the new record. Either of these effects may be 436 considered undesirable in some sites. This specification describes 437 behavior designed to prevent these undesirable effects, and requires 438 that DHCP implementations make this behavior the default. 440 1. Client updates A RR, uses DNSSEC. Name collisions in this 441 scenario are unlikely (though not impossible), since for the 442 client to use DNSSEC, it has already received credentials 443 specific to the name it desires to use. This implies that the 444 name has already been allocated (through some implementation- or 445 organization-specific procedure, and presumably uniquely) to 446 that client. 448 2. Client updates A RR, uses some form of TSIG. Name collisions in 449 this scenario are possible, since the credentials necessary for 450 the client to update DNS are not necessarily name-specific. 451 Thus, for the client to be attempting to update a unique name 452 requires the existence of some administrative procedure to 453 ensure client configuration with unique names. 455 3. Server updates the A RR, uses a name for the client which is 456 known to the server. Name collisions in this scenario are likely 457 unless prevented by the server's name configuration procedures. 458 See Section 8 for security issues with this form of deployment. 460 4. Server updates the A RR, uses a name supplied by the client. 461 Name collisions in this scenario are highly likely, even with 462 administrative procedures designed to prevent them. (This 463 scenario is a popular one in real-world deployments in many 464 types of organizations.) See Section 8 for security issues with 465 this type of deployment. 467 Scenarios 3 and 4 are much more attractive given some form of DHCP 468 Authentication, but difficulties remain. 470 Scenarios 2, 3, and 4 rely on administrative procedures to ensure 471 name uniqueness for DNS updates, and these procedures may break 472 down. Experience has shown that, in fact, these procedures will 473 break down at least occasionally. The question is what to do when 474 these procedures break down or, for example in scenario #4, may not 475 even exist. 477 In all cases of name collisions, the desire is to offer two modes of 478 operation to the administrator of the combined DHCP-DNS capability: 479 first-update-wins (i.e., the first updating entity gets the name) or 480 most-recent-update-wins (i.e., the last updating entity for a name 481 gets the name). 483 7.2 Multiple DHCP servers 485 If multiple DHCP servers are able to update the same DNS zones, or 486 if DHCP servers are performing A RR updates on behalf of DHCP 487 clients, and more than one DHCP server may be able to serve 488 addresses to the same DHCP clients, the DHCP servers should be able 489 to provide reasonable and consistent DNS name update behavior for 490 DHCP clients. 492 7.3 Use of the KEY RR 494 A solution to both of these problems is for the updating entities 495 (both DHCP clients and DHCP servers) to be able to cooperate when 496 updating DNS A RRs. 498 Specifically, a KEY RR, described in RFC2535[7] is used to associate 499 client ownership information with a DNS name and the A RR associated 500 with that name. When either a client or server adds an A RR for a 501 client, it also adds a KEY RR which specifies a unique client 502 identity (based on a "client specifier" created from the client's 503 client-id or MAC address). In this model, only one A RR is 504 associated with a given DNS name at a time. 506 By associating this ownership information with each A RR, 507 cooperating DNS updating entities may determine whether their client 508 is the first or last updater of the name (and implement the 509 appropriately configured administrative policy), and DHCP clients 510 which currently have a host name may move from one DHCP server to 511 another without losing their DNS name. 513 The specific algorithms utilizing the KEY RR to signal client 514 ownership are explained below. The algorithms only work in the case 515 where the updating entities all cooperate -- this approach is 516 advisory only and does not substitute for DNS security, nor is it 517 replaced by DNS security. 519 7.3.1 Format of the KEY RR 521 The KEY RR used to hold the DHCP client's identity is formatted as 522 follows: 524 The name of the KEY RR is the name of the A or PTR RR which refers 525 to the client. 527 The flags field is set to 0x4200 - that is, the 1 bit and the 6 bit 528 are set. 530 The protocol field is set to [TBD]. 532 The algorithm field is set to [TBD]. 534 0 15 31 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Version | Identity-length | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 / Client-identity... / 539 / / 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 The Version field indicates the version of the data used in this RR. 543 The Version field is a 2-byte integer in network byte-order. Its 544 value MUST be 1. 546 The remainder of the Key field contains the length of the 547 client-identity, followed by that number of bytes of client-identity 548 data. The data length is represented as a 2-byte integer in network 549 byte order. If a DHCP client sent the client-id option in its 550 request message, the client-identity MUST be identical to the data 551 in the client-id option. If a client did not send the client-id 552 option, the client-identity is constructed from the htype byte, the 553 hlen byte, and hlen bytes of the client's chaddr from its request 554 message. 556 7.4 DNS RR TTLs 558 RRs associated with DHCP clients may be more volatile than 559 statically configured RRs. DHCP clients and servers which perform 560 dynamic updates should attempt to specify resource record TTLs which 561 reflect this volatility, in order to minimize the possibility that 562 there will be stale records in resolvers' caches. A reasonable basis 563 for RR TTLs is the lease duration itself: TTLs of 1/2 or 1/3 the 564 expected lease duration might be reasonable defaults. Because 565 configured DHCP lease times vary widely from site to site, it may 566 also be desirable to establish a fixed TTL ceiling. DHCP clients and 567 servers MAY allow administrators to configure the TTLs they will 568 supply, possibly as a fraction of the actual lease time, or as a 569 fixed value. 571 7.5 Adding A RRs to DNS 573 When a DHCP client or server intends to update an A RR, it first 574 prepares a DNS UPDATE query which includes as a prerequisite the 575 assertion that the name does not exist. The update section of the 576 query attempts to add the new name and its IP address mapping (an A 577 RR), and the KEY RR with its unique client-identity. 579 If this update operation succeeds, the updater can conclude that it 580 has added a new name whose only RRs are the A and KEY RR records. 581 The A RR update is now complete (and a client updater is finished, 582 while a server might proceed to perform a PTR RR update). 584 If the first update operation fails with YXDOMAIN, the updater can 585 conclude that the intended name is in use. The updater then 586 attempts to confirm that the DNS name is not being used by some 587 other host. The updater prepares a second UPDATE query in which the 588 prerequisite is that the desired name has attached to it a KEY RR 589 whose contents match the client identity. The update section of 590 this query deletes the existing A records on the name, and adds the 591 A record that matches the DHCP binding and the KEY RR with the 592 client identity. 594 If this query succeeds, the updater can conclude that the current 595 client was the last client associated with the domain name, and that 596 the name now contains the updated A RR. The A RR update is now 597 complete (and a client updater is finished, while a server would 598 then proceed to perform a PTR RR update). 600 If the second query fails with NXRRSET, the updater must conclude 601 that the client's desired name is in use by another host. At this 602 juncture, the updater can decide (based on some administrative 603 configuration outside of the scope of this document) whether to let 604 the existing owner of the name keep that name, and to (possibly) 605 perform some name disambiguation operation on behalf of the current 606 client, or to replace the RRs on the name with RRs that represent 607 the current client. If the configured policy allows replacement of 608 existing records, the updater submits a query that deletes the 609 existing A RR and the existing KEY RR, adding A and KEY RRs that 610 represent the IP address and client-identity of the new client. 612 DISCUSSION: 614 The updating entity may be configured to allow the existing DNS 615 records on the domain name to remain unchanged, and to perform 616 disambiguation on the name of the current client in order to 617 attempt to generate a similar but unique name for the current 618 client. In this case, once another candidate name has been 619 generated, the updater should restart the process of adding an A 620 RR as specified in this section. 622 7.6 Adding PTR RR Entries to DNS 624 The DHCP server submits a DNS query which deletes all of the PTR RRs 625 associated with the lease IP address, and adds a PTR RR whose data 626 is the client's (possibly disambiguated) host name. The server also 627 adds a KEY RR specified in Section 7.3. 629 7.7 Removing Entries from DNS 631 The first rule in removing DNS entries is be sure that an entity 632 removing a DNS entry is only removing an entry that it added. 634 When a lease expires or a DHCP client issues a DHCPRELEASE request, 635 the DHCP server SHOULD delete the PTR RR that matches the DHCP 636 binding, if one was successfully added. The server's update query 637 SHOULD assert that the name in the PTR record matches the name of 638 the client whose lease has expired or been released. 640 The entity chosen to handle the A record for this client (either the 641 client or the server) SHOULD delete the A record that was added when 642 the lease was made to the client. 644 In order to perform this delete, the updater prepares an UPDATE 645 query which contains two prerequisites. The first prerequisite 646 asserts that the KEY RR exists whose data is the client identity 647 described in Section 7.3. The second prerequisite asserts that the 648 data in the A RR contains the IP address of the lease that has 649 expired or been released. 651 If the query fails, the updater MUST NOT delete the DNS name. It 652 may be that the host whose lease on the server has expired has moved 653 to another network and obtained a lease from a different server, 654 which has caused the client's A RR to be replaced. It may also be 655 that some other client has been configured with a name that matches 656 the name of the DHCP client, and the policy was that the last client 657 to specify the name would get the name. In this case, the KEY RR 658 will no longer match the updater's notion of the client-identity of 659 the host pointed to by the DNS name. 661 7.8 Updating other RRs 663 The procedures described in this document only cover updates to the 664 A and PTR RRs. Updating other types of RRs is outside the scope of 665 this document. 667 8. Security Considerations 669 Unauthenticated updates to the DNS can lead to tremendous confusion, 670 through malicious attack or through inadvertent misconfiguration. 671 Administrators should be wary of unsecured DNS updates to zones 672 which are exposed to the global Internet. 674 Whether the client may be responsible for updating the FQDN to IP 675 address mapping, or whether the this responsibility lies with the 676 DHCP server is a site-local matter. The choice between the two 677 alternatives may be based on a particular security model that is 678 used with the Dynamic DNS Update protocol (e.g., only a client may 679 have sufficient credentials to perform updates to the FQDN to IP 680 address mapping for its FQDN). 682 Whether a DHCP server is always responsible for updating the FQDN to 683 IP address mapping (in addition to updating the IP to FQDN mapping), 684 regardless of the wishes of a DHCP client, is a site-local matter. 685 The choice between the two alternatives may be based on a particular 686 security model. Both DHCP clients and servers SHOULD use some form 687 of update request origin authentication procedure (e.g., TSIG[8], 688 Simple Secure DNS Update[10]) when performing DNS updates. 690 While the DHCP client MAY be the one to update the DNS A record, in 691 certain configurations a DHCP server MAY do so instead. In this 692 case, the DHCP server MUST be sure of both the name to use for the 693 client, as well as the identity of the client. 695 In the general case, both of these conditions are difficult to 696 satisfy, given the absence of security from the DHCP protocol 697 itself. There are many ways for a DHCP server to develop a DNS name 698 to use for a client, but only in certain relatively unusual 699 circumstances will the DHCP server know for certain the identity of 700 the client. If DHCP authentication[9] becomes widely deployed this 701 may become more customary. 703 One example of a situation which offers some extra assurances is one 704 where the DHCP client is connected to a network through an MCNS 705 cable modem, and the CMTS (head-end) of the cable modem ensures that 706 MAC address spoofing simply does not occur. Another example of a 707 configuration that might be trusted is one where clients obtain 708 network access via a network access server using PPP. The NAS itself 709 might be obtaining IP addresses via DHCP, encoding a client 710 identification into the DHCP client-id option. In this case, the 711 network access server as well as the DHCP server might be operating 712 within a trusted environment, in which case the DHCP server could 713 trust that the user authentication and authorization procedure of 714 the remote access server was sufficient, and would therefore trust 715 the client identification encoded within the DHCP client-id. 717 9. Acknowledgements 719 Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter 720 Ford, Edie Gunter, Andreas Gustafsson, R. Barr Hibbs, Kim Kinnear, 721 Stuart Kwan, Ted Lemon, Ed Lewis, Michael Lewis, Josh Littlefield, 722 Michael Patton, and Glenn Stump for their review and comments. 724 References 726 [1] Mockapetris, P., "Domain names - Concepts and Facilities", RFC 727 1034, Nov 1987. 729 [2] Mockapetris, P., "Domain names - Implementation and 730 Specification", RFC 1035, Nov 1987. 732 [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 733 March 1997. 735 [4] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and 736 Answers to Commonly asked ``New Internet User'' Questions", RFC 737 1594, March 1994. 739 [5] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 740 Updates in the Domain Name System", RFC 2136, April 1997. 742 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 743 Levels", RFC 2119, March 1997. 745 [7] Eastlake, D., "Domain Name System Security Extensions", RFC 746 2535, March 1999. 748 [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 749 "Secret Key Transaction Signatures for DNS (TSIG) 750 (draft-ietf-dnsind-tsig-*)", July 1999. 752 [9] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages 753 (draft-ietf-dhc-authentication-*)", June 1999. 755 [10] Wellington, B., "Simple Secure DNS Dynamic Updates 756 (draft-ietf-dnsind-simple-secure-update-*)", June 1999. 758 Authors' Addresses 760 Mark Stapp 761 Cisco Systems, Inc. 762 250 Apollo Dr. 763 Chelmsford, MA 01824 764 US 766 Phone: 978.244.8498 767 EMail: mjs@cisco.com 769 Yakov Rekhter 770 Cisco Systems, Inc. 771 170 Tasman Dr. 772 San Jose, CA 95134 773 US 775 Phone: 914.235.2128 776 EMail: yakov@cisco.com 778 Full Copyright Statement 780 Copyright (C) The Internet Society (1999). All Rights Reserved. 782 This document and translations of it may be copied and furnished to 783 others, and derivative works that comment on or otherwise explain it 784 or assist in its implmentation may be prepared, copied, published 785 and distributed, in whole or in part, without restriction of any 786 kind, provided that the above copyright notice and this paragraph 787 are included on all such copies and derivative works. However, this 788 document itself may not be modified in any way, such as by removing 789 the copyright notice or references to the Internet Society or other 790 Internet organizations, except as needed for the purpose of 791 developing Internet standards in which case the procedures for 792 copyrights defined in the Internet Standards process must be 793 followed, or as required to translate it into languages other than 794 English. 796 The limited permissions granted above are perpetual and will not be 797 revoked by the Internet Society or its successors or assigns. 799 This document and the information contained herein is provided on an 800 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 801 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 802 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 803 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 804 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 806 Acknowledgement 808 Funding for the RFC editor function is currently provided by the 809 Internet Society.