idnits 2.17.1 draft-ietf-dhc-ddns-resolution-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 (October 27, 2003) is 7486 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 451, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 454, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 471, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 474, but no explicit reference was found in the text -- No information found for draft-ietf-dnsext-dhcid-rr- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' -- No information found for draft-ietf-dhc-fqdn-option- - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1594 (ref. '9') (Obsoleted by RFC 2664) -- 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: 2 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group M. Stapp 3 Internet-Draft Cisco Systems, Inc. 4 Expires: April 26, 2004 October 27, 2003 6 Resolution of DNS Name Conflicts Among DHCP Clients 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on April 26, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 DHCP provides a powerful mechanism for IP host configuration. 39 However, the configuration capability provided by DHCP does not 40 include updating DNS, and specifically updating the name to address 41 and address to name mappings maintained in the DNS. This document 42 describes techniques for the resolution of DNS name conflicts among 43 DHCP clients. 45 Table of Contents 47 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Issues with DNS Update in DHCP Environments . . . . . . . . 3 50 3.1 Client Mis-Configuration . . . . . . . . . . . . . . . . . . 4 51 3.2 Multiple DHCP Servers . . . . . . . . . . . . . . . . . . . 5 52 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 5 53 5. DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . 6 54 6. Procedures for performing DNS updates . . . . . . . . . . . 6 55 6.1 Error Return Codes . . . . . . . . . . . . . . . . . . . . . 6 56 6.2 Dual IPv4/IPv6 Client Considerations . . . . . . . . . . . . 6 57 6.3 Adding A RRs to DNS . . . . . . . . . . . . . . . . . . . . 7 58 6.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 6.3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 6.3.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 6.4 Adding PTR RR Entries to DNS . . . . . . . . . . . . . . . . 8 62 6.5 Removing Entries from DNS . . . . . . . . . . . . . . . . . 8 63 6.6 Updating Other RRs . . . . . . . . . . . . . . . . . . . . . 9 64 7. Security Considerations . . . . . . . . . . . . . . . . . . 9 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 66 References . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 References . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . 11 69 Full Copyright Statement . . . . . . . . . . . . . . . . . . 12 71 1. Terminology 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119[1]. 77 2. Introduction 79 "The Client FQDN Option"[6] includes a description of the operation 80 of DHCP[7] clients and servers that use the client FQDN option. 81 Through the use of the client FQDN option, DHCP clients and servers 82 can negotiate the client's FQDN and the allocation of responsibility 83 for updating the DHCP client's A or AAAA RR. This document 84 identifies situations in which conflicts in the use of FQDNs may 85 arise among DHCP clients, and describes a strategy for the use of 86 the DHCID DNS resource record[4] in resolving those conflicts. 88 In any case, whether a site permits all, some, or no DHCP servers 89 and clients to perform DNS updates (RFC 2136[5], RFC 3007[11]) into 90 the zones that it controls is entirely a matter of local 91 administrative policy. This document does not require any specific 92 administrative policy, and does not propose one. The range of 93 possible policies is very broad, from sites where only the DHCP 94 servers have been given credentials that the DNS servers will 95 accept, to sites where each individual DHCP client has been 96 configured with credentials that allow the client to modify its own 97 domain name. Compliant implementations MAY support some or all of 98 these possibilities. Furthermore, this specification applies only to 99 DHCP client and server processes: it does not apply to other 100 processes that initiate DNS updates. 102 3. Issues with DNS Update in DHCP Environments 104 There are two DNS update situations that require special 105 consideration in DHCP environments: cases where more than one DHCP 106 client has been configured with the same FQDN, and cases where more 107 than one DHCP server has been given authority to perform DNS updates 108 in a zone. In these cases, it is possible for DNS records to be 109 modified in inconsistent ways unless the updaters have a mechanism 110 that allows them to detect anomolous situations. If DNS updaters can 111 detect these situations, site administrators can configure the 112 updaters' behavior so that the site's policies can be enforced. We 113 use the term "Name Conflict" to refer to cases where more than one 114 DHCP client wishes to be associated with a single FQDN. This 115 specification describes a mechanism designed to allow updaters to 116 detect these situations, and suggests that DHCP implementations use 117 this mechanism by default. 119 3.1 Client Mis-Configuration 121 At many (though not all) sites, administrators wish to maintain a 122 one-to-one relationship between active DHCP clients and domain 123 names, and to maintain consistency between a host's A and PTR RRs. 124 Hosts that are not represented in the DNS, or hosts which 125 inadvertently share an FQDN with another host may encounter 126 inconsistent behavior or may not be able to obtain access to network 127 resources. Whether each DHCP client is configured with a domain name 128 by its administrator or whether the DHCP server is configured to 129 distribute the clients' names, the consistency of the DNS data is 130 entirely dependent on the accuracy of the configuration procedure. 131 Sites that deploy Secure DNS[10] may configure credentials for each 132 host and its assigned name in a way that is more error-resistant, 133 but this level of pre-configuration is still rare in DHCP 134 environments. 136 Consider an example in which two DHCP clients in the "org.nil" 137 network are both configured with the name "foo". The clients are 138 permitted to perform their own DNS updates. The first client, client 139 A, is configured via DHCP. It adds an A RR to "foo.org.nil", and its 140 DHCP server adds a PTR RR corresponding to its IP address lease. 141 When the second client, client B, boots, it is also configured via 142 DHCP, and it also begins to update "foo.org.nil". 144 At this point, the "org.nil" administrators may wish to establish 145 some policy about DHCP clients' DNS names. If the policy is that 146 each client that boots should replace any existing A RR that matches 147 its name, Client B can proceed, though Client A may encounter 148 problems. In this example, Client B replaces the A RR associated 149 with "foo.org.nil". Client A must have some way to recognize that 150 the RR associated with "foo.org.nil" now contains information for 151 Client B, so that it can avoid modifying the RR. When Client A's 152 lease expires, for example, it should not remove an RR that reflects 153 Client B's DHCP lease. 155 If the policy is that the first DHCP client with a given name should 156 be the only client associated with that name, Client B needs to be 157 able to determine that it is not the client associated with 158 "foo.org.nil". It could be that Client A booted first, and that 159 Client B should choose another name. Or it could be that B has 160 booted on a new subnet, and received a new lease. It must either 161 retain persistent state about the last lease it held (in addition to 162 its current lease) or it must have some other way to detect that it 163 was the last updater of "foo.org.nil" in order to implement the 164 site's policy. 166 3.2 Multiple DHCP Servers 168 At many sites, the difficulties with distributing DNS update 169 credentials to all of the DHCP clients lead to the desire for the 170 DHCP servers to perform A RR updates on behalf of their clients. If 171 a single DHCP server managed all of the DHCP clients at a site, it 172 could maintain some database of the DNS names that it was managing, 173 and check that database before initiating a DNS update for a client. 174 Such a database is necessarily proprietary, however, and that 175 approach does not work once more than one DHCP server is deployed. 177 Consider an example in which DHCP Client A boots, obtains a DHCP 178 lease from Server S1, presenting the hostname "foo" in a Client FQDN 179 option[6] in its DHCPREQUEST message. Server S1 updates its domain 180 name, "foo.org.nil", adding an A RR that matches Client A's lease. 181 The client then moves to another subnet, served by Server S2. When 182 Client A boots on the new subnet, Server S2 will issue it a new 183 lease, and will attempt to add an A RR matching the new lease to 184 "foo.org.nil". At this point, without some communication mechanism 185 which S2 can use to ask S1 (and every other DHCP server that updates 186 the zone) about the client, S2 has no way to know whether Client A 187 is currently associated with the domain name, or whether A is a 188 different client configured with the same hostname. If the servers 189 cannot distinguish between these situations, they cannot enforce the 190 site's naming policies. 192 4. Use of the DHCID RR 194 A solution to both of these problems is for the updater (a DHCP 195 client or DHCP server) to be able to determine which DHCP client has 196 been associated with a DNS name, in order to offer administrators 197 the opportunity to configure updater behavior. 199 For this purpose, a DHCID RR, specified in [4], is used to associate 200 client identification information with a DNS name and the A or PTR 201 RR associated with that name. When either a client or server adds an 202 A or PTR RR for a client, it also adds a DHCID RR that specifies a 203 unique client identity, based on data from the client's DHCPREQUEST 204 message. In this model, only one A RR is associated with a given DNS 205 name at a time. 207 By associating this ownership information with each DNS name, 208 cooperating DNS updaters may determine whether their client is 209 currently associated with a particular DNS name and implement the 210 appropriately configured administrative policy. In addition, DHCP 211 clients which currently have domain names may move from one DHCP 212 server to another without losing their DNS names. 214 The specific algorithms utilizing the DHCID RR to signal client 215 ownership are explained below. The algorithms only work in the case 216 where the updating entities all cooperate -- this approach is 217 advisory only and is not a substitute for DNS security, nor is it 218 replaced by DNS security. 220 5. DNS RR TTLs 222 RRs associated with DHCP clients may be more volatile than 223 statically configured RRs. DHCP clients and servers that perform 224 dynamic updates should attempt to specify resource record TTLs which 225 reflect this volatility, in order to minimize the possibility that 226 answers to DNS queries will return records that refer to DHCP lease 227 bindings that have expired. 229 The coupling among primary, secondary, and caching DNS servers is 230 'loose'; that is a fundamental part of the design of the DNS. This 231 looseness makes it impossible to prevent all possible situations in 232 which a resolver may return a record reflecting a DHCP lease binding 233 that has expired. In deployment, this rarely if ever represents a 234 significant problem. Most DHCP-managed hosts are rarely looked-up by 235 name in the DNS, and the deployment of IXFR (RFC 1995[14]) and 236 NOTIFY (RFC 1996[15]) can reduce the latency between updates and 237 their visibility at secondary servers. 239 We suggest these basic guidelines for implementors. In general, the 240 TTLs for RRs added as a result of DHCP lease activity SHOULD be less 241 than the initial lease time. The RR TTL on a DNS record added for a 242 DHCP lease SHOULD NOT exceed 1/3 of the lease time, and SHOULD be at 243 least 10 minutes. We recognize that individual administrators will 244 have varying requirements: DHCP servers and clients SHOULD allow 245 administrators to configure TTLs, either as an absolute time 246 interval or as a percentage of the lease time. 248 6. Procedures for performing DNS updates 250 6.1 Error Return Codes 252 Certain RCODEs defined in RFC 2136[5] indicate that the destination 253 DNS server cannot perform an update: FORMERR, SERVFAIL, REFUSED, 254 NOTIMP. If one of these RCODEs is returned, the updater MUST 255 terminate its update attempt. Because these errors may indicate a 256 misconfiguration of the updater or of the DNS server, the updater 257 MAY attempt to signal to its administrator that an error has 258 occurred, e.g. through a log message. 260 6.2 Dual IPv4/IPv6 Client Considerations 262 At the time of publication of this document, a small minority of 263 DHCP clients support both IPv4 and IPv6. We anticipate, however, 264 that a transition will take place over a period of time, and more 265 sites will have dual-stack clients present. IPv6 clients will be 266 represented by AAAA RRs; IPv4 clients by A RRs. The administrators 267 of some mixed deployments may wish to permit a single name to 268 contain A and AAAA RRs from different clients. Other deployments may 269 wish to restrict the use of a DNS name to a single DHCP client, and 270 allow only A and AAAA RRs reflecting that client's DHCP leases. 272 6.3 Adding A RRs to DNS 274 6.3.1 276 When a DHCP client or server intends to update an A RR, it performs 277 a DNS query with QNAME of the target name, and QTYPE is DHCID. If 278 the result is NXDOMAIN, the updater can conclude that the name is 279 not in use. In that case, the updater prepares a DNS UPDATE query 280 that includes as a prerequisite the assertion that the name does not 281 exist. The update section of the query attempts to add the new name 282 and its IP address mapping (an A RR), and the DHCID RR with its 283 unique client-identity. 285 If the query returns with NODATA, the updater can conclude that the 286 target name is in use, but that no DHCID RR is present. This 287 indicates that some records have been configured by an 288 administrator. Whether the updater proceeds with an update is a 289 matter of local administrative policy. 291 If the DHCID rrset is returned, the updater uses the hash 292 calculation defined in the DHCID RR specification[4] to determine 293 whether the client associated with the name matches the current 294 client's identity. If so, the updater proceeds following the steps 295 in [subsection xxx]. 297 If any other status is returned, the updater MUST NOT attempt an 298 update. 300 6.3.2 302 If the update operation in Section 6.3.1 fails with YXDOMAIN, the 303 updater can conclude that the intended name is in use. The updater 304 then attempts to confirm that the DNS name is not being used by some 305 other host. The updater prepares a second UPDATE query in which the 306 prerequisite is that the desired name has attached to it a DHCID RR 307 whose contents match the client identity. The update section of 308 this query deletes the existing A records on the name, and adds the 309 A record that matches the DHCP binding and the DHCID RR with the 310 client identity. 312 If this query succeeds, the updater can conclude that the current 313 client was the last client associated with the domain name, and that 314 the name now contains the updated A RR. The A RR update is now 315 complete (and a client updater is finished, while a server would 316 then proceed to perform a PTR RR update). 318 6.3.3 320 If the second query fails with NXRRSET, the updater must conclude 321 that the client's desired name is in use by another host. At this 322 juncture, the updater can decide (based on some administrative 323 configuration outside of the scope of this document) whether to let 324 the existing owner of the name keep that name, and to (possibly) 325 perform some name disambiguation operation on behalf of the current 326 client, or to replace the RRs on the name with RRs that represent 327 the current client. If the configured policy allows replacement of 328 existing records, the updater submits a query that deletes the 329 existing A RR and the existing DHCID RR, adding A and DHCID RRs that 330 represent the IP address and client-identity of the new client. 332 DISCUSSION: 333 The updating entity may be configured to allow the existing DNS 334 records on the domain name to remain unchanged, and to perform 335 disambiguation on the name of the current client in order to 336 attempt to generate a similar but unique name for the current 337 client. In this case, once another candidate name has been 338 generated, the updater should restart the process of adding an A 339 RR as specified in this section. 341 6.4 Adding PTR RR Entries to DNS 343 The DHCP server submits a DNS query that deletes all of the PTR RRs 344 associated with the lease IP address, and adds a PTR RR whose data 345 is the client's (possibly disambiguated) host name. The server MAY 346 also add a DHCID RR as specified in Section 4. 348 6.5 Removing Entries from DNS 350 The most important consideration in removing DNS entries is be sure 351 that an entity removing a DNS entry is only removing an entry that 352 it added, or for which an administrator has explicitly assigned it 353 responsibility. 355 When a lease expires or a DHCP client issues a DHCPRELEASE request, 356 the DHCP server SHOULD delete the PTR RR that matches the DHCP 357 binding, if one was successfully added. The server's update query 358 SHOULD assert that the name in the PTR record matches the name of 359 the client whose lease has expired or been released. 361 The entity chosen to handle the A record for this client (either the 362 client or the server) SHOULD delete the A record that was added when 363 the lease was made to the client. 365 In order to perform this delete, the updater prepares an UPDATE 366 query that contains two prerequisites. The first prerequisite 367 asserts that the DHCID RR exists whose data is the client identity 368 described in Section 4. The second prerequisite asserts that the 369 data in the A RR contains the IP address of the lease that has 370 expired or been released. 372 If the query fails, the updater MUST NOT delete the DNS name. It 373 may be that the client whose lease on has expired has moved to 374 another network and obtained a lease from a different server, which 375 has caused the client's A RR to be replaced. It may also be that 376 some other client has been configured with a name that matches the 377 name of the DHCP client, and the policy was that the last client to 378 specify the name would get the name. In these cases, the DHCID RR 379 will no longer match the updater's notion of the client-identity of 380 the host pointed to by the DNS name. 382 6.6 Updating Other RRs 384 The procedures described in this document only cover updates to the 385 A and PTR RRs. Updating other types of RRs is outside the scope of 386 this document. 388 7. Security Considerations 390 Unauthenticated updates to the DNS can lead to tremendous confusion, 391 through malicious attack or through inadvertent misconfiguration. 392 Administrators should be wary of permitting unsecured DNS updates to 393 zones that are exposed to the global Internet. Both DHCP clients and 394 servers SHOULD use some form of update request authentication (e.g., 395 TSIG[12]) when performing DNS updates. 397 Whether a DHCP client may be responsible for updating an FQDN to IP 398 address mapping, or whether this is the responsibility of the DHCP 399 server is a site-local matter. The choice between the two 400 alternatives may be based on the security model that is used with 401 the Dynamic DNS Update protocol (e.g., only a client may have 402 sufficient credentials to perform updates to the FQDN to IP address 403 mapping for its FQDN). 405 Whether a DHCP server is always responsible for updating the FQDN to 406 IP address mapping (in addition to updating the IP to FQDN mapping), 407 regardless of the wishes of an individual DHCP client, is also a 408 site-local matter. The choice between the two alternatives may be 409 based on the security model that is being used with dynamic DNS 410 updates. In cases where a DHCP server is performing DNS updates on 411 behalf of a client, the DHCP server should be sure of the DNS name 412 to use for the client, and of the identity of the client. 414 Currently, it is difficult for DHCP servers to develop much 415 confidence in the identities of their clients, given the absence of 416 entity authentication from the DHCP protocol itself. There are many 417 ways for a DHCP server to develop a DNS name to use for a client, 418 but only in certain relatively rare circumstances will the DHCP 419 server know for certain the identity of the client. If DHCP 420 Authentication[13] becomes widely deployed this may become more 421 customary. 423 One example of a situation that offers some extra assurances is one 424 where the DHCP client is connected to a network through an MCNS 425 cable modem, and the CMTS (head-end) of the cable modem ensures that 426 MAC address spoofing simply does not occur. Another example of a 427 configuration that might be trusted is one where clients obtain 428 network access via a network access server using PPP. The NAS itself 429 might be obtaining IP addresses via DHCP, encoding a client 430 identification into the DHCP client-id option. In this case, the 431 network access server as well as the DHCP server might be operating 432 within a trusted environment, in which case the DHCP server could be 433 configured to trust that the user authentication and authorization 434 processing of the remote access server was sufficient, and would 435 therefore trust the client identification encoded within the DHCP 436 client-id. 438 8. Acknowledgements 440 Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter 441 Ford, Olafur Gudmundsson, Edie Gunter, Andreas Gustafsson, R. Barr 442 Hibbs, Kim Kinnear, Stuart Kwan, Ted Lemon, Ed Lewis, Michael Lewis, 443 Josh Littlefield, Michael Patton, Glenn Stump, and Bernie Volz for 444 their review and comments. 446 Normative References 448 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 449 Levels", RFC 2119, March 1997. 451 [2] Mockapetris, P., "Domain names - Concepts and Facilities", RFC 452 1034, Nov 1987. 454 [3] Mockapetris, P., "Domain names - Implementation and 455 Specification", RFC 1035, Nov 1987. 457 [4] Stapp, M., Gustafsson, A. and T. Lemon, "A DNS RR for Encoding 458 DHCP Information (draft-ietf-dnsext-dhcid-rr-*)", October 2003. 460 [5] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 461 Updates in the Domain Name System", RFC 2136, April 1997. 463 Informative References 465 [6] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option 466 (draft-ietf-dhc-fqdn-option-*.txt)", October 2003. 468 [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 469 March 1997. 471 [8] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 472 April 1992. 474 [9] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and 475 Answers to Commonly asked ``New Internet User'' Questions", 476 RFC 1594, March 1994. 478 [10] Eastlake, D., "Domain Name System Security Extensions", RFC 479 2535, March 1999. 481 [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic 482 Update", RFC 3007, November 2000. 484 [12] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 485 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 486 2845, May 2000. 488 [13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 489 RFC 3118, June 2001. 491 [14] Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996. 493 [15] Vixie, P., "A Mechanism for Prompt Notification of Zone 494 Changes (DNS NOTIFY)", RFC 1996, August 1996. 496 Author's Address 498 Mark Stapp 499 Cisco Systems, Inc. 500 1414 Massachusetts Ave. 501 Boxborough, MA 01719 502 USA 504 Phone: 978.936.1535 505 EMail: mjs@cisco.com 507 Full Copyright Statement 509 Copyright (C) The Internet Society (2003). All Rights Reserved. 511 This document and translations of it may be copied and furnished to 512 others, and derivative works that comment on or otherwise explain it 513 or assist in its implementation may be prepared, copied, published 514 and distributed, in whole or in part, without restriction of any 515 kind, provided that the above copyright notice and this paragraph 516 are included on all such copies and derivative works. However, this 517 document itself may not be modified in any way, such as by removing 518 the copyright notice or references to the Internet Society or other 519 Internet organizations, except as needed for the purpose of 520 developing Internet standards in which case the procedures for 521 copyrights defined in the Internet Standards process must be 522 followed, or as required to translate it into languages other than 523 English. 525 The limited permissions granted above are perpetual and will not be 526 revoked by the Internet Society or its successors or assigns. 528 This document and the information contained herein is provided on an 529 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 530 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 531 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 532 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 533 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 535 Acknowledgement 537 Funding for the RFC editor function is currently provided by the 538 Internet Society.