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

Versions: 00 01 02 03 04 05 06 RFC 2540

INTERNET-DRAFT                                    Donald E. Eastlake 3rd
                                                         CyberCash, Inc.
Expires July 1998                                           January 1998




             Detached Domain Name System (DNS) Information
             -------- ------ ---- ------ ----- -----------

                         Donald E. Eastlake 3rd



Status of This Document

   This draft, file name draft-ietf-dnssec-ddi-03.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
   months.  Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``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 (East USA), ftp.isi.edu (West USA),
   nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
   munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).


















Donald E. Eastlake 3rd                                          [Page 1]


INTERNET-DRAFT          Detached DNS Information            January 1998


Abstract

   A standard format is defined for representing detached DNS
   information.  This is anticipated to be of use for storing
   information retrieved from the Domain Name System (DNS), including
   security information, in archival contexts or contexts not connected
   to the Internet.



Table of Contents

      Status of This Document....................................1

      Abstract...................................................2
      Table of Contents..........................................2

      1. Introduction............................................3

      2. General Format..........................................4
      2.1 Binary Format..........................................4
      2.2. Text Format...........................................6

      3. Usage Example...........................................7
      4. Security Considerations.................................7

      References.................................................8
      Author's Address...........................................8
      Expiration and File Name...................................8























Donald E. Eastlake 3rd                                          [Page 2]


INTERNET-DRAFT          Detached DNS Information            January 1998


1. Introduction

   The Domain Name System (DNS) is a replicated hierarchical distributed
   database system [RFC 1034, 1035] that can provide highly available
   service.  It provides the operational basis for Internet host name to
   address translation, automatic SMTP mail routing, and other basic
   Internet functions.  The DNS has recently been extended as described
   in [RFC 2065] to permit the general storage of public cryptographic
   keys in the DNS and to enable the authentication of information
   retrieved from the DNS though digital signatures.

   The DNS was not originally designed for storage of information
   outside of the active zones and authoritative master files that are
   part of the connected DNS.  However there may be cases where this is
   useful, particularly in connection with security information.





































Donald E. Eastlake 3rd                                          [Page 3]


INTERNET-DRAFT          Detached DNS Information            January 1998


2. General Format

   The formats used for detached Domain Name System (DNS) information
   are similar to those used for connected DNS information. The primary
   difference is that elements of the connected DNS system (unless they
   are an authoritative server for the zone containing the information)
   are required to count down the Time To Live (TTL) associated with
   each DNS Resource Record (RR) and discard them (possibly fetching a
   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
   updated, and perhaps used to authenticate historic data or it might
   be received via non-DNS protocols long after it was retrieved from
   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
   point where the TTL (which is defined as an unsigned field) would
   underflow.  To preserve information as to the freshness of this
   detached data, it is accompanied by its retrieval time.

   Whatever retrieves the information from the DNS must associate this
   retrieval time with it.  The retrieval time remains fixed thereafter.
   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
   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
   also has an expiration time.  Regardless of the TTL, it and any RRs
   it signs can not be considered authenticated after the signature
   expiration time.



2.1 Binary Format

   The standard binary format for detached DNS information is as
   follows:


















Donald E. Eastlake 3rd                                          [Page 4]


INTERNET-DRAFT          Detached DNS Information            January 1998


                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      first retrieval time                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          RR count             |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Resource Records (RRs)    |
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |                       next retrieval time                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          RR count             |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Resource Records (RRs)    |
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                              ...                              /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     hex 80    |
   +-+-+-+-+-+-+-+-+

   Retrieval time - the time that the immediately following information
      was obtained from the connected DNS system.  It is an unsigned
      number of seconds since the start of 1 January 1970, GMT, ignoring
      leap seconds, in network (big-endian) order.  Note that this time
      can not be before the initial proposal of this standard.
      Therefore, the initial byte of an actual retrieval time,
      considered as an unsigned quantity, will be larger than 80 hex.
      The end of detached DNS information is indicated by a "retrieval
      time" field initial byte equal to 80 hex.  Use of a "retrieval
      time" field with a leading zero bit in binary detached DNS
      information is reserved for future use.  It may indicate a
      different format. Retrieval times will not generally be 32 bit
      aligned with respect to each other due to the variable length
      nature of RRs.

   RR count - an unsigned integer number (with bytes in network order)
      of following resource records retrieved at the preceding retrieval
      time.

   Resource Records - the actual data which is in the same format as if
      it were being transmitted in a DNS response.  In particular, name
      compression via pointers is permitted with the origin at the
      beginning of the particular detached information data section,
      just after the RR count.








Donald E. Eastlake 3rd                                          [Page 5]


INTERNET-DRAFT          Detached DNS Information            January 1998


2.2. Text Format

   The standard text format for detached DNS information is as
   prescribed for zone master files [RFC 1035] except that the $INCLUDE
   control entry is prohibited and the new $DATE entry is required
   (unless the information set is empty). $DATE is followed  by the date
   and time that the following information was obtained from the DNS
   system as described for retrieval time in section 2.1 above.  It is
   in the text format YYYYMMDDHHMMSS where YYYY is the year, the first
   MM 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 (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 detached information.






































Donald E. Eastlake 3rd                                          [Page 6]


INTERNET-DRAFT          Detached DNS Information            January 1998


3. Usage Example

   A document might be authenticated by a key retrieved from the DNS in
   a KEY resource record (RR).  To later prove the authenticity of this
   document, it would be desirable to preserve the KEY RR for that
   public key, the SIG RR signing that KEY RR, the KEY RR for the key
   used to authenticate that SIG, and so on through SIG and KEY RRs
   until a well known trusted key is reached, perhaps the key for the
   DNS root or some third party authentication service.  (In some cases
   these KEY RRs will actually be sets of KEY RRs with the same owner
   and class because SIGs actually sign such record sets.)

   This information could be preserved as a set of detached DNS
   information blocks.




4. Security Considerations

   The entirety of this document concerns a means to represent detached
   DNS information.  Such detached resource records may be security
   relevant and/or secured information as described in RFC 2065.  The
   detached format provides no overall security for sets of detached
   information or for the association between retrieval time and
   information.  This can be provided by wrapping the detached
   information format with some other form of signature.  However, if
   the detached information is accompanied by SIG RRs, its validity
   period is indicated in those SIG RRs so the retrieval time might be
   of secondary importance.






















Donald E. Eastlake 3rd                                          [Page 7]


INTERNET-DRAFT          Detached DNS Information            January 1998


References

   [RFC 1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
   November 1987.

   [RFC 1035] - Domain Names - Implementation and Specifications, P.
   Mockapetris, November 1987.

   [RFC 2065] - Domain Name System Security Extensions, D. Eastlake, C.
   Kaufman, January 1997.




Author's Address

   Donald E. Eastlake 3rd
   CyberCash, Inc.
   318 Acton Street
   Carlisle, MA 01741 USA

   Telephone:   +1 978 287 4877
                +1 703 620 4200 (main office, Reston, Virginia)
   Fax:         +1 978 371 7148
   EMail:       dee@cybercash.com



Expiration and File Name

   This draft expires July 1998.

   Its file name is draft-ietf-dnssec-ddi-03.txt.



















Donald E. Eastlake 3rd                                          [Page 8]


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