diff options
Diffstat (limited to 'doc/rfc/rfc2540.txt')
| -rw-r--r-- | doc/rfc/rfc2540.txt | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc2540.txt b/doc/rfc/rfc2540.txt new file mode 100644 index 0000000..6314806 --- /dev/null +++ b/doc/rfc/rfc2540.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group D. Eastlake +Request for Comments: 2540 IBM +Category: Experimental March 1999 + + + Detached Domain Name System (DNS) Information + +Status 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...................................................1 + 1. Introduction............................................1 + 2. General Format..........................................2 + 2.1 Binary Format..........................................3 + 2.2. Text Format...........................................4 + 3. Usage Example...........................................4 + 4. IANA Considerations.....................................4 + 5. Security Considerations.................................4 + References.................................................5 + Author's Address...........................................5 + Full Copyright Statement...................................6 + +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 been extended as described in [RFC + 2535] to permit the general storage of public cryptographic keys in + + + +Eastlake 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 1999 + + +2.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 (see section 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 in section 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 detached + + + +Eastlake 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.com + + + + + + + + + + + + + + + + + + + + + + +Eastlake Experimental [Page 5] + +RFC 2540 Detached DNS Information March 1999 + + +Full 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] + |