DNSIND Working Group Brian Wellington (TISLabs) INTERNET-DRAFT Olafur Gudmundsson (TISLabs) April 1999 Updates: RFC 2136 Deferred Dynamic Domain Name System (DNS) Delete Operations Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document proposes a mechanism for notifying a dynamic DNS server that a delete operation should be performed at a certain point in the future. This works within the framework of the current DNS dynamic update protocol, and provides needed functionality for clients with leased dynamic addresses. Expires October 1999 [Page 1] INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 1 - Introduction Dynamic update operations for the Domain Name System [RFC1034, RFC1035] are defined in [RFC2136], but there is no automated method of specifying that records should have a fixed lifetime, or lease. 1.1 - Overview of DNS Dynamic Update DNS dynamic update defines a new DNS opcode and a new interpretation of the DNS message if that opcode is used. An update can specify insertions or deletions of data, along with prerequisites necessary for the updates to occur. All tests and changes for a DNS update request are restricted to a single zone, and are performed at the primary server for the zone. The primary server for a dynamic zone must increment the zone SOA serial number when an update occurs or before the next retrieval of the SOA. 1.2 - Overview of DHCP leases DHCP [RFC2131] provides a means for a host to obtain a network address from a DHCP server. The server may ``lease'' this address to the host, meaning that it is valid only for the period of time specified in the lease. The host may may extend its lease with subsequent requests, or may issue a message to release the address back to the server when it is no longer needed. 2 - Background When a host receives dynamic addresses with associated dynamic DNS records, the records can be updated by either the host or the DHCP server. In many cases, update by the server is recommended, since the server maintains lease information for each address. In some cases, though, the server cannot update some or all of the DNS records. This happens when the DNS and DHCP server are under different administration, for example. A host can easily update its own DNS records when receiving information from the DHCP server. It can also delete its records when shutting down. If the host unexpectedly goes down, though, it cannot delete the records. When the DHCP lease on the address expires and is not renewed, the DHCP server may reassign the address. The DNS records now point to an assigned address, but not the correct address. Until the host updates its records again, DNS will contain bad information. Since the DHCP and DNS servers are often not co-located with the clients, the possibility of a host unexpectedly going down and not communicating with the servers is non-trivial. Expires October 1999 [Page 2] INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 If the host could set a lease on the DNS records similar to that on its address, the DNS records would lose validity at the same time as the address. This would prevent bad information from remaining in DNS. DNS has no such provision for leases, though, since this would require storing a lease time along with each record (or each record in a dynamic zone). An alternative method is suggested. A ``delete'' update is sent along with the ``add'' update, but the delete is marked in such a way that it will not be exectuted immediately. Instead, it will be stored for the specified amount of time before being applied. If the host wishes to extend or shorten the lifetime of the DNS record(s), it can replace the ``deferred delete'' record, which will reset the lease time of the record(s). The ``deferred delete'' record would, of course, also be removed if a normal delete update was received. 3 - Protocol changes When doing a delete update operation as defined in [RFC2136] (deleting an RR, an RRset, or all RRset from a name), the TTL field MUST be specified as 0. An [RFC2136] compliant server will silently ignore (*) an update record with a non-zero TTL. This document overloads the TTL field. If TTL is non-zero, the value represents the number of seconds (a 32 bit unsigned integer) before which the delete will be applied to the zone. Thus, the delete operation will be deferred for that number of seconds, where the number of seconds indicates the lease time. A 32 bit integer provides for a lease time of over 136 years, which should be long enough for most uses. 3.1 - Storage and execution Deferred delete records are stored, persistently, by the name server. The name server SHOULD attempt to evaluate the deletes in a timely manner. If multiple deferred deletes are sent in the same DNS message with the same TTL value, they MUST be processed atomically if processed as planned (that is, none of the deferred deletes are updated or cancelled). 3.2 - Processing of deferred deletes When a deferred delete is received, the server must check to see if it matches an existing deferred delete records, where matching indicates the same name, type, class, and rdata. If a match is found, the new deferred delete MUST replace the old one. If the deferred delete does not refer to any record in the server, it should fail as a normal delete would. Expires October 1999 [Page 3] INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 3.3 - Processing of normal deletes When a normal delete is received and accepted, the server SHOULD purge any matching deferred delete records. 3.4 - Processing of cancellations The value 0xFFFFFFFF (the largest unsigned 32 bit integer) in the TTL field has a special meaning. If a delete containing this lease time is received, the server will unconditionally remove any matching deferred deletes. If no deferred delete matches, this request will be silently ignored. 3.5 - Processing of adds When data is added through a dynamic update which matches a deferred delete, there is no additional processing done. 4 - TTL handling Any record that may be deleted SHOULD have a short TTL compared to its lease time, to prevent deleted data from being cached past its expiration. When the time until an RR is deleted becomes low enough, the server MAY modify the TTL of the RRset. Whenever the TTL is automatically reduced by this process, the zone will be considered ``changed'' for the purpose of automatic SOA SERIAL increment (as in [RFC2136]) and real time zone slave notification [RFC1996]. As these operations can potentially be expensive (more so if DNSSEC [RFC2535] signatures must be regenerated), the specific limits and effects are left to the implementation. If the TTL is modified by the server, it is not reset if the lease is renewed. Therefore, the original RR SHOULD be sent with the lease renewal if the client expects that the server has modified the TTL. Expires October 1999 [Page 4] INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 5 - Usage Normally, a deferred delete update will initially be sent along with an add, although this is not required. Further updates to the deferred delete may be sent independently, although the add should be sent again. If the deferred delete is associated with a leased address, the lease time of the update SHOULD be approximately equal to the lease time of the address. 6 - Protocol robustness This protocol has no inherent protection against replayed messages, which can either originate from an attack or faulty hardware. To prevent this problem, prerequisites should be used in the update message, such as a test for the existence of a TXT record describing the lease, which would be added along with the other records (see [RFC2136], section 5). 7 - Security considerations This addition to the dynamic DNS protocol does not affect the security of the protocol. If security is desired, TSIG [TSIG] and/or DNSSEC [RFC2535] authentication should be used, as specified in [simple-update] or [RFC2137, update2]. The authors strongly recommend using security along with this protocol. If a DNSSEC signed-zone is modified with deferred deletes, the server must resign any affected records when the delete is executed. No special processing is required when the delete is received. 8 - IANA Considerations None. 9 - References [RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' RFC 1034, ISI, November 1987. [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC 1035, ISI, November 1987. [RFC1996] P. Vixie ``A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY),'' RFC 1996, ISC, August 1996. [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore & Cisco & DEC, April 1997. Expires October 1999 [Page 5] INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 [RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC 2137, CyberCash, April 1997. [RFC2535] D. Eastlake ``Domain Name System Security Extensions,'' RFC 2535, IBM, March 1999. [TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington ``Secret Key Transaction Signatures for DNS (TSIG),'' draft- ietf-dnsind-tsig-08.txt, ISC & TISLabs & IBM & TISLabs, February 1999. [simple-update] B. Wellington ``Simple Secure Domain Name System (DNS) Dynamic Update,'' draft-ietf-dnssec-simple-update-00.txt, TISLabs, November 1998. [update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite Systems Company, August 1998. 8 - Author's Address Brian Wellington Olafur Gudmundsson TISLabs at Network Associates TISLabs at Network Associates 3060 Washington Road, Route 97 3060 Washington Road, Route 97 Glenwood, MD 21738 Glenwood, MD 21738 +1 443 259 2369 +1 443 259 2389 Expires October 1999 [Page 6]