draft-ietf-dnssec-ddi-06.txt   rfc2540.txt 
INTERNET-DRAFT Donald E. Eastlake 3rd Network Working Group D. Eastlake
IBM Request for Comments: 2540 IBM
Expires April 1999 October 1998 Category: Experimental March 1999
Detached Domain Name System (DNS) Information Detached Domain Name System (DNS) Information
-------- ------ ---- ------ ----- -----------
Donald E. Eastlake 3rd Status of this Memo
Status of This Document
This draft, file name draft-ietf-dnssec-ddi-06.txt, is intended to be
become a Proposed Standard RFC. Distribution of this document is
unlimited. Comments should be sent to the DNS Security Working Group
mailing list <dns-security@tis.com> or to the author.
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 This memo defines an Experimental Protocol for the Internet
months. Internet-Drafts may be updated, replaced, or obsoleted by community. It does not specify an Internet standard of any kind.
other documents at any time. It is not appropriate to use Internet- Discussion and suggestions for improvement are requested.
Drafts as reference material or to cite them other than as a Distribution of this memo is unlimited.
``working draft'' or ``work in progress.''
To view the entire list of current Internet-Drafts, please check the Copyright Notice
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
[Changes from last draft: change date, update author info, define 64 Copyright (C) The Internet Society (1999). All Rights Reserved.
bit retrieval time format to avoid year 2106 problem, permit text
data format to have more than four digits of year, add IANA
Considerations section]
Abstract Abstract
A standard format is defined for representing detached DNS A standard format is defined for representing detached DNS
information. This is anticipated to be of use for storing information. This is anticipated to be of use for storing
information retrieved from the Domain Name System (DNS), including information retrieved from the Domain Name System (DNS), including
security information, in archival contexts or contexts not connected security information, in archival contexts or contexts not connected
to the Internet. to the Internet.
Table of Contents Table of Contents
Status of This Document....................................1 Abstract...................................................1
1. Introduction............................................1
Abstract...................................................2 2. General Format..........................................2
Table of Contents..........................................2 2.1 Binary Format..........................................3
2.2. Text Format...........................................4
1. Introduction............................................3 3. Usage Example...........................................4
2. General Format..........................................3 4. IANA Considerations.....................................4
2.1 Binary Format..........................................4 5. Security Considerations.................................4
2.2. Text Format...........................................5 References.................................................5
3. Usage Example...........................................5 Author's Address...........................................5
4. IANA Considerations.....................................5 Full Copyright Statement...................................6
5. Security Considerations.................................6
References.................................................7
Author's Address...........................................7
Expiration and File Name...................................7
1. Introduction 1. Introduction
The Domain Name System (DNS) is a replicated hierarchical distributed The Domain Name System (DNS) is a replicated hierarchical distributed
database system [RFC 1034, 1035] that can provide highly available database system [RFC 1034, 1035] that can provide highly available
service. It provides the operational basis for Internet host name to service. It provides the operational basis for Internet host name to
address translation, automatic SMTP mail routing, and other basic address translation, automatic SMTP mail routing, and other basic
Internet functions. The DNS has been extended as described in Internet functions. The DNS has been extended as described in [RFC
[draft-ietf-dnssec-secext2-*.txt] to permit the general storage of 2535] to permit the general storage of public cryptographic keys in
public cryptographic keys in the DNS and to enable the authentication the DNS and to enable the authentication of information retrieved
of information retrieved from the DNS though digital signatures. from the DNS though digital signatures.
The DNS was not originally designed for storage of information The DNS was not originally designed for storage of information
outside of the active zones and authoritative master files that are outside of the active zones and authoritative master files that are
part of the connected DNS. However there may be cases where this is part of the connected DNS. However there may be cases where this is
useful, particularly in connection with archived security useful, particularly in connection with archived security
information. information.
2. General Format 2. General Format
The formats used for detached Domain Name System (DNS) information The formats used for detached Domain Name System (DNS) information
are similar to those used for connected DNS information. The primary are similar to those used for connected DNS information. The primary
difference is that elements of the connected DNS system (unless they difference is that elements of the connected DNS system (unless they
are an authoritative server for the zone containing the information) are an authoritative server for the zone containing the information)
are required to count down the Time To Live (TTL) associated with are required to count down the Time To Live (TTL) associated with
each DNS Resource Record (RR) and discard them (possibly fetching a each DNS Resource Record (RR) and discard them (possibly fetching a
fresh copy) when the TTL reaches zero. In contrast to this, detached fresh copy) when the TTL reaches zero. In contrast to this, detached
information may be stored in a off-line file, where it can not be information may be stored in a off-line file, where it can not be
updated, and perhaps used to authenticate historic data or it might updated, and perhaps used to authenticate historic data or it might
be received via non-DNS protocols long after it was retrieved from be received via non-DNS protocols long after it was retrieved from
the DNS. Therefore, it is not practical to count down detached DNS the DNS. Therefore, it is not practical to count down detached DNS
information TTL and it may be necessary to keep the data beyond the information TTL and it may be necessary to keep the data beyond the
point where the TTL (which is defined as an unsigned field) would point where the TTL (which is defined as an unsigned field) would
underflow. To preserve information as to the freshness of this underflow. To preserve information as to the freshness of this
detached data, it is accompanied by its retrieval time. detached data, it is accompanied by its retrieval time.
Whatever retrieves the information from the DNS must associate this Whatever retrieves the information from the DNS must associate this
retrieval time with it. The retrieval time remains fixed thereafter. retrieval time with it. The retrieval time remains fixed thereafter.
When the current time minus the retrieval time exceeds the TTL for When the current time minus the retrieval time exceeds the TTL for
any particular detached RR, it is no longer a valid copy within the any particular detached RR, it is no longer a valid copy within the
normal connected DNS scheme. This may make it invalid in context for normal connected DNS scheme. This may make it invalid in context for
some detached purposes as well. If the RR is a SIG (signature) RR it some detached purposes as well. If the RR is a SIG (signature) RR it
also has an expiration time. Regardless of the TTL, it and any RRs also has an expiration time. Regardless of the TTL, it and any RRs
it signs can not be considered authenticated after the signature it signs can not be considered authenticated after the signature
expiration time. expiration time.
2.1 Binary Format 2.1 Binary Format
The standard binary format for detached DNS information is as The standard binary format for detached DNS information is as
follows: follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| first retrieval time | | first retrieval time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR count | | | RR count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource Records (RRs) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource Records (RRs) |
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| next retrieval time | | next retrieval time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR count | | | RR count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource Records (RRs) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource Records (RRs) |
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... / / ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hex 20 | | hex 20 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Retrieval time - the time that the immediately following information Retrieval time - the time that the immediately following information
was obtained from the connected DNS system. It is an unsigned was obtained from the connected DNS system. It is an unsigned
number of seconds since the start of 1 January 1970, GMT, ignoring number of seconds since the start of 1 January 1970, GMT,
leap seconds, in network (big-endian) order. Note that this time ignoring leap seconds, in network (big-endian) order. Note that
can not be before the initial proposal of this standard. this time can not be before the initial proposal of this
Therefore, the initial byte of an actual retrieval time, standard. Therefore, the initial byte of an actual retrieval
considered as a 32 bit unsigned quantity, would always be larger time, considered as a 32 bit unsigned quantity, would always be
than 20 hex. The end of detached DNS information is indicated by larger than 20 hex. The end of detached DNS information is
a "retrieval time" field initial byte equal to 0x20. Use of a indicated by a "retrieval time" field initial byte equal to 0x20.
"retrieval time" field with a leading unsigned byte of zero Use of a "retrieval time" field with a leading unsigned byte of
indicates a 64 bit (actually 8 leading zero bits plus a 56 bit zero indicates a 64 bit (actually 8 leading zero bits plus a 56
quantity). This 64 bit format will be required when retrieval bit quantity). This 64 bit format will be required when
time is larger than 0xFFFFFFFF, which is some time in the year retrieval time is larger than 0xFFFFFFFF, which is some time in
2106. The meaning of retrieval times with an initial byte between the year 2106. The meaning of retrieval times with an initial
0x01 and 0x1F is reserved (see section 5). Retrieval times will byte between 0x01 and 0x1F is reserved (see section 5).
not generally be 32 bit aligned with respect to each other due to Retrieval times will not generally be 32 bit aligned with respect
the variable length nature of RRs. to each other due to the variable length nature of RRs.
RR count - an unsigned integer number (with bytes in network order) RR count - an unsigned integer number (with bytes in network order)
of following resource records retrieved at the preceding retrieval of following resource records retrieved at the preceding
time. retrieval time.
Resource Records - the actual data which is in the same format as if Resource Records - the actual data which is in the same format as if
it were being transmitted in a DNS response. In particular, name it were being transmitted in a DNS response. In particular, name
compression via pointers is permitted with the origin at the compression via pointers is permitted with the origin at the
beginning of the particular detached information data section, beginning of the particular detached information data section,
just after the RR count. just after the RR count.
2.2. Text Format 2.2. Text Format
The standard text format for detached DNS information is as The standard text format for detached DNS information is as
prescribed for zone master files [RFC 1035] except that the $INCLUDE prescribed for zone master files [RFC 1035] except that the $INCLUDE
control entry is prohibited and the new $DATE entry is required control entry is prohibited and the new $DATE entry is required
(unless the information set is empty). $DATE is followed by the date (unless the information set is empty). $DATE is followed by the date
and time that the following information was obtained from the DNS and time that the following information was obtained from the DNS
system as described for retrieval time in section 2.1 above. It is system as described for retrieval time in section 2.1 above. It is
in the text format YYYYMMDDHHMMSS where YYYY is the year (which may in the text format YYYYMMDDHHMMSS where YYYY is the year (which may
be more than four digits to cover years after 9999), the first MM is be more than four digits to cover years after 9999), the first MM is
the month number (01-12), DD is the day of the month (01-31), HH is the month number (01-12), DD is the day of the month (01-31), HH is
the hour in 24 hours notation (00-23), the second MM is the minute the hour in 24 hours notation (00-23), the second MM is the minute
(00-59), and SS is the second (00-59). Thus a $DATE must appear (00-59), and SS is the second (00-59). Thus a $DATE must appear
before the first RR and at every change in retrieval time through the before the first RR and at every change in retrieval time through the
detached information. detached information.
skipping to change at page 6, line 9 skipping to change at page 4, line 51
4. IANA Considerations 4. IANA Considerations
Allocation of meanings to retrieval time fields with a initial byte Allocation of meanings to retrieval time fields with a initial byte
of between 0x01 and 0x1F requires an IETF consensus. of between 0x01 and 0x1F requires an IETF consensus.
5. Security Considerations 5. Security Considerations
The entirety of this document concerns a means to represent detached The entirety of this document concerns a means to represent detached
DNS information. Such detached resource records may be security DNS information. Such detached resource records may be security
relevant and/or secured information as described in [draft-ietf- relevant and/or secured information as described in [RFC 2535]. The
dnssec-secext2-*.txt]. The detached format provides no overall detached format provides no overall security for sets of detached
security for sets of detached information or for the association information or for the association between retrieval time and
between retrieval time and information. This can be provided by information. This can be provided by wrapping the detached
wrapping the detached information format with some other form of information format with some other form of signature. However, if
signature. However, if the detached information is accompanied by the detached information is accompanied by SIG RRs, its validity
SIG RRs, its validity period is indicated in those SIG RRs so the period is indicated in those SIG RRs so the retrieval time might be
retrieval time might be of secondary importance. of secondary importance.
References References
[RFC 1034] - Domain Names - Concepts and Facilities, P. Mockapetris, [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
November 1987. Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] - Domain Names - Implementation and Specifications, P. [RFC 1035] Mockapetris, P., " Domain Names - Implementation and
Mockapetris, November 1987. Specifications", STD 13, RFC 1035, November 1987.
[draft-ietf-dnssec-secext2-*.txt] - Domain Name System Security [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
Extensions, Donald Eastlake 3rd. RFC 2535, March 1999.
Author's Address Author's Address
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
IBM IBM
318 Acton Street 65 Shindegan Hill Road, RR #1
Carlisle, MA 01741 USA Carmel, NY 10512
Telephone: +1-978-287-4877 Phone: +1-914-276-2668(h)
+1-914-784-7913 +1-914-784-7913(w)
Fax: +1-978-371-7148 Fax: +1-914-784-3833(w)
email: dee3@us.ibm.com EMail: dee3@us.ibm.com
Expiration and File Name Full Copyright Statement
This draft expires April 1999. Copyright (C) The Internet Society (1999). All Rights Reserved.
Its file name is draft-ietf-dnssec-ddi-06.txt. This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 23 change blocks. 
116 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/