idnits 2.17.1 draft-ietf-dhc-dhcp-dns-10.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 17 pages 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. ** The abstract seems to contain references ([RFC2136]), 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 == Line 740 has weird spacing: '...for the purpo...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: If the DHCPREQUEST message received by a DHCP server from a DHCP client doesn't carry the Client FQDN option (e.g., the client doesn't implement the Client FQDN option), and the DHCP client acquires its FQDN from a DHCP server (as part of a normal DHCP transaction), then the server MAY be configured to update both A and PTR RRs. Any updates MUST be originated following the procedures described in Sec-tion 3.4. In this case, the server MAY NOT wish to return the FQDN option to a client which may not be able to understand it. If it can, the DHCP server MAY (optionally) return the host part of the domain name that it will use for the client in the host-name DHCP option (defined in [RFC2132]). Note that it may not be possible to con-sistently encode some domain name data in the format specified by the host-name option. -- 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 (December 1999) is 8892 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) == Missing Reference: 'RFC2535' is mentioned on line 475, but not defined ** Obsolete undefined reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Missing Reference: 'TBD' is mentioned on line 659, but not defined ** Obsolete normative reference: RFC 1594 (Obsoleted by RFC 2664) ** Obsolete normative reference: RFC 2535 (ref. 'DNSSEC') (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. 'TSIG' -- No information found for draft-ietf-dhc-authentication- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DHCPAUTH' Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Yakov Rekhter 2 INTERNET-DRAFT Mark Stapp 3 Cisco Systems 5 June 1999 6 Expires 7 December 1999 9 Interaction between DHCP and DNS 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (1999). All Rights Reserved. 37 Abstract 39 DHCP provides a powerful mechanism for IP host configuration. 40 However, the configuration capability provided by DHCP does not 41 include updating DNS, and specifically updating the name to address 42 and address to name mappings maintained in the DNS. 44 This document specifies how DHCP clients and servers should use the 45 Dynamic DNS Updates mechanism in [RFC2136] to update the DNS name to 46 address and address to name mappings so that the mappings for DHCP 47 clients will be consistent with the IP addresses that the clients 48 acquire via DHCP. 50 1. Terminology 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119]. 56 2. Interaction between DHCP and DNS 58 DNS [RFC1034, RFC1035] maintains (among other things) the information 59 about mapping between hosts' Fully Qualified Domain Names (FQDNs) 60 [RFC1594] and IP addresses assigned to the hosts. The information is 61 maintained in two types of Resource Records (RRs): A and PTR. The A 62 RR contains a mapping from an FQDN to an IP address; the PTR RR con- 63 tains a mapping from an IP address to a FQDN. The Dynamic DNS 64 Updates specification [RFC2136] describes a mechanism that enables 65 DNS information to be updated over a network. 67 DHCP [RFC2131] provides a mechanism by which a host (a DHCP client) 68 could acquire certain configuration information, and specifically its 69 IP address(es). However, DHCP does not provide any mechanisms to 70 update the DNS RRs that contain the information about mapping between 71 the host's FQDN and its IP address(es) (A and PTR RRs). Thus the 72 information maintained by DNS for a DHCP client may be incorrect - a 73 host (the client) could acquire its address by using DHCP, but the A 74 RR for the host's FQDN wouldn't reflect the address that the host 75 acquired, and the PTR RR for the acquired address wouldn't reflect 76 the host's FQDN. 78 The Dynamic DNS Update protocol can be used to maintain consistency 79 between the information stored in the A and PTR RRs and the actual 80 address assignment done via DHCP. When a host with a particular FQDN 81 acquires its IP address via DHCP, the A RR associated with the host's 82 FQDN would be updated (by using the Dynamic DNS Updates protocol) to 83 reflect the new address. Likewise, when an IP address gets assigned 84 to a host with a particular FQDN, the PTR RR associated with this 85 address would be updated (using the Dynamic DNS Updates protocol) to 86 reflect the new FQDN. 88 Although this document refers to the A and PTR DNS record types and 89 to DHCP assignment of IPv4 addresses, the same procedures and 90 requirements should apply for updates to the analogous RR types that 91 are used when clients are assigned IPv6 addresses via DHCPv6. 93 3. Models of operation 95 When a DHCP client acquires a new address, both the A RR (for the 96 client's FQDN) and the PTR RR (for the acquired address) have to be 97 updated. Therefore, two separate Dynamic DNS Update transactions 98 occur. Acquiring an address via DHCP involves two entities: a DHCP 99 client and a DHCP server. In principle each of these entities could 100 perform none, one, or both of the transactions. However, upon reflec- 101 tion one could realize that not all permutations make sense. This 102 document covers the possible design permutations: 104 (1) DHCP client updates the A RR, DHCP server updates the PTR RR 106 (2) DHCP server updates both the A and the PTR RRs 108 One could observe that the only difference between these two cases is 109 whether the FQDN to IP address mapping is updated by a DHCP client or 110 by a DHCP server. The IP address to FQDN mapping is updated by a DHCP 111 server in both cases. 113 The reason these two are important, while others are unlikely, has to 114 do with authority over the respective DNS domain names. A client may 115 be given authority over mapping its own A RRs, or that authority may 116 be restricted to a server to prevent the client from listing arbi- 117 trary addresses or associating its address with arbitrary domain 118 names. In all cases, the only reasonable place for the authority over 119 the PTR RRs associated with the address is in the DHCP server that 120 allocates them. 122 In any case, whether a site permits all, some, or no DHCP servers and 123 clients to perform DNS updates into the zones which it controls is 124 entirely a matter of local administrative policy. This document does 125 not require any specific administrative policy, and does not propose 126 one. The range of possible policies is very broad, from sites where 127 only the DHCP servers have been given credentials that the DNS 128 servers will accept, to sites where each individual DHCP client has 129 been configured with credentials which allow the client to modify its 130 own domain name. Compliant implementations will support some or all 131 of these possibilities. 133 This document describes a new DHCP option which a client can use to 134 convey all or part of its domain name to a DHCP server. Site-specific 135 policy determines whether DHCP servers use the names that clients 136 offer or not, and what DHCP servers should do in cases where clients 137 do not supply domain names. 139 3.1. Client FQDN Option 141 To update the IP address to FQDN mapping a DHCP server needs to know 142 the FQDN of the client to which the server leases the address. To 143 allow the client to convey its FQDN to the server this document 144 defines a new DHCP option, called "Client FQDN". The FQDN Option also 145 contains Flags and RCode fields which DHCP servers can use to convey 146 information about DNS updates to clients. 148 Clients MAY send the FQDN option, setting appropriate Flags values, 149 in both their DISCOVER and REQUEST messages. If a client sends the 150 FQDN option in its DISCOVER message, it MUST send the option in sub- 151 sequent REQUEST messages. 153 The code for this option is 81. Its minimum length is 4. 155 Code Len Flags RCODE1 RCODE2 Domain Name 156 +------+------+------+------+------+------+-- 157 | 81 | n | | | | ... 158 +------+------+------+------+------+------+-- 160 3.1.1. The Flags Field 162 This figure presents the format of the Flags field, which is one byte 163 long: 165 0 1 2 3 4 5 6 7 166 +-+-+-+-+-+-+-+-+ 167 | MBZ |E|O|S| 168 +-+-+-+-+-+-+-+-+ 170 When a client sends the FQDN option in its DHCPDISCOVER and/or 171 DHCPREQUEST messages, it sets the right-most bit (labelled "S") to 172 indicate that it will not perform any Dynamic DNS updates, and that 173 it expects the DHCP server to perform any FQDN-to-IP (the A RR) DNS 174 update on its behalf. If this bit is clear, the client indicates that 175 it intends to perform its own FQDN-to-IP mapping update. 177 If a DHCP server intends to take responsibility for the A RR update 178 whether or not the client sending the FQDN option has set the "S" 179 bit, it sets both the "O" bit and the "S" bit, and sends the FQDN 180 option in its corresponding DHCPOFFER and/or DHCPACK messages. 182 The data in the Domain Name field may appear in one of two formats: 183 ASCII, or DNS-style binary encoding (without compression, of course). 184 A client which sends the FQDN option sets the "E" bit to indicate 185 that the data in the Domain Name field is DNS-encoded, as described 186 in [RFC1035]. 188 The remaining bits in the Flags field are reserved for future assign- 189 ment. DHCP clients and servers which send the FQDN option MUST set 190 the MBZ bits to 0, and they MUST ignore values in the part of the 191 field labelled "MBZ". 193 3.1.2. The RCODE Fields 195 The RCODE1 and RCODE2 fields are used by a DHCP server to indicate to 196 a DHCP client the Response Code from the an A RR Dynamic DNS Update 197 performed on the client's behalf. The server also uses these fields 198 to indicate whether it has attempted such an update before sending 199 the DHCPACK message. Each of these fields is one byte long. 201 3.1.3. The Domain Name Field 203 The Domain Name part of the option carries the FQDN of a DHCP client. 204 A client may be configured with a fully-qualified domain name, or 205 with a partial name that is not fully-qualified. If a client knows 206 only part of its name, it MAY send a single label, indicating that it 207 knows part of the name but does not necessarily know the zone in 208 which the name is to be embedded. The data in the Domain Name field 209 may appear in one of two formats: ASCII (with no terminating NULL), 210 or DNS encoding as specified in [RFC1035]. If the DHCP client wishes 211 to use DNS encoding, it MUST set the third-from-rightmost bit in the 212 Flags field (the "E" bit); if it uses ASCII encoding, it must clear 213 that Flags bit. 215 A DHCP client that can only send a single label using ASCII encoding 216 includes a series of ASCII characters in the Domain Name field, 217 excluding the "." (dot) character. The client SHOULD follow the 218 character-set recommendations of [RFC1034] and [RFC1035]. A client 219 using DNS encoding sends a single label as a single byte count, fol- 220 lowed by that number of bytes of data, without a terminal reference 221 to the root. 223 3.2. DHCP Client behavior 225 The following describes the behavior of a DHCP client that implements 226 the Client FQDN option. 228 If a client that owns/maintains its own FQDN wants to be responsible 229 for updating the FQDN to IP address mapping for the FQDN and 230 address(es) used by the client, then the client MUST include the 231 Client FQDN option in the DHCPREQUEST message originated by the 232 client. A DHCP client MAY choose to include the Client FQDN option in 233 its DISCOVER messages as well as its REQUEST messages. The rightmost 234 bit in the Flags field in the option MUST be set to 0. Once the 235 client's DHCP configuration is completed (the client receives a 236 DHCPACK message, and successfully completes a final check on the 237 parameters passed in the message), the client SHOULD originate an 238 update for the A RR (associated with the client's FQDN). The update 239 MUST be originated following the procedures described in section 3.4. 240 If the DHCP server from which the client is requesting a lease 241 includes the FQDN option in its ACK message, and if the server sets 242 both the "S" and the "O" bits in the option's Flags field, the client 243 MUST NOT initiate an update for the name in the Domain Name field. 245 A client can choose to delegate the responsibility for updating the 246 FQDN to IP address mapping for the FQDN and address(es) used by the 247 client to the server. In order to inform the server of this choice, 248 the client SHOULD include the Client FQDN option in its DHCPREQUEST 249 message. The rightmost (or "S") bit in the Flags field in the option 250 MUST be set to 1. A client which delegates this responsibility MUST 251 NOT attempt to perform a Dynamic DNS update for the name in the 252 Domain Name field of the FQDN option. The client MAY supply an FQDN 253 in the Client FQDN option, or it MAY supply a single label (the 254 most-specific label), or it MAY leave that field empty as a signal to 255 the server to generate an FQDN for the client in any manner the 256 server chooses. 258 Since there is a possibility that the DHCP server may be configured 259 to complete or replace a domain name that the client was configured 260 to send, the client might find it useful to send the FQDN option in 261 its DISCOVER messages. If the DHCP server returns different Domain 262 Name data in its OFFER message, the client could use that data in 263 performing its own eventual A RR update, or in forming the FQDN 264 option that it sends in its REQUEST message. There is no requirement 265 that the client send identical FQDN option data in its DISCOVER and 266 REQUEST messages. In particular, if a client has sent the FQDN option 267 to its server, and the configuration of the client changes so that 268 its notion of its domain name changes, it should send the new data in 269 an FQDN option when it communicates with the server again. This may 270 allow the DHCP server to update the name associated with the PTR 271 record, and, if the server updated the A record representing the 272 client, to delete that record and attempt an update for the client's 273 current domain name. 275 A client which delegates the responsibility for updating the FQDN to 276 IP address mapping to a server might not receive any indication 277 (either positive or negative) about the status of the update from the 278 server. The client MAY use a DNS query to check whether the mapping 279 is updated. 281 A client MUST set the RCODE1 and RCODE2 fields in the Client FQDN 282 option to 0 when sending the option. 284 If a client releases its lease prior to the lease expiration time and 285 the client is responsible for updating its A RR(s), the client SHOULD 286 delete the A RR (following the procedures described in [RFC2136]) 287 associated with the leased address before sending a DHCPRELEASE mes- 288 sage. Similarly, if a client was responsible for updating its A RR, 289 but is unable to renew its lease, the client SHOULD attempt to delete 290 the A RR before its lease expires. A client which has not been able 291 to delete an A RR which it added (because it has lost its IP address) 292 SHOULD add an entry to its logfile and/or notify its administrator. 294 3.3. DHCP Server behavior 296 When a server receives a DHCPREQUEST message from a client, if the 297 message contains the Client FQDN option, and the server replies to 298 the message with a DHCPACK message, the server SHOULD originate an 299 update for the PTR RR associated with the address leased to the 300 client if the server is configured to perform DNS updates. The update 301 MUST be originated following the procedures described in Section 3.4. 302 The server MAY complete the update before the server sends the 303 DHCPACK message to the client. In this case the RCODE from the update 304 [RFC2136] MUST be carried to the client in the RCODE1 field of the 305 Client FQDN option in the DHCPACK message. Alternatively, the server 306 MAY send the DHCPACK message to the client without waiting for the 307 update to be completed. In this case the RCODE1 field of the Client 308 FQDN option in the DHCPACK message MUST be set to 255. The choice 309 between the two alternatives is entirely determined by the configura- 310 tion of the DHCP server. Servers SHOULD support both configuration 311 options. 313 In addition, if the Client FQDN option carried in the DHCPREQUEST 314 message has the "S" bit in its Flags field set, then the server MAY 315 originate an update for the A RR (associated with the FQDN carried in 316 the option) if it is configured to do so by the site's administrator, 317 and if it has the necessary credentials. The server MAY be configured 318 to use the name supplied by the client, or it MAY be configured to 319 modify the supplied name, or substitute a different name. 321 The update MUST be originated following the procedures described in 322 Section 3.4. The server MAY originate the update before the server 323 sends the DHCPACK message to the client. In this case the RCODE from 324 the update [RFC2136] MUST be carried to the client in the RCODE2 325 field of the Client FQDN option in the DHCPACK message. Alterna- 326 tively the server MAY send the DHCPACK message to the client without 327 waiting for the update to be completed. In this case the RCODE2 field 328 of the Client FQDN option in the DHCPACK message MUST be set to 255. 329 The choice between the two alternatives is entirely up to the DHCP 330 server. In either case, if the server intends to perform the DNS 331 update and the client's REQUEST message included the FQDN option, the 332 server SHOULD include the FQDN option in its ACK message, and MUST 333 set the "S" bit in the option's Flags field. 335 Even if the Client FQDN option carried in the DHCPREQUEST message has 336 the "S" bit its Flags field clear (indicating that the client wants 337 to update the A RR), the server MAY, be configured byt the local 338 administrator to update the A RR on the client's behalf. A server 339 which is configured to override the client's preference SHOULD 340 include an FQDN option in its ACK message, and MUST set both the "O" 341 and "S" bits in the FQDN option's Flags field. The update MUST be 342 originated following the procedures described in Section 3.4. The 343 server MAY originate the update before the server sends the DHCPACK 344 message to the client. In this case the RCODE from the update 345 [RFC2136] MUST be carried to the client in the RCODE2 field of the 346 Client FQDN option in the DHCPACK message. Alternatively, the server 347 MAY send the DHCPACK message to the client without waiting for the 348 update to be completed. In this case the RCODE2 field of the Client 349 FQDN option in the DHCPACK message MUST be set to 255. Whether the 350 DNS update occurs before or after the DHCPACK is sent is entirely up 351 to the DHCP server's configuration. 353 When a server receives a DHCPREQUEST message from a client, and the 354 message contains the Client FQDN option, the server MUST ignore the 355 values carried in the RCODE1 and RCODE2 fields of the option. 357 When a DHCP server sends the Client FQDN option to a client in the 358 DHCPACK message, the server MUST copy the Domain Name field from the 359 Client FQDN option that the client sent to the server in the DHCPRE- 360 QUEST message. If, however, the client sent only a single label, or 361 if the DHCP server has been configured to assign the client a name 362 different from the one the client has sent, the server SHOULD send 363 its notion of the complete FQDN for the client. The server MUST use 364 the same encoding format (ASCII or DNS-encoding) that the client used 365 in the FQDN option in its DHCPREQUEST, and MUST set the "E" bit in 366 the option's Flags field accordingly. 368 If the DHCPREQUEST message received by a DHCP server from a DHCP 369 client doesn't carry the Client FQDN option (e.g., the client doesn't 370 implement the Client FQDN option), and the DHCP client acquires its 371 FQDN from a DHCP server (as part of a normal DHCP transaction), then 372 the server MAY be configured to update both A and PTR RRs. Any 373 updates MUST be originated following the procedures described in Sec- 374 tion 3.4. In this case, the server MAY NOT wish to return the FQDN 375 option to a client which may not be able to understand it. If it can, 376 the DHCP server MAY (optionally) return the host part of the domain 377 name that it will use for the client in the host-name DHCP option 378 (defined in [RFC2132]). Note that it may not be possible to con- 379 sistently encode some domain name data in the format specified by the 380 host-name option. 382 If a server detects that a lease on an address that the server leases 383 to a client has expired or has been released by the client, the 384 server SHOULD delete the PTR RR which it associated with the address 385 via DNS Dynamic Update. In addition, if the server added an A RR on 386 behalf of the client, the server SHOULD also delete the A RR. The 387 deletion MUST follow the procedures described in Section 3.4. 389 If a server terminates a lease on an address prior to the lease's 390 expiration time, for instance by sending a DHCPNAK to a client, the 391 server SHOULD delete the PTR RR which it associated with the address 392 via DNS Dynamic Update. In addition, if the server took responsibil- 393 ity for the client's A RR , the server SHOULD also delete that A RR. 394 The deletion MUST follow the procedures described in Section 3.4. 396 3.4. Procedures for performing DNS updates 398 There are two principal issues that need to be addressed concerning A 399 RR DNS updates: 401 o Name Collisions 403 If the entity updating the A RR (either the DHCP client or DHCP 404 server) attempts to perform a DNS update to a domain name that 405 has an A RR which is already in use by a different DHCP client, 406 what should be done? Similarly, should a DHCP client or server 407 update a domain name which has an A RR that has been configured 408 by an administrator? In either of these cases, the domain name 409 in question would either have an additional A RR, or would have 410 its original A RR replaced by the new record. Either of these 411 effects may be considered undesirable in some sites. This 412 specification describes behavior designed to prevent these 413 undesirable effects, and requires that implementations make this 414 behavior the default. In some scenarios these name collisions 415 are unlikely, in some scenarios they are very likely: 417 1. Client updates A RR, uses DNSSEC: Name collisions in this 418 scenario are unlikely (though not impossible), since for the 419 client to use DNSSEC, it has already received credentials 420 specific to the name it desires to use. This implies that 421 the name has already been allocated (through some 422 implementation- or organization-specific procedure, and 423 presumably uniquely) to that client. 425 2. Client updates A RR, uses some form of TSIG: Name colli- 426 sions in this scenario are possible, since the credentials 427 necessary for the client to update DNS are not necessarily 428 name-specific. Thus, for the client to be attempting to 429 update a unique name requires the existence of some adminis- 430 trative procedure to ensure client configuration with unique 431 names. 433 3. Server updates the A RR, uses a name for the client which 434 is known to the server: Name collisions in this scenario are 435 likely unless prevented by the server's name configuration 436 procedures. See Section 5 for security issues with this form 437 of deployment. 439 4. Server updates the A RR, uses a name supplied by the 440 client: Name collisions in this scenario are highly likely, 441 even with administrative procedures designed to prevent them. 442 (This scenario is a popular one in real-world deployments in 443 many types of organizations.) See Section 5 for security 444 issues with this type of deployment. 446 Scenarios 3 and 4 are much more attractive given some form of 447 DHCP Authentication, but the difficulties remain. 449 Scenarios 2, 3, and 4 rely on administrative procedures to 450 ensure name uniqueness for DNS updates, and these procedures may 451 break down. Experience has shown that, in fact, these pro- 452 cedures will break down at least occasionally. The question is 453 what to do when these procedures break down or, for example in 454 scenario #4, may not even exist. 456 In all cases of name collisions, the desire is to offer two 457 modes of operation to the administrator of the combined DHCP-DNS 458 capability: first-update-wins (i.e., the first updating entity 459 gets the name) or most-recent-update-wins (i.e., the last updat- 460 ing entity for a name gets the name). 462 o Multiple DHCP servers 464 If multiple DHCP servers are able to update the same DNS zones, 465 or if DHCP servers are performing A RR updates on behalf of DHCP 466 clients, and more than one DHCP server may be able to serve 467 addresses to the same population of DHCP clients, the DHCP 468 servers should be able to provide reasonable DNS name update 469 behavior for DHCP clients. 471 The solution to both of these problems is for the updating entities 472 (either DHCP clients or DHCP servers) to be able to cooperate when 473 updating DNS A RRs. 475 Specifically, a KEY RR, described in [RFC2535] is used to associate 476 client ownership information with a DNS name and the A RR associated 477 with that name. When either a client or server adds an A RR for a 478 client, it also adds a KEY RR which specifies a unique client iden- 479 tity (based on a "client specifier" created from the client's 480 client-id or MAC address: see Appendix A). In this model, only one A 481 RR is associated with a given DNS name at a time. 483 By associating this ownership information with each A RR, cooperating 484 DNS updating entities may determine whether their client is the first 485 or last updater of the name (and implement the appropriately config- 486 ured administrative policy), and DHCP clients which currently have a 487 host name may move from one DHCP server to another without losing 488 their DNS name. 490 See Appendix A for the details of the use of the KEY RR for this pur- 491 pose. 493 The specific algorithms utilizing the KEY RR to signal client owner- 494 ship are explained below. The algorithms only work in the case where 495 the updating entities all cooperate -- this approach is advisory only 496 and does not substitute for DNS security, nor is it replaced by DNS 497 security. 499 3.4.1. Adding A RRs to DNS 501 When a DHCP client or server intends to update an A RR, it first 502 prepares a DNS UPDATE query which includes as a prerequisite the 503 assertion that the name does not exist. The update section of the 504 query attempts to add the new name and its IP address mapping and the 505 KEY RR with its unique client-identity. 507 If this update operation succeeds, the updater can conclude that it 508 has added a new name whose only RRs are the A and KEY RR records. 509 The A RR update is now complete (and a client updater is finished, 510 while a server would then proceed to perform a PTR RR update). 512 If the first update operation fails with YXDOMAIN, the updater can 513 conclude that the intended name is in use. The updater then attempts 514 to confirm that the DNS name is not being used by some other host. 516 The updater prepares a second UPDATE query in which the prerequisite 517 is that the desired name has attached to it a KEY RR whose contents 518 match the client identity (see Appendix A). The update section of 519 this query deletes the existing A records on the name, and adds the A 520 record that matches the DHCP binding and the KEY RR with the client 521 identity. 523 If this query succeeds, the updater can conclude that the current 524 client was the last user of this name, and that the name now contains 525 the updated A RR. The A RR update is now complete (and a client 526 updater is finished, while a server would then proceed to perform a 527 PTR RR update). 529 If the second query fails with NXRRSET, the updater must conclude 530 that the client's desired name is in use by another host. At this 531 juncture, the updater can decide (based on some administrative confi- 532 guration outside of the scope of this document) whether to let the 533 existing owner of the name keep that name, and to (possibly) perform 534 some name disambiguation operation on behalf of the current client, 535 or to 'take-over' the name on behalf of the current client. 537 DISCUSSION: 539 The updating entity may be configured to allow the existing owner 540 to keep the name, and to perform disambiguation on the name of the 541 current client in order to attempt to generate a similar but 542 unique name for the current client. In this case, once such a 543 similar name has been generated, the updating entity should res- 544 tart the process of adding an A RR as specified in this section. 546 3.4.2. Adding PTR RR Entries to DNS 548 The DHCP server submits a DNS query which deletes all of the PTR RRs 549 associated with the lease IP address, and adds a PTR RR whose data is 550 the client's (possibly disambiguated) host name. The server also adds 551 a KEY RR whose data is the client's client-identity as described in 552 Appendix A. 554 3.4.3. Removing Entries from DNS 556 The first rule in removing DNS entries is be sure that an entity 557 removing a DNS entry is only removing an entry for which it is 558 responsible. 560 When a lease expires or a DHCP client issues a DHCPRELEASE request, 561 the DHCP server SHOULD delete the PTR RR that matches the DHCP bind- 562 ing, if one was successfully added. The server's update query SHOULD 563 assert that the name in the PTR record matches the name of the client 564 whose lease has expired or been released. 566 The entity chosen to handle the A record for this client (either the 567 client or the server) SHOULD delete the A and KEY records that were 568 added when the lease was made to the client. 570 In order to perform this delete, the updater prepares an UPDATE query 571 which contains two prerequisites. The first prerequisite asserts 572 that the KEY RR exists whose data is the client identity described in 573 Appendix A. The second prerequisite asserts that the data in the A RR 574 contains the IP address of the lease that has expired or been 575 released. 577 If the query's prerequisites fail, the updater MUST NOT delete the 578 DNS name. It may be that the host whose lease on the server has 579 expired has moved to another network and obtained a lease from a dif- 580 ferent server, which has caused the client's A RR to be replaced. It 581 may also be that some other client has been configured with a name 582 that matches the name of the DHCP client, and the administrative pol- 583 icy at the site was that the last client to specify the name would 584 get the name. In this case, the KEY RR will no longer match the 585 updater's notion of the client-identity of the host pointed to by the 586 DNS name. 588 4. Updating other RRs 590 The procedures described in this document only cover updates to the A 591 and PTR RRs. Updating other types of RRs is outside the scope of this 592 document. 594 5. Security Considerations 596 Whether the client may be responsible for updating the FQDN to IP 597 address mapping, or whether the this responsibility lies with the 598 DHCP server is a site-local matter. The choice between the two alter- 599 natives may be based on a particular security model that is used with 600 the Dynamic DNS Update protocol (e.g., only a client may have suffi- 601 cient credentials to perform updates to the FQDN to IP address map- 602 ping for its FQDN). 604 Whether a DHCP server is always responsible for updating the FQDN to 605 IP address mapping (in addition to updating the IP to FQDN mapping), 606 regardless of the wishes of a DHCP client, is also a site-local 607 matter. The choice between the two alternatives may be based on a 608 particular security model. 610 The client SHOULD use some form of data origin authentication pro- 611 cedures (e.g. [TSIG], [DNSSEC]) when performing DNS updates. 613 While the DHCP client MAY be the one to update the DNS A record, in 614 certain specialized cases a DHCP server MAY do so instead. In this 615 case, the DHCP server MUST be sure of both the name to use for the 616 client, as well as the identity of the client. 618 In the general case, both of these conditions are not satisfied -- 619 one needs to be mindful of the possibility of MAC address spoofing in 620 a DHCP packet. It is not difficult for a DHCP server to know unambi- 621 guously the DNS name to use for a client, but only in certain cir- 622 cumstances will the DHCP server know for sure the identity of the 623 client. If DHCP authentication [DHCPAUTH] becomes widely deployed 624 this may become more customary. An example of a situation which 625 offers some extra assurances is one where the DHCP client is con- 626 nected to a network through an MCNS cable modem, and the CMTS (head- 627 end) of the cable modem ensures that MAC address spoofing simply does 628 not occur. 630 Another example where the DHCP server would know the identity of the 631 client would be in a case where it was interacting with a remote 632 access server which encoded a client identification into the DHCP 633 client-id option. In this case, the remote access server as well as 634 the DHCP server would be operating within a trusted environment, and 635 the DHCP server could trust that the user authentication and authori- 636 zation procedure of the remote access server was sufficient, and 637 would therefore trust the client identification encoded within the 638 DHCP client-id. 640 In either of these cases, a DHCP server would be able to correctly 641 enter the DNS A record on behalf of a client, since it would know the 642 name associated with a client (through some administrative procedure 643 outside the scope of this protocol), and it would also know the 644 client's identity in a secure manner. 646 6. Appendix A - Use of the KEY RR 648 The KEY RR used to hold the DHCP client's identity is formatted as 649 follows: 651 The name of the KEY RR is the name of the A or PTR RR which refers to 652 the client. 654 The flags field is set to 0x42 - that is, the 1 bit and the 6 bit are 655 set. 657 The protocol field is set to [TBD]. 659 The algorithm field is set to [TBD]. 661 The first byte in the key field contains the length of the client- 662 identity, and is followed by that number of bytes of client-identity 663 data. If a DHCP client sent the client-id option in its request mes- 664 sage, the client-identity MUST be identical to the data in the 665 client-id option. If a client did not send the client-id option, the 666 client-identity is constructed from the htype byte, the hlen byte, 667 and hlen bytes of the client's chaddr from its request message. 669 7. References 671 [RFC1034] P. Mockapetris, "Domain names - concepts and facilities", 672 RFC1034, 11/01/1987 674 [RFC1035] P. Mockapetris, "Domain names - implementation and specif- 675 ication", RFC1035, 11/01/1987 677 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131, 678 March 1997. 680 [RFC2132] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor 681 Extensions", RFC2132, March 1997. 683 [RFC1594] A. Marine, J. Reynolds, G. Malkin, "FYI on Questions and 684 Answer Answers to Commonly asked ``New Internet User'' 685 Questions", RFC1594, 03/11/1994 687 [RFC2136] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic 688 Updates in the Domain Name System (DNS UPDATE)", RFC2136, 689 April 1997 691 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 692 Requirement Levels", RFC2119. 694 [DNSSEC] D. Eastlake, "Domain Name System Security Extensions", 695 RFC2535, March 1999. 697 [TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, 698 "Secret Key Transaction Signatures for DNS", draft-ietf- 699 dnsind-tsig-*, Work in Progress. 701 [DHCPAUTH] R. Droms, W. Arbaugh, "Authentication for DHCP Messages", 702 draft-ietf-dhc-authentication-*, Work in Progress. 704 8. Acknowledgements 706 Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, 707 Peter Ford, Edie Gunter, R. Barr Hibbs, Kim Kinnear, Stuart Kwan, 708 Ted Lemon, Michael Lewis, Michael Patton, and Glenn Stump for 709 their review and comments. 711 9. Author information 713 Yakov Rekhter 714 Cisco Systems, Inc. 715 170 Tasman Dr. 716 San Jose, CA 95134 717 Phone: (914) 235-2128 718 email: yakov@cisco.com 720 Mark Stapp 721 Cisco Systems, Inc. 722 250 Apollo Drive 723 Chelmsford, MA 01824 724 Phone: (978) 244-8498 725 email: mjs@cisco.com 727 10. Full Copyright Statement 729 Copyright (C) The Internet Society (1999). All Rights Reserved. 731 This document and translations of it may be copied and furnished 732 to others, and derivative works that comment on or otherwise 733 explain it or assist in its implementation may be prepared, 734 copied, published and distributed, in whole or in part, without 735 restriction of any kind, provided that the above copyright notice 736 and this paragraph are included on all such copies and derivative 737 works. However, this document itself may not be modified in any 738 way, such as by removing the copyright notice or references to the 739 Internet Society or other Internet organizations, except as needed 740 for the purpose of developing Internet standards in which case 741 the procedures for copyrights defined in the Internet Standards 742 process must be followed, or as required to translate it into 743 languages other than English. 745 The limited permissions granted above are perpetual and will not 746 be revoked by the Internet Society or its successors or assigns. 748 This document and the information contained herein is provided on 749 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 750 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 751 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 752 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 753 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.