idnits 2.17.1 draft-ietf-dhc-ddns-resolution-09.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 648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 625. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 632. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 638. ** 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 (June 28, 2005) is 6877 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. '10') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '11') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2845 (ref. '13') (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: December 30, 2005 Cisco Systems, Inc. 5 June 28, 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 December 30, 2005. 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 Not in Use . . . . . . . . . . . 8 66 6.3.3 DNS UPDATE When FQDN in Use . . . . . . . . . . . . . 8 67 6.3.4 FQDN in Use by another Client . . . . . . . . . . . . 9 68 6.4 Adding PTR RR Entries to DNS . . . . . . . . . . . . . . . 10 69 6.5 Removing Entries from DNS . . . . . . . . . . . . . . . . 10 70 6.6 Updating Other RRs . . . . . . . . . . . . . . . . . . . . 11 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 9.1 Normative References . . . . . . . . . . . . . . . . . . . 12 75 9.2 Informative References . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 77 Intellectual Property and Copyright Statements . . . . . . . . 15 79 1. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [1]. 85 FQDN, or Fully Qualified Domain Name, is the full name of a system, 86 rather than just its hostname. For example, "venera" is a hostname 87 and "venera.isi.edu" is an FQDN. See [7]. 89 DOCSIS, or Data-Over-Cable Service Interface Specifications, is 90 defined by CableLabs (www.cablelabs.com). 92 Additional terms used in this document are likely defined in [7]. 94 2. Introduction 96 "The Client FQDN Option" [4] includes a description of the operation 97 of DHCPv4 [8] clients and servers that use the DHCPv4 client FQDN 98 option. And, "The DHCPv6 Client FQDN Option" [5] includes a 99 description of the operation of DHCPv6 [10] clients and servers that 100 use the DHCPv6 client FQDN option. Through the use of the client 101 FQDN option, DHCP clients and servers can negotiate the client's FQDN 102 and the allocation of responsibility for updating the DHCP client's A 103 and/or AAAA RRs. This document identifies situations in which 104 conflicts in the use of FQDNs may arise among DHCP clients and 105 servers, and describes a strategy for the use of the DHCID DNS 106 resource record [2] in resolving those conflicts. 108 In any case, whether a site permits all, some, or no DHCP servers and 109 clients to perform DNS updates (RFC 2136 [3], RFC 3007 [12]) into the 110 zones that it controls is entirely a matter of local administrative 111 policy. This document does not require any specific administrative 112 policy, and does not propose one. The range of possible policies is 113 very broad, from sites where only the DHCP servers have been given 114 credentials that the DNS servers will accept, to sites where each 115 individual DHCP client has been configured with credentials that 116 allow the client to modify its own FQDN. Compliant implementations 117 MAY support some or all of these possibilities. Furthermore, this 118 specification applies only to DHCP client and server processes; it 119 does not apply to other processes that initiate DNS updates. 121 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 [4] 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 [15]) and NOTIFY (RFC 1996 [16]) 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 [6]. Otherwise, a dual-stack client that uses 301 older-style DHCPv4 client identifiers (see [8] and [9]) will only be 302 able to have either its A or AAAA records in DNS under a single FQDN 303 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 has two choices as to where to start the update sequence. The choice 309 of whether to start with the lookup query in Section 6.3.1 or to 310 start directly with the update in Section 6.3.2 is left to the 311 implementer. 313 Implementers MAY use other algorithms, provided that the algorithm 314 assures that the DNS updates are done with the proper prerequisites 315 to prevent incorrect or incomplete updates should multiple updaters 316 be updating the same FQDN at once. 318 As the update sequence below can result in loops, implementers SHOULD 319 limit the total number of attempts for a single transaction. 321 6.3.1 Initial DHCID RR Query 323 When a DHCP client or server intends to update A and/or AAAA RRs, it 324 performs a DNS query with QNAME of the target FQDN and with QTYPE of 325 DHCID. 327 If the query returns NXDOMAIN, the updater can conclude that the FQDN 328 is not in use and proceeds to Section 6.3.2. 330 If the query returns NOERROR but without an answer, the updater can 331 conclude that the target FQDN is in use, but that no DHCID RR is 332 present. This indicates that some records have been configured by an 333 administrator. Whether the updater proceeds with the update is a 334 matter of local administrative policy. Or, the updater may proceed 335 to Section 6.3.4. 337 If the query returns NOERROR with a DHCID rrset, the updater uses the 338 hash calculation defined in the DHCID RR specification [2] to 339 determine whether the client associated with the FQDN matches the 340 current client's identity. If so, the updater proceeds to 341 Section 6.3.3. Otherwise the updater must conclude that the client's 342 desired FQDN is in use by another client and proceeds to 343 Section 6.3.4. 345 If any other status is returned, the updater SHOULD NOT attempt an 346 update. 348 6.3.2 DNS UPDATE When FQDN Not in Use 350 The updater prepares a DNS UPDATE query that includes as a 351 prerequisite the assertion that the FQDN does not exist. The update 352 section of the query attempts to add the new FQDN and its IP address 353 mapping (A and/or AAAA RRs) and the DHCID RR with its unique client 354 identity. 356 If the update operation succeeds, the A and/or AAAA RR update is now 357 complete (and a client updater is finished, while a server would then 358 proceed to perform a PTR RR update). 360 If the update returns YXDOMAIN, the updater can now conclude that the 361 intended FQDN is in use and proceeds to Section 6.3.3. 363 6.3.3 DNS UPDATE When FQDN in Use 365 The updater next attempts to confirm that the FQDN is not being used 366 by some other client by preparing an UPDATE query in which there are 367 two prerequisites. The first prerequisite is that the FQDN exists. 368 The second is that the desired FQDN has attached to it a DHCID RR 369 whose contents match the client identity. The update section of the 370 UPDATE query contains: 371 1. A delete of any existing A RRs on the FQDN if this is an A update 372 or an AAAA update and the updater does not desire A records on 373 the FQDN. 374 2. A delete of the existing AAAA RRs on the FQDN if the updater does 375 not desire AAAA records on the FQDN or this update is adding an 376 AAAA and the updater only desires a single IP address on the 377 FQDN. 378 3. An add of the A RR that matches the DHCP binding if this is an A 379 update. 380 4. Adds of the AAAA RRs that match the DHCP bindings if this is an 381 AAAA update. 383 If the update succeeds, the updater can conclude that the current 384 client was the last client associated with the FQDN, and that the 385 FQDN now contains the updated A and/or AAAA RRs. The update is now 386 complete (and a client updater is finished, while a server would then 387 proceed to perform a PTR RR update). 389 If the update returns NXDOMAIN, the FQDN is no longer in use and the 390 updater proceeds to Section 6.3.2. 392 If the update returns NXRRSET, there are two possibilities - there 393 are no DHCID RRs for the FQDN or the DHCID RR does not match. In 394 either case, the updater proceeds to Section 6.3.4. 396 6.3.4 FQDN in Use by another Client 398 At this juncture, the updater can decide (based on some 399 administrative configuration outside of the scope of this document) 400 whether to let the existing owner of the FQDN keep that FQDN, and to 401 (possibly) perform some FQDN disambiguation operation on behalf of 402 the current client, or to replace the RRs on the FQDN with RRs that 403 represent the current client. If the configured policy allows 404 replacement of existing records, the updater submits a query that 405 deletes all RRs for the FQDN and adds the A and/or AAAA and DHCID RRs 406 that represent the IP address and client identity of the new client. 408 Techniques that may be considered to disambiguate FQDNs include 409 adding some suffix or prefix to the hostname portion of the FQDN or 410 randomly generating a hostname. 412 DISCUSSION: 414 The updating entity may be configured to allow the existing DNS 415 records on the FQDN to remain unchanged, and to perform 416 disambiguation on the FQDN of the current client in order to 417 attempt to generate a similar but unique FQDN for the current 418 client. In this case, once another candidate FQDN has been 419 generated, the updater should restart the process of adding A 420 and/or AAAA RRs as specified in this section. 422 6.4 Adding PTR RR Entries to DNS 424 The DHCP server submits a DNS query that deletes all of the PTR RRs 425 associated with the client's assigned IP address, and adds a PTR RR 426 whose data is the client's (possibly disambiguated) FQDN. The server 427 MAY also add a DHCID RR as specified in Section 4, in which case it 428 would include a delete of all of the DHCID RRs associated with the 429 client's assigned IP address, and adds a DHCID RR for the client. 431 There is no need to validate the DHCID RR for PTR updates as the DHCP 432 server (or servers) only assigns an address to a single client at a 433 time. 435 6.5 Removing Entries from DNS 437 The most important consideration in removing DNS entries is be sure 438 that an entity removing a DNS entry is only removing an entry that it 439 added, or for which an administrator has explicitly assigned it 440 responsibility. 442 When an address' lease time or valid lifetime expires or a DHCP 443 client issues a DHCPRELEASE [8] or Release [10] request, the DHCP 444 server SHOULD delete the PTR RR that matches the DHCP binding, if one 445 was successfully added. The server's update query SHOULD assert that 446 the domain name (PTRDNAME field) in the PTR record matches the FQDN 447 of the client whose address has expired or been released and should 448 delete all RRs for the FQDN. 450 The entity chosen to handle the A or AAAA records for this client 451 (either the client or the server) SHOULD delete the A or AAAA records 452 that was added when the address was assigned to the client. However, 453 the updater should only remove the DHCID RR if there are no A or AAAA 454 RRs remaining for the client. 456 In order to perform this A or AAAA RR delete, the updater prepares an 457 UPDATE query that contains a prerequisite that asserts that the DHCID 458 RR exists whose data is the client identity described in Section 4 459 and contains an update section that deletes the client's specific A 460 or AAAA RR. 462 If the query succeeds, the updater prepares a second UPDATE query 463 that contains three prerequisites and contains an update section that 464 deletes all RRs for the FQDN. The first prerequisite asserts that 465 the DHCID RR exists whose data is the client identity described in 466 Section 4. The second prerequisite asserts that there are no A RRs. 467 The third prerequisite asserts that there are no AAAA RRs. 469 If either query fails, the updater MUST NOT delete the FQDN. It may 470 be that the client whose address has expired has moved to another 471 network and obtained an address from a different server, which has 472 caused the client's A or AAAA RR to be replaced. It may also be that 473 some other client has been configured with a FQDN that matches the 474 FQDN of the DHCP client, and the policy was that the last client to 475 specify the FQDN would get the FQDN. In these cases, the DHCID RR 476 will no longer match the updater's notion of the client identity of 477 the client pointed to by the FQDN. 479 6.6 Updating Other RRs 481 The procedures described in this document only cover updates to the 482 A, AAAA, PTR, and DHCID RRs. Updating other types of RRs is outside 483 the scope of this document. 485 7. Security Considerations 487 Administrators should be wary of permitting unsecured DNS updates to 488 zones, where or not they are exposed to the global Internet. Both 489 DHCP clients and servers SHOULD use some form of update request 490 authentication (e.g., TSIG [13]) when performing DNS updates. 492 Whether a DHCP client may be responsible for updating an FQDN to IP 493 address mapping, or whether this is the responsibility of the DHCP 494 server is a site-local matter. The choice between the two 495 alternatives may be based on the security model that is used with the 496 Dynamic DNS Update protocol (e.g., only a client may have sufficient 497 credentials to perform updates to the FQDN to IP address mapping for 498 its FQDN). 500 Whether a DHCP server is always responsible for updating the FQDN to 501 IP address mapping (in addition to updating the IP to FQDN mapping), 502 regardless of the wishes of an individual DHCP client, is also a 503 site-local matter. The choice between the two alternatives may be 504 based on the security model that is being used with dynamic DNS 505 updates. In cases where a DHCP server is performing DNS updates on 506 behalf of a client, the DHCP server should be sure of the FQDN to use 507 for the client, and of the identity of the client. 509 Currently, it is difficult for DHCP servers to develop much 510 confidence in the identities of their clients, given the absence of 511 entity authentication from the DHCP protocol itself. There are many 512 ways for a DHCP server to develop a FQDN to use for a client, but 513 only in certain relatively rare circumstances will the DHCP server 514 know for certain the identity of the client. If DHCP Authentication 515 [14] becomes widely deployed this may become more customary. 517 One example of a situation that offers some extra assurances is when 518 the DHCP client is connected to a network through a DOCSIS cable 519 modem, and the Cable Modem Termination System (head-end) of the cable 520 modem ensures that MAC address spoofing simply does not occur. 521 Another example of a configuration that might be trusted is when 522 clients obtain network access via a network access server using PPP. 523 The Network Access Server (NAS) itself might be obtaining IP 524 addresses via DHCP, encoding client identification into the DHCP 525 client-id option. In this case, the NAS as well as the DHCP server 526 might be operating within a trusted environment, in which case the 527 DHCP server could be configured to trust that the user authentication 528 and authorization processing of the NAS was sufficient, and would 529 therefore trust the client identification encoded within the DHCP 530 client-id. 532 8. Acknowledgements 534 Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter 535 Ford, Olafur Gudmundsson, Edie Gunter, Andreas Gustafsson, R. Barr 536 Hibbs, Kim Kinnear, Stuart Kwan, Ted Lemon, Ed Lewis, Michael Lewis, 537 Josh Littlefield, Michael Patton, and Glenn Stump for their review 538 and comments. 540 9. References 542 9.1 Normative References 544 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 545 Levels", BCP 14, RFC 2119, March 1997. 547 [2] Stapp, M., Gustafsson, A., and T. Lemon, "A DNS RR for Encoding 548 DHCP Information (draft-ietf-dnsext-dhcid-rr-*)", February 2005. 550 [3] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 551 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 552 April 1997. 554 9.2 Informative References 556 [4] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option 557 (draft-ietf-dhc-fqdn-option-*.txt)", February 2005. 559 [5] Volz, B., "The DHCPv6 Client FQDN Option 560 (draft-ietf-dhc-dhcpv6-fqdn-*.txt)", February 2005. 562 [6] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers 563 for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*txt)", June 2005. 565 [7] Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996. 567 [8] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 568 March 1997. 570 [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 571 Extensions", RFC 2132, March 1997. 573 [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 574 Carney, "Dynamic Host Configuration Protocol for IPv6 575 (DHCPv6)", RFC 3315, July 2003. 577 [11] Eastlake, D., "Domain Name System Security Extensions", 578 RFC 2535, March 1999. 580 [12] Wellington, B., "Secure Domain Name System (DNS) Dynamic 581 Update", RFC 3007, November 2000. 583 [13] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, 584 "Secret Key Transaction Authentication for DNS (TSIG)", 585 RFC 2845, May 2000. 587 [14] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 588 RFC 3118, June 2001. 590 [15] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 591 August 1996. 593 [16] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes 594 (DNS NOTIFY)", RFC 1996, August 1996. 596 Authors' Addresses 598 Mark Stapp 599 Cisco Systems, Inc. 600 1414 Massachusetts Ave. 601 Boxborough, MA 01719 602 USA 604 Phone: 978.936.1535 605 Email: mjs@cisco.com 607 Bernie Volz 608 Cisco Systems, Inc. 609 1414 Massachusetts Ave. 610 Boxborough, MA 01719 611 USA 613 Phone: 978.936.0382 614 Email: volz@cisco.com 616 Intellectual Property Statement 618 The IETF takes no position regarding the validity or scope of any 619 Intellectual Property Rights or other rights that might be claimed to 620 pertain to the implementation or use of the technology described in 621 this document or the extent to which any license under such rights 622 might or might not be available; nor does it represent that it has 623 made any independent effort to identify any such rights. Information 624 on the procedures with respect to rights in RFC documents can be 625 found in BCP 78 and BCP 79. 627 Copies of IPR disclosures made to the IETF Secretariat and any 628 assurances of licenses to be made available, or the result of an 629 attempt made to obtain a general license or permission for the use of 630 such proprietary rights by implementers or users of this 631 specification can be obtained from the IETF on-line IPR repository at 632 http://www.ietf.org/ipr. 634 The IETF invites any interested party to bring to its attention any 635 copyrights, patents or patent applications, or other proprietary 636 rights that may cover technology that may be required to implement 637 this standard. Please address the information to the IETF at 638 ietf-ipr@ietf.org. 640 Disclaimer of Validity 642 This document and the information contained herein are provided on an 643 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 644 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 645 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 646 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 647 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 648 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 650 Copyright Statement 652 Copyright (C) The Internet Society (2005). This document is subject 653 to the rights, licenses and restrictions contained in BCP 78, and 654 except as set forth therein, the authors retain all their rights. 656 Acknowledgment 658 Funding for the RFC Editor function is currently provided by the 659 Internet Society.