[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

INTERNET DRAFT                                               M. A. Patton
Expiration Date: July 1996                                            BBN
<draft-ietf-dnsind-expires-00.txt>                          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
        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").


   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]).


   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                      |
           |                                               |


   *  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
           EXP     A       19960101080000

   ; all address records for  host VENERA are good until midnight, 31 May 1996
           EXP     A       19960531000000

   ; no expiration for VAXA's addresses
   VAXA    A

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
   [[[ 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.",

   [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",

   [10]  RFC 1032: M. Stahl, "Domain administrators guide", 11/01/1987.

   [11]  RFC 974: C. Partridge, "Mail routing and the domain system",

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

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/