idnits 2.17.1 draft-ietf-dhc-ddns-resolution-10.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 611. ** 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 : ---------------------------------------------------------------------------- ** 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.) 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 (September 2, 2005) is 6810 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) -- No information found for draft-ietf-dnsext-dhcid-rr- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '6') (Obsoleted by RFC 8415) -- No information found for draft-ietf-dhc-fqdn-option- - is the name correct? -- No information found for draft-ietf-dhc-dhcpv6-fqdn- - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '11') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- No information found for draft-ietf-dhc-3315id-for-v4- - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2845 (ref. '16') (Obsoleted by RFC 8945) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration M. Stapp 3 Internet-Draft B. Volz 4 Expires: March 6, 2006 Cisco Systems, Inc. 5 September 2, 2005 7 Resolution of FQDN Conflicts among DHCP Clients 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 This Internet-Draft will expire on March 6, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 DHCP provides a mechanism for host configuration that includes 42 dynamic assignment of IP addresses and fully qualified domain names. 43 To maintain accurate name to IP address and IP address to name 44 mappings in the DNS, these dynamically assigned addresses and fully 45 qualified domain names require updates to the DNS. This document 46 identifies situations in which conflicts in the use of fully 47 qualified domain names may arise among DHCP clients and servers, and 48 describes a strategy for the use of the DHCID DNS resource record in 49 resolving those conflicts. 51 Table of Contents 53 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Issues with DNS Update in DHCP Environments . . . . . . . . . 3 56 3.1. Client Misconfiguration . . . . . . . . . . . . . . . . . 4 57 3.2. Multiple DHCP Servers . . . . . . . . . . . . . . . . . . 5 58 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 5 59 5. DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 6. Procedures for Performing DNS Updates . . . . . . . . . . . . 7 61 6.1. Error Return Codes . . . . . . . . . . . . . . . . . . . . 7 62 6.2. Dual IPv4/IPv6 Client Considerations . . . . . . . . . . . 7 63 6.3. Adding A and/or AAAA RRs to DNS . . . . . . . . . . . . . 7 64 6.3.1. Initial DHCID RR Query . . . . . . . . . . . . . . . . 8 65 6.3.2. DNS UPDATE When FQDN in Use . . . . . . . . . . . . . 8 66 6.3.3. FQDN in Use by another Client . . . . . . . . . . . . 9 67 6.4. Adding PTR RR Entries to DNS . . . . . . . . . . . . . . . 9 68 6.5. Removing Entries from DNS . . . . . . . . . . . . . . . . 9 69 6.6. Updating Other RRs . . . . . . . . . . . . . . . . . . . . 10 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 76 Intellectual Property and Copyright Statements . . . . . . . . . . 15 78 1. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [1]. 84 This document assumes familiarity with DNS terminology defined in RFC 85 1035 [4] and DHCP terminology defined in RFC 2131 [5] and RFC 3315 86 [6]. 88 FQDN, or Fully Qualified Domain Name, is the full name of a system, 89 rather than just its hostname. For example, "venera" is a hostname 90 and "venera.isi.edu" is an FQDN. See RFC 1983 [7]. 92 DOCSIS, or Data-Over-Cable Service Interface Specifications, is 93 defined by CableLabs (www.cablelabs.com). 95 2. Introduction 97 "The Client FQDN Option" [8] includes a description of the operation 98 of DHCPv4 [5] clients and servers that use the DHCPv4 client FQDN 99 option. And, "The DHCPv6 Client FQDN Option" [9] includes a 100 description of the operation of DHCPv6 [6] clients and servers that 101 use the DHCPv6 client FQDN option. Through the use of the client 102 FQDN option, DHCP clients and servers can negotiate the client's FQDN 103 and the allocation of responsibility for updating the DHCP client's A 104 and/or AAAA RRs. This document identifies situations in which 105 conflicts in the use of FQDNs may arise among DHCP clients and 106 servers, and describes a strategy for the use of the DHCID DNS 107 resource record [2] in resolving those conflicts. 109 In any case, whether a site permits all, some, or no DHCP servers and 110 clients to perform DNS updates (RFC 2136 [3], RFC 3007 [10]) into the 111 zones that it controls is entirely a matter of local administrative 112 policy. This document does not require any specific administrative 113 policy, and does not propose one. The range of possible policies is 114 very broad, from sites where only the DHCP servers have been given 115 credentials that the DNS servers will accept, to sites where each 116 individual DHCP client has been configured with credentials that 117 allow the client to modify its own FQDN. Compliant implementations 118 MAY support some or all of these possibilities. Furthermore, this 119 specification applies only to DHCP client and server processes; it 120 does not apply to other processes that initiate DNS updates. 122 3. Issues with DNS Update in DHCP Environments 123 There are two DNS update situations that require special 124 consideration in DHCP environments: cases where more than one DHCP 125 client has been configured with the same FQDN and cases where more 126 than one DHCP server has been given authority to perform DNS updates 127 in a zone. In these cases, it is possible for DNS records to be 128 modified in inconsistent ways unless the updaters have a mechanism 129 that allows them to detect anomalous situations. If DNS updaters can 130 detect these situations, site administrators can configure the 131 updaters' behavior so that the site's policies can be enforced. This 132 specification describes a mechanism designed to allow updaters to 133 detect these situations, and suggests that DHCP implementations use 134 this mechanism by default. 136 3.1. Client Misconfiguration 138 Administrators may wish to maintain a one-to-one relationship between 139 active DHCP clients and FQDNs, and to maintain consistency between a 140 client's A, AAAA, and PTR RRs. Clients that are not represented in 141 the DNS, or clients that inadvertently share an FQDN with another 142 client may encounter inconsistent behavior or may not be able to 143 obtain access to network resources. Whether each DHCP client is 144 configured with a FQDN by its administrator or whether the DHCP 145 server is configured to distribute the clients' FQDN, the consistency 146 of the DNS data is entirely dependent on the accuracy of the 147 configuration procedure. Sites that deploy Secure DNS [11] may 148 configure credentials for each client and its assigned FQDN in a way 149 that is more error-resistant, as both the FQDN and credentials must 150 match. 152 Consider an example in which two DHCP clients in the "org.nil" 153 network are both configured with the hostname "foo". The clients are 154 permitted to perform their own DNS updates. The first client, client 155 A, is configured via DHCP. It adds an A RR to "foo.org.nil", and its 156 DHCP server adds a PTR RR corresponding to its assigned IP address. 157 When the second client, client B, boots, it is also configured via 158 DHCP, and it also begins to update "foo.org.nil". 160 At this point, the "org.nil" administrators may wish to establish 161 some policy about DHCP clients' FQDNs. If the policy is that each 162 client that boots should replace any existing A RR that matches its 163 FQDN, Client B can proceed, though Client A may encounter problems. 164 In this example, Client B replaces the A RR associated with 165 "foo.org.nil". Client A must have some way to recognize that the RR 166 associated with "foo.org.nil" now contains information for Client B, 167 so that it can avoid modifying the RR. When Client A's assigned IP 168 address expires, for example, it should not remove a RR that reflects 169 Client B's DHCP assigned IP address. 171 If the policy is that the first DHCP client with a given FQDN should 172 be the only client associated with that FQDN, Client B needs to be 173 able to determine if it is not the client associated with 174 "foo.org.nil". It could be that Client A booted first, and that 175 Client B should choose another FQDN. Or it could be that B has 176 booted on a new subnet, and received a new IP address assignment, in 177 which case B should update the DNS with its new IP address. It must 178 either retain persistent state about the last IP address it was 179 assigned (in addition to its current IP address) or it must have some 180 other way to detect that it was the last updater of "foo.org.nil" in 181 order to implement the site's policy. 183 3.2. Multiple DHCP Servers 185 It is possible to arrange for DHCP servers to perform A and/or AAAA 186 RR updates on behalf of their clients. If a single DHCP server 187 manages all of the DHCP clients at a site, it can maintain a database 188 of the FQDNs in use, and can check that database before assigning a 189 FQDN to a client. Such a database is necessarily proprietary, 190 however, and the approach does not work once more than one DHCP 191 server is deployed. 193 When multiple DHCP servers are deployed, the servers require a way to 194 coordinate the identities of DHCP clients. Consider an example in 195 which DHCP Client A boots, obtains an IP address from Server S1, 196 presenting the hostname "foo" in a Client FQDN option [8] in its 197 DHCPREQUEST message. Server S1 updates the FQDN "foo.org.nil", 198 adding an A RR containing the IP address assigned to A. The client 199 then moves to another subnet, served by Server S2. When Client A 200 boots on the new subnet, Server S2 will assign it a new IP address, 201 and will attempt to add an A RR containing the newly assigned IP 202 address to the FQDN "foo.org.nil". At this point, without some 203 communication mechanism which S2 can use to ask S1 (and every other 204 DHCP server that updates the zone) about the client, S2 has no way to 205 know whether Client A is currently associated with the FQDN, or 206 whether A is a different client configured with the same FQDN. If 207 the servers cannot distinguish between these situations, they cannot 208 enforce the site's naming policies. 210 4. Use of the DHCID RR 212 A solution to both of these problems is for the updater (a DHCP 213 client or DHCP server) to be able to determine which DHCP client has 214 been associated with a FQDN, in order to offer administrators the 215 opportunity to configure updater behavior. 217 For this purpose, a DHCID RR, specified in [2], is used to associate 218 client identification information with a FQDN and the A, AAAA, and 219 PTR RRs associated with that FQDN. When either a client or server 220 adds A, AAAA, or PTR RRs for a client, it also adds a DHCID RR that 221 specifies a unique client identity, based on data from the client's 222 DHCPREQUEST message. In this model, only one client is associated 223 with a given FQDN at a time. 225 By associating this ownership information with each FQDN, cooperating 226 DNS updaters may determine whether their client is currently 227 associated with a particular FQDN and implement the appropriately 228 configured administrative policy. In addition, DHCP clients which 229 currently have FQDNs may move from one DHCP server to another without 230 losing their FQDNs. 232 The specific algorithm utilizing the DHCID RR to signal client 233 ownership is explained below. The algorithm only works in the case 234 where the updating entities all cooperate -- this approach is 235 advisory only and is not a substitute for DNS security, nor is it 236 replaced by DNS security. 238 5. DNS RR TTLs 240 RRs associated with DHCP clients may be more volatile than statically 241 configured RRs. DHCP clients and servers that perform dynamic 242 updates should attempt to specify resource record TTLs which reflect 243 this volatility, in order to minimize the possibility that answers to 244 DNS queries will return records that refer to DHCP IP address 245 assignments that have expired or been released. 247 The coupling among primary, secondary, and caching DNS servers is 248 'loose'; that is a fundamental part of the design of the DNS. This 249 looseness makes it impossible to prevent all possible situations in 250 which a resolver may return a record reflecting a DHCP assigned IP 251 address that has expired or been released. In deployment, this 252 rarely, if ever, represents a significant problem. Most DHCP-managed 253 clients are infrequently looked-up by name in the DNS, and the 254 deployment of IXFR (RFC 1995 [12]) and NOTIFY (RFC 1996 [13]) can 255 reduce the latency between updates and their visibility at secondary 256 servers. 258 We suggest these basic guidelines for implementers. In general, the 259 TTLs for RRs added as a result of DHCP IP address assignment activity 260 SHOULD be less than the initial lease time or lifetime. The RR TTL 261 on a DNS record added SHOULD NOT exceed 1/3 of the lease time or 262 lifetime, and SHOULD be at least 10 minutes. We recognize that 263 individual administrators will have varying requirements: DHCP 264 servers and clients SHOULD allow administrators to configure TTLs and 265 upper and lower bounds on the TTL values, either as an absolute time 266 interval or as a percentage of the lease time or lifetime. 268 While clients and servers MAY update the TTL of the records as the 269 lease or lifetime is about to expire, there is no requirement that 270 they do so as this puts additional load on the DNS system with likely 271 little benefit. 273 6. Procedures for Performing DNS Updates 275 6.1. Error Return Codes 277 Certain RCODEs defined in RFC 2136 [3] indicate that the destination 278 DNS server cannot perform an update: FORMERR, SERVFAIL, REFUSED, 279 NOTIMP. If one of these RCODEs is returned, the updater MUST 280 terminate its update attempt. Because these errors may indicate a 281 misconfiguration of the updater or of the DNS server, the updater MAY 282 attempt to signal to its administrator that an error has occurred, 283 e.g. through a log message. 285 6.2. Dual IPv4/IPv6 Client Considerations 287 At the time of publication of this document, a small minority of DHCP 288 clients support both IPv4 and IPv6. We anticipate, however, that a 289 transition will take place over a period of time, and more sites will 290 have dual-stack clients present. IPv6 clients require updates of 291 AAAA RRs; IPv4 client require updates of A RRs. The administrators 292 of mixed deployments will likely wish to permit a single FQDN to 293 contain A and AAAA RRs from the same client. 295 Sites that wish to permit a single FQDN to contain both A and AAAA 296 RRs MUST make use of DHCPv4 clients and servers that support using 297 the DHCP Unique Identifier (DUID) for DHCPv4 client identifiers such 298 that this DUID is used in computing the RDATA of the DHCID RR by both 299 DHCPv4 and DHCPv6 for the client, see Node-Specific Client 300 Identifiers for DHCPv4 [14]. Otherwise, a dual-stack client that 301 uses older-style DHCPv4 client identifiers (see [5] and [15]) will 302 only be able to have either its A or AAAA records in DNS under a 303 single FQDN because of the DHCID RR conflicts that result. 305 6.3. Adding A and/or AAAA RRs to DNS 307 When a DHCP client or server intends to update A and/or AAAA RRs, it 308 starts with the update query in Section 6.3.1. 310 As the update sequence below can result in loops, implementers SHOULD 311 limit the total number of attempts for a single transaction. 313 6.3.1. Initial DHCID RR Query 315 The updater prepares a DNS UPDATE query that includes as a 316 prerequisite the assertion that the FQDN does not exist. The update 317 section of the query attempts to add the new FQDN and its IP address 318 mapping (A and/or AAAA RRs) and the DHCID RR with its unique client 319 identity. 321 If the update operation succeeds, the A and/or AAAA RR update is now 322 complete (and a client updater is finished, while a server would then 323 proceed to perform a PTR RR update). 325 If the update returns YXDOMAIN, the updater can now conclude that the 326 intended FQDN is in use and proceeds to Section 6.3.2. 328 If any other status is returned, the updater SHOULD NOT attempt an 329 update (see Section 6.1). 331 6.3.2. DNS UPDATE When FQDN in Use 333 The updater next attempts to confirm that the FQDN is not being used 334 by some other client by preparing an UPDATE query in which there are 335 two prerequisites. The first prerequisite is that the FQDN exists. 336 The second is that the desired FQDN has attached to it a DHCID RR 337 whose contents match the client identity. The update section of the 338 UPDATE query contains: 339 1. A delete of any existing A RRs on the FQDN if this is an A update 340 or an AAAA update and the updater does not desire A records on 341 the FQDN. 342 2. A delete of the existing AAAA RRs on the FQDN if the updater does 343 not desire AAAA records on the FQDN or this update is adding an 344 AAAA and the updater only desires a single IP address on the 345 FQDN. 346 3. An add of the A RR that matches the DHCP binding if this is an A 347 update. 348 4. Adds of the AAAA RRs that match the DHCP bindings if this is an 349 AAAA update. 351 If the update succeeds, the updater can conclude that the current 352 client was the last client associated with the FQDN, and that the 353 FQDN now contains the updated A and/or AAAA RRs. The update is now 354 complete (and a client updater is finished, while a server would then 355 proceed to perform a PTR RR update). 357 If the update returns NXDOMAIN, the FQDN is no longer in use and the 358 updater proceeds back to Section 6.3.1. 360 If the update returns NXRRSET, there are two possibilities - there 361 are no DHCID RRs for the FQDN or the DHCID RR does not match. In 362 either case, the updater proceeds to Section 6.3.3. 364 6.3.3. FQDN in Use by another Client 366 As the FQDN appears to be in use by another client or is not 367 associated with any client, the updater can decide (based on some 368 administrative configuration outside of the scope of this document) 369 whether to let the existing owner of the FQDN keep that FQDN, and to 370 (possibly) perform some FQDN disambiguation operation on behalf of 371 the current client, or to replace the RRs on the FQDN with RRs that 372 represent the current client. If the configured policy allows 373 replacement of existing records either if another DHCID RR is present 374 or no DHCID RR is present, the updater submits a query that deletes 375 all RRs for the FQDN (with a prerequisite that a DHCID RR exists or 376 does not exist) and adds the A and/or AAAA and DHCID RRs that 377 represent the IP address and client identity of the new client. 379 Techniques that may be considered to disambiguate FQDNs include 380 adding some suffix or prefix to the hostname portion of the FQDN or 381 randomly generating a hostname. 383 DISCUSSION: 384 The updating entity may be configured to allow the existing DNS 385 records on the FQDN to remain unchanged, and to perform 386 disambiguation on the FQDN of the current client in order to 387 attempt to generate a similar but unique FQDN for the current 388 client. In this case, once another candidate FQDN has been 389 generated, the updater should restart the process of adding A 390 and/or AAAA RRs as specified in this section. 392 6.4. Adding PTR RR Entries to DNS 394 The DHCP server submits a DNS query that deletes all of the PTR RRs 395 associated with the client's assigned IP address, and adds a PTR RR 396 whose data is the client's (possibly disambiguated) FQDN. The server 397 MAY also add a DHCID RR as specified in Section 4, in which case it 398 would include a delete of all of the DHCID RRs associated with the 399 client's assigned IP address, and adds a DHCID RR for the client. 401 There is no need to validate the DHCID RR for PTR updates as the DHCP 402 server (or servers) only assigns an address to a single client at a 403 time. 405 6.5. Removing Entries from DNS 407 The most important consideration in removing DNS entries is be sure 408 that an entity removing a DNS entry is only removing an entry that it 409 added, or for which an administrator has explicitly assigned it 410 responsibility. 412 When an address' lease time or valid lifetime expires or a DHCP 413 client issues a DHCPRELEASE [5] or Release [6] request, the DHCP 414 server SHOULD delete the PTR RR that matches the DHCP binding, if one 415 was successfully added. The server's update query SHOULD assert that 416 the domain name (PTRDNAME field) in the PTR record matches the FQDN 417 of the client whose address has expired or been released and should 418 delete all RRs for the FQDN. 420 The entity chosen to handle the A or AAAA records for this client 421 (either the client or the server) SHOULD delete the A or AAAA records 422 that was added when the address was assigned to the client. However, 423 the updater should only remove the DHCID RR if there are no A or AAAA 424 RRs remaining for the client. 426 In order to perform this A or AAAA RR delete, the updater prepares an 427 UPDATE query that contains a prerequisite that asserts that the DHCID 428 RR exists whose data is the client identity described in Section 4 429 and contains an update section that deletes the client's specific A 430 or AAAA RR. 432 If the query succeeds, the updater prepares a second UPDATE query 433 that contains three prerequisites and contains an update section that 434 deletes all RRs for the FQDN. The first prerequisite asserts that 435 the DHCID RR exists whose data is the client identity described in 436 Section 4. The second prerequisite asserts that there are no A RRs. 437 The third prerequisite asserts that there are no AAAA RRs. 439 If either query fails, the updater MUST NOT delete the FQDN. It may 440 be that the client whose address has expired has moved to another 441 network and obtained an address from a different server, which has 442 caused the client's A or AAAA RR to be replaced. It may also be that 443 some other client has been configured with a FQDN that matches the 444 FQDN of the DHCP client, and the policy was that the last client to 445 specify the FQDN would get the FQDN. In these cases, the DHCID RR 446 will no longer match the updater's notion of the client identity of 447 the client pointed to by the FQDN. 449 6.6. Updating Other RRs 451 The procedures described in this document only cover updates to the 452 A, AAAA, PTR, and DHCID RRs. Updating other types of RRs is outside 453 the scope of this document. 455 7. Security Considerations 457 Administrators should be wary of permitting unsecured DNS updates to 458 zones, where or not they are exposed to the global Internet. Both 459 DHCP clients and servers SHOULD use some form of update request 460 authentication (e.g., TSIG [16]) when performing DNS updates. 462 Whether a DHCP client may be responsible for updating an FQDN to IP 463 address mapping, or whether this is the responsibility of the DHCP 464 server is a site-local matter. The choice between the two 465 alternatives may be based on the security model that is used with the 466 Dynamic DNS Update protocol (e.g., only a client may have sufficient 467 credentials to perform updates to the FQDN to IP address mapping for 468 its FQDN). 470 Whether a DHCP server is always responsible for updating the FQDN to 471 IP address mapping (in addition to updating the IP to FQDN mapping), 472 regardless of the wishes of an individual DHCP client, is also a 473 site-local matter. The choice between the two alternatives may be 474 based on the security model that is being used with dynamic DNS 475 updates. In cases where a DHCP server is performing DNS updates on 476 behalf of a client, the DHCP server should be sure of the FQDN to use 477 for the client, and of the identity of the client. 479 Currently, it is difficult for DHCP servers to develop much 480 confidence in the identities of their clients, given the absence of 481 entity authentication from the DHCP protocol itself. There are many 482 ways for a DHCP server to develop a FQDN to use for a client, but 483 only in certain relatively rare circumstances will the DHCP server 484 know for certain the identity of the client. If DHCP Authentication 485 [17] becomes widely deployed this may become more customary. 487 One example of a situation that offers some extra assurances is when 488 the DHCP client is connected to a network through a DOCSIS cable 489 modem, and the Cable Modem Termination System (head-end) of the cable 490 modem ensures that MAC address spoofing simply does not occur. 491 Another example of a configuration that might be trusted is when 492 clients obtain network access via a network access server using PPP. 493 The Network Access Server (NAS) itself might be obtaining IP 494 addresses via DHCP, encoding client identification into the DHCP 495 client-id option. In this case, the NAS as well as the DHCP server 496 might be operating within a trusted environment, in which case the 497 DHCP server could be configured to trust that the user authentication 498 and authorization processing of the NAS was sufficient, and would 499 therefore trust the client identification encoded within the DHCP 500 client-id. 502 8. Acknowledgements 504 Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter 505 Ford, Olafur Gudmundsson, Edie Gunter, Andreas Gustafsson, David W. 506 Hankins, R. Barr Hibbs, Kim Kinnear, Stuart Kwan, Ted Lemon, Ed 507 Lewis, Michael Lewis, Josh Littlefield, Michael Patton, and Glenn 508 Stump for their review and comments. 510 9. References 512 9.1. Normative References 514 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 515 Levels", BCP 14, RFC 2119, March 1997. 517 [2] Stapp, M., Gustafsson, A., and T. Lemon, "A DNS RR for Encoding 518 DHCP Information (draft-ietf-dnsext-dhcid-rr-*)", February 2005. 520 [3] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 521 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 522 April 1997. 524 9.2. Informative References 526 [4] Mockapetris, P., "Domain names - implementation and 527 specification", STD 13, RFC 1035, November 1987. 529 [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 530 March 1997. 532 [6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 533 Carney, "Dynamic Host Configuration Protocol for IPv6 534 (DHCPv6)", RFC 3315, July 2003. 536 [7] Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996. 538 [8] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option 539 (draft-ietf-dhc-fqdn-option-*.txt)", February 2005. 541 [9] Volz, B., "The DHCPv6 Client FQDN Option 542 (draft-ietf-dhc-dhcpv6-fqdn-*.txt)", February 2005. 544 [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic 545 Update", RFC 3007, November 2000. 547 [11] Eastlake, D., "Domain Name System Security Extensions", 548 RFC 2535, March 1999. 550 [12] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 551 August 1996. 553 [13] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes 554 (DNS NOTIFY)", RFC 1996, August 1996. 556 [14] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers 557 for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*txt)", June 2005. 559 [15] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 560 Extensions", RFC 2132, March 1997. 562 [16] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, 563 "Secret Key Transaction Authentication for DNS (TSIG)", 564 RFC 2845, May 2000. 566 [17] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 567 RFC 3118, June 2001. 569 Authors' Addresses 571 Mark Stapp 572 Cisco Systems, Inc. 573 1414 Massachusetts Ave. 574 Boxborough, MA 01719 575 USA 577 Phone: 978.936.1535 578 Email: mjs@cisco.com 580 Bernie Volz 581 Cisco Systems, Inc. 582 1414 Massachusetts Ave. 583 Boxborough, MA 01719 584 USA 586 Phone: 978.936.0382 587 Email: volz@cisco.com 589 Intellectual Property Statement 591 The IETF takes no position regarding the validity or scope of any 592 Intellectual Property Rights or other rights that might be claimed to 593 pertain to the implementation or use of the technology described in 594 this document or the extent to which any license under such rights 595 might or might not be available; nor does it represent that it has 596 made any independent effort to identify any such rights. Information 597 on the procedures with respect to rights in RFC documents can be 598 found in BCP 78 and BCP 79. 600 Copies of IPR disclosures made to the IETF Secretariat and any 601 assurances of licenses to be made available, or the result of an 602 attempt made to obtain a general license or permission for the use of 603 such proprietary rights by implementers or users of this 604 specification can be obtained from the IETF on-line IPR repository at 605 http://www.ietf.org/ipr. 607 The IETF invites any interested party to bring to its attention any 608 copyrights, patents or patent applications, or other proprietary 609 rights that may cover technology that may be required to implement 610 this standard. Please address the information to the IETF at 611 ietf-ipr@ietf.org. 613 Disclaimer of Validity 615 This document and the information contained herein are provided on an 616 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 617 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 618 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 619 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 620 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 621 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 623 Copyright Statement 625 Copyright (C) The Internet Society (2005). This document is subject 626 to the rights, licenses and restrictions contained in BCP 78, and 627 except as set forth therein, the authors retain all their rights. 629 Acknowledgment 631 Funding for the RFC Editor function is currently provided by the 632 Internet Society.