idnits 2.17.1 draft-ietf-dhc-ddns-resolution-08.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 590. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 21, 2004) is 7157 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' -- 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? -- No information found for draft-ietf-dhc-3315id-for-v4- - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '9') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '10') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2845 (ref. '12') (Obsoleted by RFC 8945) Summary: 6 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 22, 2005 Cisco Systems, Inc. 5 September 21, 2004 7 Resolution of DNS Name Conflicts among DHCP Clients 8 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 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 22 Internet-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 March 22, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 DHCP provides a powerful mechanism for IP host configuration. 44 However, the configuration capability provided by DHCP does not 45 include updating DNS, and specifically updating the name to address 46 and address to name mappings maintained in the DNS. This document 47 describes techniques for the resolution of DNS name conflicts among 48 DHCP clients. 50 Table of Contents 52 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Issues with DNS Update in DHCP Environments . . . . . . . . . 3 55 3.1 Client Misconfiguration . . . . . . . . . . . . . . . . . 4 56 3.2 Multiple DHCP Servers . . . . . . . . . . . . . . . . . . 5 57 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 5 58 5. DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6. Procedures for performing DNS updates . . . . . . . . . . . . 6 60 6.1 Error Return Codes . . . . . . . . . . . . . . . . . . . . 6 61 6.2 Dual IPv4/IPv6 Client Considerations . . . . . . . . . . . 7 62 6.3 Adding A or AAAA RRs to DNS . . . . . . . . . . . . . . . 7 63 6.3.1 Initial DHCID RR Query . . . . . . . . . . . . . . . . 7 64 6.3.2 DNS UPDATE When Name Not in Use . . . . . . . . . . . 8 65 6.3.3 DNS UPDATE When Name in Use . . . . . . . . . . . . . 8 66 6.3.4 Name in Use by another Client . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . 10 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 74 9.2 Informative References . . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 76 Intellectual Property and Copyright Statements . . . . . . . . 14 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 2. Introduction 86 "The Client FQDN Option" [4] includes a description of the operation 87 of DHCPv4 [7] clients and servers that use the DHCPv4 client FQDN 88 option. And, "The DHCPv6 Client FQDN Option" [5] includes a 89 description of the operation of DHCPv6 [9] clients and servers that 90 use the DHCPv6 client FQDN option. Through the use of the client 91 FQDN option, DHCP clients and servers can negotiate the client's FQDN 92 and the allocation of responsibility for updating the DHCP client's A 93 or AAAA RR. This document identifies situations in which conflicts 94 in the use of FQDNs may arise among DHCP clients, and describes a 95 strategy for the use of the DHCID DNS resource record [2] in 96 resolving those conflicts. 98 In any case, whether a site permits all, some, or no DHCP servers and 99 clients to perform DNS updates (RFC 2136 [3], RFC 3007 [11]) into the 100 zones that it controls is entirely a matter of local administrative 101 policy. This document does not require any specific administrative 102 policy, and does not propose one. The range of possible policies is 103 very broad, from sites where only the DHCP servers have been given 104 credentials that the DNS servers will accept, to sites where each 105 individual DHCP client has been configured with credentials that 106 allow the client to modify its own domain name. Compliant 107 implementations MAY support some or all of these possibilities. 108 Furthermore, this specification applies only to DHCP client and 109 server processes: it does not apply to other processes that initiate 110 DNS updates. 112 3. Issues with DNS Update in DHCP Environments 114 There are two DNS update situations that require special 115 consideration in DHCP environments: cases where more than one DHCP 116 client has been configured with the same FQDN, and cases where more 117 than one DHCP server has been given authority to perform DNS updates 118 in a zone. In these cases, it is possible for DNS records to be 119 modified in inconsistent ways unless the updaters have a mechanism 120 that allows them to detect anomalous situations. If DNS updaters can 121 detect these situations, site administrators can configure the 122 updaters' behavior so that the site's policies can be enforced. We 123 use the term "Name Conflict" to refer to cases where more than one 124 DHCP client wishes to be associated with a single FQDN. This 125 specification describes a mechanism designed to allow updaters to 126 detect these situations, and suggests that DHCP implementations use 127 this mechanism by default. 129 3.1 Client Misconfiguration 131 At many (though not all) sites, administrators wish to maintain a 132 one-to-one relationship between active DHCP clients and domain names, 133 and to maintain consistency between a host's A and PTR RRs. Hosts 134 that are not represented in the DNS, or hosts which inadvertently 135 share an FQDN with another host may encounter inconsistent behavior 136 or may not be able to obtain access to network resources. Whether 137 each DHCP client is configured with a domain name by its 138 administrator or whether the DHCP server is configured to distribute 139 the clients' names, the consistency of the DNS data is entirely 140 dependent on the accuracy of the configuration procedure. Sites that 141 deploy Secure DNS [10] may configure credentials for each host and 142 its assigned name in a way that is more error-resistant, but this 143 level of pre-configuration is still rare in DHCP environments. 145 Consider an example in which two DHCP clients in the "org.nil" 146 network are both configured with the name "foo". The clients are 147 permitted to perform their own DNS updates. The first client, client 148 A, is configured via DHCP. It adds an A RR to "foo.org.nil", and its 149 DHCP server adds a PTR RR corresponding to its IP address lease. 150 When the second client, client B, boots, it is also configured via 151 DHCP, and it also begins to update "foo.org.nil". 153 At this point, the "org.nil" administrators may wish to establish 154 some policy about DHCP clients' DNS names. If the policy is that 155 each client that boots should replace any existing A RR that matches 156 its name, Client B can proceed, though Client A may encounter 157 problems. In this example, Client B replaces the A RR associated 158 with "foo.org.nil". Client A must have some way to recognize that 159 the RR associated with "foo.org.nil" now contains information for 160 Client B, so that it can avoid modifying the RR. When Client A's 161 lease expires, for example, it should not remove an RR that reflects 162 Client B's DHCP lease. 164 If the policy is that the first DHCP client with a given name should 165 be the only client associated with that name, Client B needs to be 166 able to determine that it is not the client associated with 167 "foo.org.nil". It could be that Client A booted first, and that 168 Client B should choose another name. Or it could be that B has 169 booted on a new subnet, and received a new lease. It must either 170 retain persistent state about the last lease it held (in addition to 171 its current lease) or it must have some other way to detect that it 172 was the last updater of "foo.org.nil" in order to implement the 173 site's policy. 175 3.2 Multiple DHCP Servers 177 At many sites, the difficulties with distributing DNS update 178 credentials to all of the DHCP clients lead to the desire for the 179 DHCP servers to perform A RR updates on behalf of their clients. If 180 a single DHCP server managed all of the DHCP clients at a site, it 181 could maintain some database of the DNS names that it was managing, 182 and check that database before initiating a DNS update for a client. 183 Such a database is necessarily proprietary, however, and that 184 approach does not work once more than one DHCP server is deployed. 186 Consider an example in which DHCP Client A boots, obtains a DHCP 187 lease from Server S1, presenting the hostname "foo" in a Client FQDN 188 option [4] in its DHCPREQUEST message. Server S1 updates its domain 189 name, "foo.org.nil", adding an A RR that matches Client A's lease. 190 The client then moves to another subnet, served by Server S2. When 191 Client A boots on the new subnet, Server S2 will issue it a new 192 lease, and will attempt to add an A RR matching the new lease to 193 "foo.org.nil". At this point, without some communication mechanism 194 which S2 can use to ask S1 (and every other DHCP server that updates 195 the zone) about the client, S2 has no way to know whether Client A is 196 currently associated with the domain name, or whether A is a 197 different client configured with the same hostname. If the servers 198 cannot distinguish between these situations, they cannot enforce the 199 site's naming policies. 201 4. Use of the DHCID RR 203 A solution to both of these problems is for the updater (a DHCP 204 client or DHCP server) to be able to determine which DHCP client has 205 been associated with a DNS name, in order to offer administrators the 206 opportunity to configure updater behavior. 208 For this purpose, a DHCID RR, specified in [2], is used to associate 209 client identification information with a DNS name and the A or PTR RR 210 associated with that name. When either a client or server adds an A 211 or PTR RR for a client, it also adds a DHCID RR that specifies a 212 unique client identity, based on data from the client's DHCPREQUEST 213 message. In this model, only one A RR is associated with a given DNS 214 name at a time. 216 By associating this ownership information with each DNS name, 217 cooperating DNS updaters may determine whether their client is 218 currently associated with a particular DNS name and implement the 219 appropriately configured administrative policy. In addition, DHCP 220 clients which currently have domain names may move from one DHCP 221 server to another without losing their DNS names. 223 The specific algorithms utilizing the DHCID RR to signal client 224 ownership are explained below. The algorithms only work in the case 225 where the updating entities all cooperate -- this approach is 226 advisory only and is not a substitute for DNS security, nor is it 227 replaced by DNS security. 229 5. DNS RR TTLs 231 RRs associated with DHCP clients may be more volatile than statically 232 configured RRs. DHCP clients and servers that perform dynamic 233 updates should attempt to specify resource record TTLs which reflect 234 this volatility, in order to minimize the possibility that answers to 235 DNS queries will return records that refer to DHCP lease bindings 236 that have expired. 238 The coupling among primary, secondary, and caching DNS servers is 239 'loose'; that is a fundamental part of the design of the DNS. This 240 looseness makes it impossible to prevent all possible situations in 241 which a resolver may return a record reflecting a DHCP lease binding 242 that has expired. In deployment, this rarely if ever represents a 243 significant problem. Most DHCP-managed hosts are rarely looked-up by 244 name in the DNS, and the deployment of IXFR (RFC 1995 [14]) and 245 NOTIFY (RFC 1996 [15]) can reduce the latency between updates and 246 their visibility at secondary servers. 248 We suggest these basic guidelines for implementers. In general, the 249 TTLs for RRs added as a result of DHCP lease activity SHOULD be less 250 than the initial lease time. The RR TTL on a DNS record added for a 251 DHCP lease SHOULD NOT exceed 1/3 of the lease time, and SHOULD be at 252 least 10 minutes. We recognize that individual administrators will 253 have varying requirements: DHCP servers and clients SHOULD allow 254 administrators to configure TTLs, either as an absolute time interval 255 or as a percentage of the lease time. 257 6. Procedures for performing DNS updates 259 6.1 Error Return Codes 261 Certain RCODEs defined in RFC 2136 [3] indicate that the destination 262 DNS server cannot perform an update: FORMERR, SERVFAIL, REFUSED, 263 NOTIMP. If one of these RCODEs is returned, the updater MUST 264 terminate its update attempt. Because these errors may indicate a 265 misconfiguration of the updater or of the DNS server, the updater MAY 266 attempt to signal to its administrator that an error has occurred, 267 e.g. through a log message. 269 6.2 Dual IPv4/IPv6 Client Considerations 271 At the time of publication of this document, a small minority of DHCP 272 clients support both IPv4 and IPv6. We anticipate, however, that a 273 transition will take place over a period of time, and more sites will 274 have dual-stack clients present. IPv6 clients will be represented by 275 AAAA RRs; IPv4 clients by A RRs. The administrators of mixed 276 deployments will likely wish to permit a single name to contain A and 277 AAAA RRs from the same client. 279 Sites that wish to permit a single name to contain both A and AAAA 280 RRs MUST make use of DHCPv4 clients and servers that support using 281 the DHCP Unique Identifier for DHCPv4 client identifiers, see 282 Node-Specific Client Identifiers for DHCPv4 [6]. Otherwise, a 283 dual-stack client that uses older-style DHCPv4 client identifiers 284 (see [7] and [8]) will only be able to have either its A or AAAA 285 record in DNS under a name because of the DHCID RR conflicts that 286 result. 288 6.3 Adding A or AAAA RRs to DNS 290 6.3.1 Initial DHCID RR Query 292 When a DHCP client or server intends to update an A or AAAA RR, it 293 performs a DNS query with QNAME of the target name and with QTYPE of 294 DHCID. 296 If the query returns NXDOMAIN, the updater can conclude that the name 297 is not in use and proceeds to Section 6.3.2. 299 If the query returns NOERROR but without an answer, the updater can 300 conclude that the target name is in use, but that no DHCID RR is 301 present. This indicates that some records have been configured by an 302 administrator. Whether the updater proceeds with an update is a 303 matter of local administrative policy. 305 If the DHCID rrset is returned, the updater uses the hash calculation 306 defined in the DHCID RR specification [4] to determine whether the 307 client associated with the name matches the current client's 308 identity. If so, the updater proceeds to Section 6.3.3. Otherwise 309 the updater must conclude that the client's desired name is in use by 310 another host and proceeds to Section 6.3.4. 312 If any other status is returned, the updater MUST NOT attempt an 313 update. 315 6.3.2 DNS UPDATE When Name Not in Use 317 The updater prepares a DNS UPDATE query that includes as a 318 prerequisite the assertion that the name does not exist. The update 319 section of the query attempts to add the new name and its IP address 320 mapping (an A or AAAA RR), and the DHCID RR with its unique 321 client-identity. 323 If the update operation succeeds, the A or AAAA RR update is now 324 complete (and a client updater is finished, while a server would then 325 proceed to perform a PTR RR update). 327 If the update returns YXDOMAIN, the updater can now conclude that the 328 intended name is in use and proceeds to Section 6.3.3. 330 6.3.3 DNS UPDATE When Name in Use 332 The updater next attempts to confirm that the DNS name is not being 333 used by some other host. The updater prepares a UPDATE query in 334 which the prerequisite is that the desired name has attached to it a 335 DHCID RR whose contents match the client identity. The update 336 section of the UPDATE query contains: 337 1. A delete of any existing A RRs on the name if this is an A update 338 or an AAAA update and the updater does not desire A records on 339 the name. 340 2. A delete of the existing AAAA RRs on the name if the updater does 341 not desire AAAA records on the name or this update is adding an 342 AAAA and the updater only desires a single address on the name. 343 3. An add of the A RR that matches the DHCP binding if this is an A 344 update. 345 4. An add of the AAAA RR that matches the DHCP binding if this is an 346 AAAA update. 348 If the update succeeds, the updater can conclude that the current 349 client was the last client associated with the domain name, and that 350 the name now contains the updated A or AAAA RR. The update is now 351 complete (and a client updater is finished, while a server would then 352 proceed to perform a PTR RR update). 354 If the update returns NXRRSET, the updater must conclude that the 355 client's desired name is in use by another host and proceeds to 356 Section 6.3.4. 358 6.3.4 Name in Use by another Client 360 At this juncture, the updater can decide (based on some 361 administrative configuration outside of the scope of this document) 362 whether to let the existing owner of the name keep that name, and to 363 (possibly) perform some name disambiguation operation on behalf of 364 the current client, or to replace the RRs on the name with RRs that 365 represent the current client. If the configured policy allows 366 replacement of existing records, the updater submits a query that 367 deletes all RRs for the name and adds the A or AAAA and DHCID RRs 368 that represent the address and client-identity of the new client. 370 DISCUSSION: 371 The updating entity may be configured to allow the existing DNS 372 records on the domain name to remain unchanged, and to perform 373 disambiguation on the name of the current client in order to 374 attempt to generate a similar but unique name for the current 375 client. In this case, once another candidate name has been 376 generated, the updater should restart the process of adding an A 377 RR as specified in this section. 379 6.4 Adding PTR RR Entries to DNS 381 The DHCP server submits a DNS query that deletes all of the PTR RRs 382 associated with the lease IP address, and adds a PTR RR whose data is 383 the client's (possibly disambiguated) host name. The server MAY also 384 add a DHCID RR as specified in Section 4, in which case it would 385 include a delete of all of the DHCID RRs associated with the lease IP 386 address, and adds a DHCID RR for the client. 388 6.5 Removing Entries from DNS 390 The most important consideration in removing DNS entries is be sure 391 that an entity removing a DNS entry is only removing an entry that it 392 added, or for which an administrator has explicitly assigned it 393 responsibility. 395 When a lease expires or a DHCP client issues a DHCPRELEASE [7] or 396 Release [9] request, the DHCP server SHOULD delete the PTR RR that 397 matches the DHCP binding, if one was successfully added. The 398 server's update query SHOULD assert that the name in the PTR record 399 matches the name of the client whose lease has expired or been 400 released and should delete all RRs for the name. 402 The entity chosen to handle the A or AAAA record for this client 403 (either the client or the server) SHOULD delete the A or AAAA record 404 that was added when the lease was made to the client. However, the 405 updater should only remove the DHCID RR if there are no A or AAAA RRs 406 for the client. 408 In order to perform this A or AAAA RR delete, the updater prepares an 409 UPDATE query that contains a prerequisite that asserts that the DHCID 410 RR exists whose data is the client identity described in Section 4 411 and contains an update section that deletes the client's specific A 412 or AAAA RR. 414 If the query succeeds, the updater prepares a second UPDATE query 415 that contains three prerequisites and deletes all RRs for the name. 416 The first prerequisite asserts that the DHCID RR exists whose data is 417 the client identity described in Section 4. The second prerequisite 418 asserts that there are no A RRs. The third prerequisite asserts that 419 there are no AAAA RRs. 421 If either query fails, the updater MUST NOT delete the DNS name. It 422 may be that the client whose lease has expired has moved to another 423 network and obtained a lease from a different server, which has 424 caused the client's A or AAAA RR to be replaced. It may also be that 425 some other client has been configured with a name that matches the 426 name of the DHCP client, and the policy was that the last client to 427 specify the name would get the name. In these cases, the DHCID RR 428 will no longer match the updater's notion of the client-identity of 429 the host pointed to by the DNS name. 431 6.6 Updating Other RRs 433 The procedures described in this document only cover updates to the 434 A, AAAA, PTR, and DHCID RRs. Updating other types of RRs is outside 435 the scope of this document. 437 7. Security Considerations 439 Unauthenticated updates to the DNS can lead to tremendous confusion, 440 through malicious attack or through inadvertent misconfiguration. 441 Administrators should be wary of permitting unsecured DNS updates to 442 zones that are exposed to the global Internet. Both DHCP clients and 443 servers SHOULD use some form of update request authentication (e.g., 444 TSIG [12]) when performing DNS updates. 446 Whether a DHCP client may be responsible for updating an FQDN to IP 447 address mapping, or whether this is the responsibility of the DHCP 448 server is a site-local matter. The choice between the two 449 alternatives may be based on the security model that is used with the 450 Dynamic DNS Update protocol (e.g., only a client may have sufficient 451 credentials to perform updates to the FQDN to IP address mapping for 452 its FQDN). 454 Whether a DHCP server is always responsible for updating the FQDN to 455 IP address mapping (in addition to updating the IP to FQDN mapping), 456 regardless of the wishes of an individual DHCP client, is also a 457 site-local matter. The choice between the two alternatives may be 458 based on the security model that is being used with dynamic DNS 459 updates. In cases where a DHCP server is performing DNS updates on 460 behalf of a client, the DHCP server should be sure of the DNS name to 461 use for the client, and of the identity of the client. 463 Currently, it is difficult for DHCP servers to develop much 464 confidence in the identities of their clients, given the absence of 465 entity authentication from the DHCP protocol itself. There are many 466 ways for a DHCP server to develop a DNS name to use for a client, but 467 only in certain relatively rare circumstances will the DHCP server 468 know for certain the identity of the client. If DHCP Authentication 469 [13] becomes widely deployed this may become more customary. 471 One example of a situation that offers some extra assurances is one 472 where the DHCP client is connected to a network through an MCNS cable 473 modem, and the CMTS (head-end) of the cable modem ensures that MAC 474 address spoofing simply does not occur. Another example of a 475 configuration that might be trusted is one where clients obtain 476 network access via a network access server using PPP. The NAS itself 477 might be obtaining IP addresses via DHCP, encoding a client 478 identification into the DHCP client-id option. In this case, the 479 network access server as well as the DHCP server might be operating 480 within a trusted environment, in which case the DHCP server could be 481 configured to trust that the user authentication and authorization 482 processing of the remote access server was sufficient, and would 483 therefore trust the client identification encoded within the DHCP 484 client-id. 486 8. Acknowledgements 488 Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter 489 Ford, Olafur Gudmundsson, Edie Gunter, Andreas Gustafsson, R. Barr 490 Hibbs, Kim Kinnear, Stuart Kwan, Ted Lemon, Ed Lewis, Michael Lewis, 491 Josh Littlefield, Michael Patton, and Glenn Stump for their review 492 and comments. 494 9. References 496 9.1 Normative References 498 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 499 Levels", BCP 14, RFC 2119, March 1997. 501 [2] Stapp, M., Gustafsson, A. and T. Lemon, "A DNS RR for Encoding 502 DHCP Information (draft-ietf-dnsext-dhcid-rr-*)", July 2004. 504 [3] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 505 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 506 1997. 508 9.2 Informative References 510 [4] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option 511 (draft-ietf-dhc-fqdn-option-*.txt)", July 2004. 513 [5] Volz, B., "The DHCPv6 Client FQDN Option 514 (draft-ietf-dhc-dhcpv6-fqdn-*.txt)", September 2004. 516 [6] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers 517 for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*txt)", July 2004. 519 [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 520 March 1997. 522 [8] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 523 Extensions", RFC 2132, March 1997. 525 [9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 526 Carney, "Dynamic Host Configuration Protocol for IPv6 527 (DHCPv6)", RFC 3315, July 2003. 529 [10] Eastlake, D., "Domain Name System Security Extensions", RFC 530 2535, March 1999. 532 [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic 533 Update", RFC 3007, November 2000. 535 [12] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 536 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 537 2845, May 2000. 539 [13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 540 RFC 3118, June 2001. 542 [14] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 543 1996. 545 [15] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes 546 (DNS NOTIFY)", RFC 1996, August 1996. 548 Authors' Addresses 550 Mark Stapp 551 Cisco Systems, Inc. 552 1414 Massachusetts Ave. 553 Boxborough, MA 01719 554 USA 556 Phone: 978.936.1535 557 EMail: mjs@cisco.com 559 Bernie Volz 560 Cisco Systems, Inc. 561 1414 Massachusetts Ave. 562 Boxborough, MA 01719 563 USA 565 Phone: 978.936.0382 566 EMail: volz@cisco.com 568 Intellectual Property Statement 570 The IETF takes no position regarding the validity or scope of any 571 Intellectual Property Rights or other rights that might be claimed to 572 pertain to the implementation or use of the technology described in 573 this document or the extent to which any license under such rights 574 might or might not be available; nor does it represent that it has 575 made any independent effort to identify any such rights. Information 576 on the procedures with respect to rights in RFC documents can be 577 found in BCP 78 and BCP 79. 579 Copies of IPR disclosures made to the IETF Secretariat and any 580 assurances of licenses to be made available, or the result of an 581 attempt made to obtain a general license or permission for the use of 582 such proprietary rights by implementers or users of this 583 specification can be obtained from the IETF on-line IPR repository at 584 http://www.ietf.org/ipr. 586 The IETF invites any interested party to bring to its attention any 587 copyrights, patents or patent applications, or other proprietary 588 rights that may cover technology that may be required to implement 589 this standard. Please address the information to the IETF at 590 ietf-ipr@ietf.org. 592 Disclaimer of Validity 594 This document and the information contained herein are provided on an 595 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 596 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 597 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 598 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 599 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 600 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 602 Copyright Statement 604 Copyright (C) The Internet Society (2004). This document is subject 605 to the rights, licenses and restrictions contained in BCP 78, and 606 except as set forth therein, the authors retain all their rights. 608 Acknowledgment 610 Funding for the RFC Editor function is currently provided by the 611 Internet Society.