idnits 2.17.1 draft-ietf-dhc-fqdn-option-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 723. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 700. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 707. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 713. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- No issues found here. 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 (March 22, 2006) is 6609 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: '6' is defined on line 620, but no explicit reference was found in the text ** Downref: Normative reference to an Unknown state RFC: RFC 952 (ref. '6') -- No information found for draft-ietf-dhc-ddns-resolution- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '10' -- Obsolete informational reference (is this intentional?): RFC 1594 (ref. '11') (Obsoleted by RFC 2664) -- Obsolete informational reference (is this intentional?): RFC 2671 (ref. '13') (Obsoleted by RFC 6891) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC M. Stapp 3 Internet-Draft B. Volz 4 Expires: September 23, 2006 Cisco Systems, Inc. 5 Y. Rekhter 6 Juniper Networks 7 March 22, 2006 9 The DHCP Client FQDN Option 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 23, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document describes a Dynamic Host Configuration Protocol for 44 IPv4, DHCPv4, option which can be used to exchange information about 45 a DHCPv4 client's fully-qualified domain name and about 46 responsibility for updating the DNS RR related to the client's 47 address assignment. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Models of Operation . . . . . . . . . . . . . . . . . . . 3 54 2. The Client FQDN Option . . . . . . . . . . . . . . . . . . . . 4 55 2.1. The Flags Field . . . . . . . . . . . . . . . . . . . . . 5 56 2.2. The RCODE Fields . . . . . . . . . . . . . . . . . . . . . 6 57 2.3. The Domain Name Field . . . . . . . . . . . . . . . . . . 6 58 2.3.1. Deprecated ASCII Encoding . . . . . . . . . . . . . . 7 59 3. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 7 60 3.1. Interaction With Other Options . . . . . . . . . . . . . . 7 61 3.2. Client Desires to Update A RRs . . . . . . . . . . . . . . 8 62 3.3. Client Desires Server to Do DNS Updates . . . . . . . . . 8 63 3.4. Client Desires No Server DNS Updates . . . . . . . . . . . 8 64 3.5. Domain Name and DNS Update Issues . . . . . . . . . . . . 9 65 4. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 9 66 4.1. When to Perform DNS Updates . . . . . . . . . . . . . . . 10 67 5. DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 6. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . . 12 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 74 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 76 Intellectual Property and Copyright Statements . . . . . . . . . . 17 78 1. Introduction 80 DNS ([2], [3]) maintains (among other things) the information about 81 the mapping between hosts' Fully Qualified Domain Names (FQDNs) [11] 82 and IP addresses assigned to the hosts. The information is 83 maintained in two types of Resource Records (RRs): A and PTR. The 84 DNS update specification ([4]) describes a mechanism that enables DNS 85 information to be updated over a network. 87 The Dynamic Host Configuration Protocol for IPv4 (DHCPv4 or just DHCP 88 in this document) [5] provides a mechanism by which a host (a DHCP 89 client) can acquire certain configuration information, along with its 90 address. This document specifies a DHCP option, the Client FQDN 91 option, which can be used by DHCP clients and servers to exchange 92 information about the client's fully-qualified domain name for an 93 address and who has the responsibility for updating the DNS with the 94 associated A and PTR RRs. 96 1.1. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [1]. 102 1.2. Models of Operation 104 When a DHCP client acquires a new address, a site's administrator may 105 desire that one or both of the A RR for the client's FQDN and the PTR 106 RR for the acquired address be updated. Therefore, two separate DNS 107 update transactions may occur. Acquiring an address via DHCP 108 involves two entities: a DHCP client and a DHCP server. In principle 109 each of these entities could perform none, one, or both of the 110 transactions. However, in practice not all permutations make sense. 111 The DHCP Client FQDN option is primarily intended to operate in the 112 following two cases: 114 1. DHCP client updates the A RR, DHCP server updates the PTR RR 115 2. DHCP server updates both the A and the PTR RRs 117 The only difference between these two cases is whether the FQDN to IP 118 address mapping is updated by a DHCP client or by a DHCP server. The 119 IP address to FQDN mapping is updated by a DHCP server in both cases. 121 The reason these two are important, while others are unlikely, has to 122 do with authority over the respective DNS domain names. A DHCP 123 client may be given authority over mapping its own A RRs, or that 124 authority may be restricted to a server to prevent the client from 125 listing arbitrary addresses or associating its address with arbitrary 126 domain names. In all cases, the only reasonable place for the 127 authority over the PTR RRs associated with the address is in the DHCP 128 server that allocates the address. 130 Note: A third case is supported - the client requests that the server 131 perform no updates. However, this case is presumed to be rare 132 because of the authority issues. 134 It is considered local policy to permit DHCP clients and servers to 135 perform DNS updates to zones. This document does not require any 136 specific administrative policy, and does not propose one. 137 Furthermore, this specification applies only to DHCP client and 138 server processes: it does not apply to other processes which initiate 139 DNS updates. 141 This document describes a DHCP option which a client can use to 142 convey all or part of its domain name to a DHCP server. Site- 143 specific policy determines whether DHCP servers use the names that 144 clients offer or not, and what DHCP servers may do in cases where 145 clients do not supply domain names. 147 2. The Client FQDN Option 149 To update the IP address to FQDN mapping a DHCP server needs to know 150 the FQDN of the client to which the server leases the address. To 151 allow the client to convey its FQDN to the server this document 152 defines a new DHCP option, called "Client FQDN". The Client FQDN 153 option also contains Flags, which DHCP servers can use to convey 154 information about DNS updates to clients, and two deprecated RCODEs. 156 Clients MAY send the Client FQDN option, setting appropriate Flags 157 values, in both their DHCPDISCOVER and DHCPREQUEST messages. If a 158 client sends the Client FQDN option in its DHCPDISCOVER message, it 159 MUST send the option in subsequent DHCPREQUEST messages though the 160 contents of the option MAY change. 162 Only one Client FQDN option MAY appear in a message, though it may be 163 instantiated in a message as multiple options [9]. DHCP clients and 164 servers supporting this option, MUST implement DHCP option 165 concatenation [9]. In the terminology of [9], the Client FQDN option 166 is a concatenation-requiring option. 168 The code for this option is 81. Len contains the number of octets 169 that follow the Len field, and the minimum value is 3 (octets). 171 The format of the Client FQDN option is: 173 Code Len Flags RCODE1 RCODE2 Domain Name 174 +------+------+------+------+------+------+-- 175 | 81 | n | | | | ... 176 +------+------+------+------+------+------+-- 178 The above figure follows the conventions of [12]. 180 2.1. The Flags Field 182 The format of the 1-octet Flags field is: 184 0 1 2 3 4 5 6 7 185 +-+-+-+-+-+-+-+-+ 186 | MBZ |N|E|O|S| 187 +-+-+-+-+-+-+-+-+ 189 The "S" bit indicates whether the server SHOULD or SHOULD NOT perform 190 the A RR (FQDN to address) DNS updates. A client sets the bit to 0 191 to indicate the server SHOULD NOT perform the updates and 1 to 192 indicate the server SHOULD perform the updates. The state of the bit 193 in the reply from the server indicates the action to be taken by the 194 server; if 1, the server has taken responsibility for A RR updates 195 for the FQDN. 197 The "O" bit indicates whether the server has overridden the client's 198 preference for the "S" bit. A client MUST set this bit to 0. A 199 server MUST set this bit to 1 if the "S" bit in its reply to the 200 client does not match the "S" bit received from the client. 202 The "N" bit indicates whether the server SHOULD NOT perform any DNS 203 updates. A client sets this bit to 0 to request that the server 204 SHOULD perform updates (the PTR RR and possibly the A RR based on the 205 "S" bit) or to 1 to request that the server SHOULD NOT perform any 206 DNS updates. A server sets the "N" bit to indicate whether the 207 server SHALL (0) or SHALL NOT (1) perform DNS updates. If the "N" 208 bit is 1, the "S" bit MUST be 0. 210 The "E" bit indicates the encoding of the Domain Name field. 1 211 indicates canonical wire format, without compression, as described in 212 [3], section 3.1. This encoding SHOULD be used by clients and MUST 213 be supported by servers. 0 indicates a now deprecated ASCII encoding 214 (see Section 2.3.1). A server MUST use the same encoding as that 215 used by the client. A server that does not support the deprecated 216 ASCII encoding MUST ignore Client FQDN options that use that 217 encoding. 219 The remaining bits in the Flags field are reserved for future 220 assignment. DHCP clients and servers which send the Client FQDN 221 option MUST clear the MBZ bits, and they MUST ignore these bits. 223 2.2. The RCODE Fields 225 The two 1-octet RCODE1 and RCODE2 fields are deprecated. A client 226 SHOULD set these to 0 when sending the option and SHOULD ignore them 227 on receipt. A server SHOULD set these to 255 when sending the option 228 and MUST ignore them on receipt. 230 As this option with these fields is already in wide use, the fields 231 are retained. These fields were originally defined for use by a DHCP 232 server to indicate to a DHCP client the Response Code from any A 233 (RCODE1) or PTR (RCODE2) RR DNS updates it has performed or a value 234 of 255 was used to indicate that an update had been initiated but had 235 not yet completed. Each of these fields is one octet long. These 236 fields were defined before EDNS0 [13], which describes a mechanism 237 for extending the length of a DNS RCODE to 12 bits, which is another 238 reason to deprecate them. 240 If the client needs to confirm the DNS update has been done, it MAY 241 use a DNS query to check whether the mapping is up to date. However, 242 depending on the load on the DHCP and DNS servers and the DNS 243 propagation delays, the client can only infer success. If the 244 information is not found to be up to date in DNS, the authoritative 245 servers might not have completed the updates or zone transfers, or 246 caching resolvers may yet have updated their caches. 248 2.3. The Domain Name Field 250 The Domain Name part of the option carries all or part of the FQDN of 251 a DHCP client. The data in the Domain Name field SHOULD appear in 252 canonical wire format as specified in [3], section 3.1. If the DHCP 253 client uses the canonical wire format, it MUST set the "E" bit in the 254 Flags field to 1. In order to determine whether the FQDN has changed 255 between message exchanges, the client and server MUST NOT alter the 256 Domain Name field contents unless the FQDN has actually changed. 258 A client MAY be configured with a fully-qualified domain name or with 259 a partial name that is not fully-qualified. If a client knows only 260 part of its name, it MAY send a name that is not fully-qualified, 261 indicating that it knows part of the name but does not necessarily 262 know the zone in which the name is to be embedded. 264 To send a fully-qualified domain name, the Domain Name field is set 265 to the DNS encoded domain name including the terminating zero-length 266 label. To send a partial name, the Domain Name field is set to the 267 DNS encoded domain name without the terminating zero-length label. 269 A client MAY also leave the Domain Name field empty if it desires the 270 server to provide a name. 272 2.3.1. Deprecated ASCII Encoding 274 A substantial population of clients implemented an earlier draft 275 version of this specification, which permitted an ASCII encoding of 276 the Domain Name field. Server implementations SHOULD be aware that 277 clients which send the Client FQDN option with the "E" bit set to 0 278 are using an ASCII encoding of the Domain Name field. Servers MAY be 279 prepared to return an ASCII encoded version of the Domain Name field 280 to such clients. Servers that are not prepared to return an ASCII 281 encoded version MUST ignore the Client FQDN option if the "E" bit is 282 0. The use of ASCII encoding in this option SHOULD be considered 283 deprecated. 285 A DHCP client which used ASCII encoding was permitted to suggest a 286 single label if it was not configured with a fully-qualified name. 287 Such clients send a single label as a series of ASCII characters in 288 the Domain Name field, excluding the "." (dot) character. 290 Clients and servers SHOULD follow the character set rules of [6]RFC 291 952, fourth section ("Assumptions"), first 5 sentences, as modified 292 by [7] section 2.1. However, implementers SHOULD also be aware that 293 some client software may send data intended to be in other character 294 sets. This specification does not require support for other 295 character sets. 297 3. DHCP Client Behavior 299 The following describes the behavior of a DHCP client that implements 300 the Client FQDN option. 302 3.1. Interaction With Other Options 304 Other DHCP options MAY carry data that is related to the Domain Name 305 field of the Client FQDN option. The Host Name option [12], for 306 example, contains an ASCII string representation of the client's host 307 name. In general, a client does not need to send redundant data, and 308 therefore clients which send the Client FQDN option in their messages 309 MUST NOT also send the Host Name option. Clients which receive both 310 the Host Name option and the Client FQDN option from a server SHOULD 311 prefer Client FQDN option data. Section 4 instructs servers to 312 ignore the Host Name option in client messages which include the 313 Client FQDN option. 315 3.2. Client Desires to Update A RRs 317 If a client that owns/maintains its own FQDN wants to be responsible 318 for updating the FQDN to IP address mapping for the FQDN and 319 address(es) used by the client, the client MUST include the Client 320 FQDN option in the DHCPREQUEST message originated by the client. A 321 DHCP client MAY choose to include the Client FQDN option in its 322 DHCPDISCOVER messages as well as its DHCPREQUEST messages. The "S", 323 "O", and "N" bits in the Flags field in the option MUST be 0. 325 Once the client's DHCP configuration is completed (the client 326 receives a DHCPACK message and successfully completes a final check 327 on the parameters passed in the message), the client MAY originate an 328 update for the A RR (associated with the client's FQDN) unless the 329 server has set the "S" bit to 1. If the "S" is 1, the DHCP client 330 SHOULD NOT initiate an update for the name in the server's returned 331 Client FQDN option Domain Name field. However, a DHCP client that is 332 explicitly configured with a FQDN MAY ignore the state of the "S" bit 333 if the server's returned name matches the client's configured name. 335 3.3. Client Desires Server to Do DNS Updates 337 A client can choose to delegate the responsibility for updating the 338 FQDN to IP address mapping for the FQDN and address(es) used by the 339 client to the server. In order to inform the server of this choice, 340 the client SHOULD include the Client FQDN option in its DHCPREQUEST 341 message and MAY include the Client FQDN option in its DHCPDISCOVER. 342 The "S" bit in the Flags field in the option MUST be 1 and the "O" 343 and "N" bits MUST be 0. 345 3.4. Client Desires No Server DNS Updates 347 A client can choose to request that the server perform no DNS updates 348 on its behalf. In order to inform the server of this choice, the 349 client SHOULD include the Client FQDN option in its DHCPREQUEST 350 message and MAY include the Client FQDN option in its DHCPDISCOVER. 351 The "N" bit in the Flags field in the option MUST be 1 and the "S" 352 and "O" bits MUST be 0. 354 Once the client's DHCP configuration is completed (the client 355 receives a DHCPACK message and successfully completes a final check 356 on the parameters passed in the message), the client MAY originate 357 its DNS updates provided the server's "N" bit is 1. If the server's 358 "N" bit is 0, the server MAY perform the PTR RR updates; and, MAY 359 also perform the A RR updates if the "S" bit is 1. 361 3.5. Domain Name and DNS Update Issues 363 As there is a possibility that the DHCP server is configured to 364 complete or replace a domain name that the client sends, the client 365 MAY find it useful to send the Client FQDN option in its DHCPDISCOVER 366 messages. If the DHCP server returns different Domain Name data in 367 its DHCPOFFER message, the client could use that data in performing 368 its own eventual A RR update, or in forming the Client FQDN option 369 that it sends in its DHCPREQUEST message. There is no requirement 370 that the client send identical Client FQDN option data in its 371 DHCPDISCOVER and DHCPREQUEST messages. In particular, if a client 372 has sent the Client FQDN option to its server, and the configuration 373 of the client changes so that its notion of its domain name changes, 374 it MAY send the new name data in a Client FQDN option when it 375 communicates with the server again. This MAY cause the DHCP server 376 to update the name associated with the PTR record, and, if the server 377 updated the A record representing the client, to delete that record 378 and attempt an update for the client's current domain name. 380 A client that delegates the responsibility for updating the FQDN to 381 IP address mapping to a server will not receive any indication 382 (either positive or negative) from the server whether the server was 383 able to perform the update. The client MAY use a DNS query to check 384 whether the mapping is up to date (see Section 2.2). 386 If a client releases its lease prior to the lease expiration time and 387 the client is responsible for updating its A RR, the client SHOULD 388 delete the A RR associated with the leased address before sending a 389 DHCPRELEASE message. Similarly, if a client was responsible for 390 updating its A RR, but is unable to renew its lease, the client 391 SHOULD attempt to delete the A RR before its lease expires. A DHCP 392 client which has not been able to delete an A RR which it added 393 (because it has lost the use of its DHCP IP address) SHOULD attempt 394 to notify its administrator, perhaps by emitting a log message. 396 A client that desires to perform DNS updates to A RRs SHOULD NOT do 397 so if the client's address is a private address [8]. 399 4. DHCP Server Behavior 401 The following describes the behavior of a DHCP server that implements 402 the Client FQDN option when the client's message includes the Client 403 FQDN option. 405 The server examines its configuration and the Flag bits in the 406 client's Client FQDN option to determine how to respond: 408 o If the client's "E" bit is 0 and the server does not support ASCII 409 encoding (Section 2.3.1), the server SHOULD ignore the Client FQDN 410 option. 411 o The server sets to 0 the "S", "O", and "N" bits in its copy of the 412 option it will return to the client. The server copies the 413 client's "E" bit. 414 o If the client's "N" bit is 1 and the server's configuration allows 415 it to honor the client's request for no server initiated DNS 416 updates, the server sets the "N" bit to 1. 417 o Otherwise, if the client's "S" bit is 1 and the server's 418 configuration allows it to honor the client's request for the 419 server to initiate A RR DNS updates, the server sets the "S" to 1. 420 If the server's "S" bit does not match the client's "S" bit, the 421 server sets the "O" bit to 1. 423 The server MAY be configured to use the name supplied in the client's 424 Client FQDN option, or it MAY be configured to modify the supplied 425 name, or substitute a different name. The server SHOULD send its 426 notion of the complete FQDN for the client in the Domain Name field. 427 The server MAY simply copy the Domain Name field from the Client FQDN 428 option that the client sent to the server. The server MUST use the 429 same encoding format (ASCII or DNS binary encoding) that the client 430 used in the Client FQDN option in its DHCPDISCOVER or DHCPREQUEST, 431 and MUST set the "E" bit in the option's Flags field accordingly. 433 If a client sends both the Client FQDN and Host Name option, the 434 server SHOULD ignore the Host Name option. 436 The server SHOULD set the RCODE1 and RCODE2 fields to 255 before 437 sending the Client FQDN message to the client in a DHCPOFFER or 438 DHCPACK. 440 4.1. When to Perform DNS Updates 442 The server SHOULD NOT perform any DNS updates if the "N" bit is 1 in 443 the Flags field of the Client FQDN option in the DHCPACK messages (to 444 be) sent to the client. However, the server SHOULD delete any RRs 445 which it previously added via DNS updates for the client. 447 The server MAY perform the PTR RR DNS update (unless the "N" bit is 448 1). 450 The server MAY perform the A RR DNS update if the "S" bit is 1 in the 451 Flags field of the Client FQDN option in the DHCPACK message (to be) 452 sent to the client. 454 The server MAY perform these updates even if the client's DHCPREQUEST 455 did not carry the Client FQDN option. The server MUST NOT initiate 456 DNS updates when responding to DHCPDISCOVER messages from a client. 458 The server MAY perform its DNS updates (PTR RR or PTR and A RR) 459 before or after sending the DHCPACK message to the client. 461 If the server's A RR DNS update does not complete until after the 462 server has replied to the DHCP client, the server's interaction with 463 the DNS server MAY cause the DHCP server to change the domain name 464 that it associates with the client. This can occur, for example, if 465 the server detects and resolves a domain-name conflict [10]. In such 466 cases, the domain name that the server returns to the DHCP client 467 would change between two DHCP exchanges. 469 If the server previously performed DNS updates for the client and the 470 client's information has not changed, the server MAY skip performing 471 additional DNS updates. 473 When a server detects that a lease on an address that the server 474 leases to a client has expired, the server SHOULD delete any PTR RR 475 which it added via DNS update. In addition, if the server added an A 476 RR on the client's behalf, the server SHOULD also delete the A RR. 478 When a server terminates a lease on an address prior to the lease's 479 expiration time, for instance by sending a DHCPNAK to a client, the 480 server SHOULD delete any PTR RR which it associated with the address 481 via DNS update. In addition, if the server took responsibility for 482 an A RR, the server SHOULD also delete that A RR. 484 5. DNS RR TTLs 486 RRs associated with DHCP clients may be more volatile than statically 487 configured RRs. DHCP clients and servers that perform dynamic 488 updates should attempt to specify resource record TTLs which reflect 489 this volatility, in order to minimize the possibility that answers to 490 DNS queries will return records that refer to DHCP IP address 491 assignments that have expired or been released. 493 The coupling among primary, secondary, and caching DNS servers is 494 'loose'; that is a fundamental part of the design of the DNS. This 495 looseness makes it impossible to prevent all possible situations in 496 which a resolver may return a record reflecting a DHCP assigned IP 497 address that has expired or been released. In deployment, this 498 rarely, if ever, represents a significant problem. Most DHCP-managed 499 clients are infrequently looked-up by name in the DNS, and the 500 deployment of IXFR ([16]) and NOTIFY ([17]) can reduce the latency 501 between updates and their visibility at secondary servers. 503 We suggest these basic guidelines for implementers. In general, the 504 TTLs for RRs added as a result of DHCP IP address assignment activity 505 SHOULD be less than the initial lease time. The RR TTL on a DNS 506 record added SHOULD NOT exceed 1/3 of the lease time, but SHOULD NOT 507 be less than 10 minutes. We recognize that individual administrators 508 will have varying requirements: DHCP servers and clients SHOULD allow 509 administrators to configure TTLs and upper and lower bounds on the 510 TTL values, either as an absolute time interval or as a percentage of 511 the lease time. 513 While clients and servers MAY update the TTL of the records as the 514 lease is about to expire, there is no requirement that they do so as 515 this puts additional load on the DNS system with likely little 516 benefit. 518 6. DNS Update Conflicts 520 This document does not resolve how a DHCP client or server prevent 521 name conflicts. This document addresses only how a DHCP client and 522 server negotiate who will perform the DNS updates and the fully 523 qualified domain name requested or used. 525 Implementers of this work will need to consider how name conflicts 526 will be prevented. If a DNS updater needs a security token in order 527 to successfully perform DNS updates on a specific name, name 528 conflicts can only occur if multiple updaters are given a security 529 token for that name. Or, if the fully qualified domains are based on 530 the specific address bound to a client, conflicts will not occur. 531 Or, a name conflict resolution technique as described in "Resolving 532 Name Conflicts" [10]) SHOULD be used. 534 7. IANA Considerations 536 IANA has already assigned DHCP option 81 to the Client FQDN option. 537 As this document describes the option's use, IANA is requested to 538 reference this document for option 81. 540 8. Security Considerations 542 Unauthenticated updates to the DNS can lead to tremendous confusion, 543 through malicious attack or through inadvertent misconfiguration. 544 Administrators need to be wary of permitting unsecured DNS updates to 545 zones which are exposed to the global Internet. Both DHCP clients 546 and servers should use some form of update request origin 547 authentication procedure (e.g., Secure DNS Dynamic Update [14]) when 548 performing DNS updates. 550 Whether a DHCP client is responsible for updating an FQDN to IP 551 address mapping or whether this is the responsibility of the DHCP 552 server is a site-local matter. The choice between the two 553 alternatives is likely based on the security model that is used with 554 the DNS update protocol (e.g., only a client may have sufficient 555 credentials to perform updates to the FQDN to IP address mapping for 556 its FQDN). 558 Whether a DHCP server is always responsible for updating the FQDN to 559 IP address mapping (in addition to updating the IP to FQDN mapping), 560 regardless of the wishes of an individual DHCP client, is also a 561 site-local matter. The choice between the two alternatives is likely 562 based on the security model that is being used with DNS updates. In 563 cases where a DHCP server is performing DNS updates on behalf of a 564 client, the DHCP server should be sure of the DNS name to use for the 565 client, and of the identity of the client. 567 Currently, it is difficult for DHCP servers to develop much 568 confidence in the identities of its clients, given the absence of 569 entity authentication from the DHCP protocol itself. There are many 570 ways for a DHCP server to develop a DNS name to use for a client, but 571 only in certain relatively unusual circumstances will the DHCP server 572 know for certain the identity of the client. If DHCP Authentication 573 [15] becomes widely deployed this may become more customary. 575 One example of a situation which offers some extra assurances is one 576 where the DHCP client is connected to a network through an MCNS cable 577 modem, and the CMTS (head-end) ensures that MAC address spoofing 578 simply does not occur. Another example of a configuration that might 579 be trusted is one where clients obtain network access via a network 580 access server using PPP. The NAS itself might be obtaining IP 581 addresses via DHCP, encoding a client identification into the DHCP 582 client-id option. In this case, the network access server as well as 583 the DHCP server might be operating within a trusted environment, in 584 which case the DHCP server could be configured to trust that the user 585 authentication and authorization procedure of the remote access 586 server was sufficient, and would therefore trust the client 587 identification encoded within the DHCP client-id. 589 It is critical to implement proper conflict resolution, and the 590 security considerations of conflict resolution apply [10]. 592 9. Acknowledgements 594 Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter 595 Ford, Olafur Gudmundsson, Edie Gunter, Andreas Gustafsson, David W. 596 Hankins, R. Barr Hibbs, Kim Kinnear, Stuart Kwan, Ted Lemon, Ed 597 Lewis, Michael Lewis, Josh Littlefield, Michael Patton, Pekka Savola, 598 Jyrki Soini, and Glenn Stump for their review and comments. 600 10. References 602 10.1. Normative References 604 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 605 Levels", BCP 14, RFC 2119, March 1997. 607 [2] Mockapetris, P., "Domain names - concepts and facilities", 608 STD 13, RFC 1034, November 1987. 610 [3] Mockapetris, P., "Domain names - implementation and 611 specification", STD 13, RFC 1035, November 1987. 613 [4] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 614 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 615 April 1997. 617 [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 618 March 1997. 620 [6] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host 621 table specification", RFC 952, October 1985. 623 [7] Braden, R., "Requirements for Internet Hosts - Application and 624 Support", STD 3, RFC 1123, October 1989. 626 [8] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. 627 Lear, "Address Allocation for Private Internets", BCP 5, 628 RFC 1918, February 1996. 630 [9] Lemon, T. and S. Cheshire, "Encoding Long Options in the 631 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 632 November 2002. 634 [10] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among 635 DHCP Clients (draft-ietf-dhc-ddns-resolution-*.txt)", 636 February 2006. 638 10.2. Informative References 640 [11] Marine, A., Reynolds, J., and G. Malkin, "FYI on Questions and 641 Answers - Answers to Commonly asked "New Internet User" 642 Questions", RFC 1594, March 1994. 644 [12] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 645 Extensions", RFC 2132, March 1997. 647 [13] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 648 August 1999. 650 [14] Wellington, B., "Secure Domain Name System (DNS) Dynamic 651 Update", RFC 3007, November 2000. 653 [15] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 654 RFC 3118, June 2001. 656 [16] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 657 August 1996. 659 [17] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes 660 (DNS NOTIFY)", RFC 1996, August 1996. 662 Authors' Addresses 664 Mark Stapp 665 Cisco Systems, Inc. 666 1414 Massachusetts Ave. 667 Boxborough, MA 01719 668 USA 670 Phone: 978.936.1535 671 Email: mjs@cisco.com 673 Bernie Volz 674 Cisco Systems, Inc. 675 1414 Massachusetts Ave. 676 Boxborough, MA 01719 677 USA 679 Phone: 978.936.0382 680 Email: volz@cisco.com 682 Yakov Rekhter 683 Juniper Networks 684 1194 North Mathilda Avenue 685 Sunnyvale, CA 94089 686 USA 688 Phone: 408.745.2000 689 Email: yakov@juniper.net 691 Intellectual Property Statement 693 The IETF takes no position regarding the validity or scope of any 694 Intellectual Property Rights or other rights that might be claimed to 695 pertain to the implementation or use of the technology described in 696 this document or the extent to which any license under such rights 697 might or might not be available; nor does it represent that it has 698 made any independent effort to identify any such rights. Information 699 on the procedures with respect to rights in RFC documents can be 700 found in BCP 78 and BCP 79. 702 Copies of IPR disclosures made to the IETF Secretariat and any 703 assurances of licenses to be made available, or the result of an 704 attempt made to obtain a general license or permission for the use of 705 such proprietary rights by implementers or users of this 706 specification can be obtained from the IETF on-line IPR repository at 707 http://www.ietf.org/ipr. 709 The IETF invites any interested party to bring to its attention any 710 copyrights, patents or patent applications, or other proprietary 711 rights that may cover technology that may be required to implement 712 this standard. Please address the information to the IETF at 713 ietf-ipr@ietf.org. 715 Disclaimer of Validity 717 This document and the information contained herein are provided on an 718 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 719 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 720 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 721 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 722 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 723 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 725 Copyright Statement 727 Copyright (C) The Internet Society (2006). This document is subject 728 to the rights, licenses and restrictions contained in BCP 78, and 729 except as set forth therein, the authors retain all their rights. 731 Acknowledgment 733 Funding for the RFC Editor function is currently provided by the 734 Internet Society.