One document matched: draft-ietf-dnsind-expires-00.txt
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
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
| PAFTECH AB 2003-2026 | 2026-04-23 11:30:28 |