Movatterモバイル変換

Network Working Group                                        D. EastlakeRequest for Comments: 2540                                           IBMCategory: Experimental                                        March 1999Detached Domain Name System (DNS) InformationStatus of this Memo   This memo defines an Experimental Protocol for the Internet   community.  It does not specify an Internet standard of any kind.   Discussion and suggestions for improvement are requested.   Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (1999).  All Rights Reserved.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   Abstract...................................................11. Introduction............................................12. General Format..........................................22.1 Binary Format..........................................32.2. Text Format...........................................43. Usage Example...........................................44. IANA Considerations.....................................45. Security Considerations.................................4   References.................................................5   Author's Address...........................................5   Full Copyright Statement...................................61. 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 been extended as described in [RFC   2535] to permit the general storage of public cryptographic keys inEastlake                      Experimental                      [Page 1]

RFC 2540                Detached DNS Information              March 1999   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 archived security   information.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.Eastlake                      Experimental                      [Page 2]

RFC 2540                Detached DNS Information              March 19992.1 Binary Format   The standard binary format for detached DNS information is as   follows:                         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 20    |    +-+-+-+-+-+-+-+-+   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 a 32 bit unsigned quantity, would always be       larger than 20 hex.  The end of detached DNS information is       indicated by a "retrieval time" field initial byte equal to 0x20.       Use of a "retrieval time" field with a leading unsigned byte of       zero indicates a 64 bit (actually 8 leading zero bits plus a 56       bit quantity).  This 64 bit format will be required when       retrieval time is larger than 0xFFFFFFFF, which is some time in       the year 2106.  The meaning of retrieval times with an initial       byte between 0x01 and 0x1F is reserved (seesection 5).       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.Eastlake                      Experimental                      [Page 3]

RFC 2540                Detached DNS Information              March 1999   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.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 insection 2.1 above.  It is   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   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.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. IANA Considerations   Allocation of meanings to retrieval time fields with a initial byte   of between 0x01 and 0x1F requires an IETF consensus.5. 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 2535].  The   detached format provides no overall security for sets of detachedEastlake                      Experimental                      [Page 4]

RFC 2540                Detached DNS Information              March 1999   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.References   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and                Facilities", STD 13,RFC 1034, November 1987.   [RFC 1035]   Mockapetris, P., " Domain Names - Implementation and                Specifications", STD 13,RFC 1035, November 1987.   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",RFC 2535, March 1999.Author's Address   Donald E. Eastlake 3rd   IBM   65 Shindegan Hill Road, RR #1   Carmel, NY 10512   Phone:   +1-914-276-2668(h)            +1-914-784-7913(w)   Fax:     +1-914-784-3833(w)   EMail:   dee3@us.ibm.comEastlake                      Experimental                      [Page 5]

RFC 2540                Detached DNS Information              March 1999Full Copyright Statement   Copyright (C) The Internet Society (1999).  All Rights Reserved.   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.Eastlake                      Experimental                      [Page 6]