INTERNET DRAFT M. A. Patton Expiration Date: July 1996 BBN February 1996 Scheduled Expiration of DNS Resource Records Status of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). This Internet Draft expires July 1996. [[[Global issues for entire draft: Draft as written expires all RRs of a type together. This seems to be reasonable given some other discussions, but may be controversial. Since my inclination was towards treating a whole RR set the same already and I couldn't figure out a good way to be more fine-grained, I felt it was useful to do it this way, at least to start. For all these reasons, I will leave it as is, unless someone comes up with a compelling reason for it, AND a good design for how to do it. Do we need to expire CNAMES? Can't put an EXP there...unless we make EXP an exception to that rule. I think the DNSsec does this for SIGs...just extend that exemption? Should the SOA serial be updated when records expire? I think the same words that are in the DynDNS draft should be put here... Problem is that this can happen in both primary and secondary servers. Interaction with Dynamic Update. Do expired RRs appear to be there or not for the conditioning section of an update. May want them to appear to be there for several reasons 1) they need to be deleted for real (maybe); 2) may be trying to replace just around time of expire and not having them is a race condition; and 3) may have been used in conditioning because a recent query showed it there. On the other hand, these may want to be really gone once expired, because they're no longer visible to queries and therefore updates may assume they don't exist and say that in the conditional part... Should anything be said about expiring EXP RRs? This draft lets you do it, which can result in odd behaviour. On the other hand, I don't see why outlawing it is really needed (maybe someone will come up with a good use for this "feature"). ]]] Abstract This document describes an additional RR type for the Domain Name System[7,8] which provides for scheduled expiration of RRs in the DNS. These RRs record the time at which a referenced set of RRs are to be removed from the DNS. This can be used to provide the information required to automatically support the reduced TTLs described in RFC1034[8] when anticipating a change, and by being in the zone data, will communicate that information to other servers that recognize the RR, in particular, secondary servers that recieve the data by Zone Transfer (AXFR or IXFR[2]). Introduction Several people have noted that the SIG RR from the DNS Security Extensions[1] can be used to enable the TTL count down and automatic deletion of RRs. This is a feature that has been discussed widely at times on various DNS related mailing lists. To allow this use of SIG RRs without the requirement for cryptography, the NULL SIG RR was introduced. In the later stages of development of the DNSsec draft, some concerns were raised by the security people at having a "Security" RR that, in fact, offered no security. The EXP RR described here is offered as an alternative to using NULL SIG RRs for TTL count down and automatic deletion of RRs. This document is an attempt to focus the alternative and get some experience with this approach before the DNSsec goes from Proposed to Draft. At that stage, if the NULL SIG RR has achieved enough deployment and no problems with its use are found, it may be retained. On the other hand, if it does not get used, or has problems, it can be dropped and the slack taken up by the RR described here. There are some proponents of this option who would like to see this RR even if the NULL SIG is retained. If the DNSsec goes forward with support behind the NULL SIG, but there is nonetheless support (in terms of implementation and deployment experience) for the EXP RR, it can go forward independantly. [[[I think more should be said, but that's about all I'm good for at this time. If others want to try their hand at inroductory and justification text, I'd be happy to incorporate it...]]] 1. definition of the RR type The Expires RR is defined with mnemonic "EXP" and TYPE code [[[TBD]]] (decimal). The format is based slightly on the format used for the SIG RR in the DNS Security Extensions[1] The format of an Expires (EXP) RR is: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE = EXP | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS = IN | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | COVERS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TIME | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: * NAME: an owner name, i.e., the name of the DNS node to which this resource record pertains. This is encoded as described in RFC1035 sections 3.1 and 4.1.4 and may be any number of octets. * TYPE: two octets containing the EXP RR TYPE code of 31 (decimal). * CLASS: two octets containing the RR IN CLASS code of 1. * TTL: a 32 bit signed integer that specifies the time interval in seconds that the resource record may be cached before the source of the information should again be consulted. * RDLENGTH: 6 * COVERS: is the type code of the RR set that it covers or 255 to indicate that it applies to all RRs of the same name and class. This is a subset of the QTYPE defined in RFC1035. * TIME: The date and time that the referenced RRs are due to expire, represented as an unsigned number of seconds since the start of 1 January 1970, GMT, ignoring leap seconds. [[[It's been suggested to add an "Effective on" time or function. If that's desired by anyone, my temptation is to make it separate. For this to be useful, it (and EXP) would really need to apply to specific RRs rather than a whole RR set. This makes it hard. For all these reasons, I will leave it out, unless someone comes up with a compelling reason for it, AND a good design for how to do it. My inclination is that this should be done with something like adding an EXP, then at the "effective time" doing a DYNDNS update removing the EXP and the RRs it covers and adding the new ones. This probably requires that the expired RRs appear to be there whether they've expired or not for the purposes of update, but they may not be visible to queries, can we make this reasonable.]]] 2. Master File Format The format of EXP RRs follows all the rules of RFC 1035, Section 5, "Master Files." Example master file (based on the example in RFC1035): @ IN SOA VENERA Action.domains ( 20 ; SERIAL 7200 ; REFRESH 600 ; RETRY 3600000; EXPIRE 60) ; MINIMUM NS A.ISI.EDU. NS VENERA NS VAXA MX 10 VENERA MX 20 VAXA ; address record for host A is good until 8am, 1 Jan 1996 A A 26.3.0.103 EXP A 19960101080000 VENERA A 10.1.0.52 A 128.9.0.32 ; all address records for host VENERA are good until midnight, 31 May 1996 EXP A 19960531000000 ; no expiration for VAXA's addresses VAXA A 10.2.0.27 A 128.9.0.33 3. Handling of Expires RRs and RRS covered by them When an authoritative server [[[is this limitation good? bad? other?]]] returns any RR covered by an Expires RR, it must assure that the TTL is small enough that copies will not be cached beyond the given expiration time. Although the server does not need to actually remove expired RRs from its database, it must give the appearance of having done so when formulating replies to query or transfer requests. A simple algorithm for skipping over expired RRs or adjusting their TTL to match an expiration time is shown below: if expire > now { if (expire - now) > TTL { TTL = (expire - now) } include RR in reply } This algorithm makes the TTL just small enough to satisfy the EXP requirements. Some people have suggested more elaborate techniques to reduce the inherent inconsistencies introduced. Such an algorithm might be to use a two day TTL when the change is more than a week away, but a week ahead, start lowering the TTL such that 3 days before the change only 1 day TTLs are given out, and a day in advance it's down to a few hours, and a few hours in advance it's down to 30 minutes. The usefulness of this more gradual approach has been debated [[[do I have any references on this discussion???]]], but in any case it is a local matter as long as the TTL does not exceed that given by the simple algorithm above. 4. Additional Section Processing [[[Do we need this?]]] [[[Maybe suggest including them when they apply? Probably not useful.]]] 5. Acknowledgements The original arguments for this as a separate RR were put forward by Robert Elz in the DNSIND Working Group. Many others described uses and requirements that were the basis of this design. Comments and some explanatory text from Walt Lazear were helpful. I'd also like to thank Arnt Gulbrandsen for his collected list of DNS RFCs and permission to use it as the basis for the References section and Bill Manning, the author of RFC1348[4], for unwittingly supplying the boilerplate and diagrams I used as a basis for this document. Much of the layout of the RR was based on the work of Donald Eastlake and Charles Kaufman in the design of the DNS Security Extensions. 6. Security Considerations Security issues are not [[[yet]]] discussed in this memo. [[[Should any be???]]] [[[ EXP allows add permission to be turned into delete permission]]] [[[ interaction with DNSSEC, which has a different variant of expiration, and with secure update[TBD]. ]]] 7. References [1] DNSsec draft [[[fill in details]]] [2] IXFR draft [[[fill in details]]] [3] RFC 1536: A. Kumar, J. Postel, C. Neuman, P. Danzig, S. Miller, "Common DNS Implementation Errors and Suggested Fixes.", 10/06/1993. [4] RFC 1348: B. Manning, "DNS NSAP RRs", 07/01/1992. [5] RFC 1183: R. Ullman, P. Mockapetris, L. Mamakos, C. Everhart, "New DNS RR Definitions", 10/08/1990. [6] RFC 1101: P. Mockapetris, "DNS encoding of network names and other types", 04/01/1989. [7] RFC 1035: P. Mockapetris, "Domain names - implementation and specification", 11/01/1987. [8] RFC 1034: P. Mockapetris, "Domain names - concepts and facilities", 11/01/1987. [9] RFC 1033: M. Lottor, "Domain administrators operations guide", 11/01/1987. [10] RFC 1032: M. Stahl, "Domain administrators guide", 11/01/1987. [11] RFC 974: C. Partridge, "Mail routing and the domain system", 01/01/1986. 8. Authors' Address: Michael A. Patton Bolt Beranek and Newman 10 Moulton Street Cambridge, MA, 02138 Phone: (617) 873 2737 FAX: (617) 873 3457 Email: map@bbn.com This Internet Draft expires July 1996