contrib/bind9/doc/rfc/rfc2540.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        D. Eastlake
   8 Request for Comments: 2540                                           IBM
   9 Category: Experimental                                        March 1999
  10
  11
  12              Detached Domain Name System (DNS) Information
  13
  14 Status of this Memo
  15
  16    This memo defines an Experimental Protocol for the Internet
  17    community.  It does not specify an Internet standard of any kind.
  18    Discussion and suggestions for improvement are requested.
  19    Distribution of this memo is unlimited.
  20
  21 Copyright Notice
  22
  23    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  24
  25 Abstract
  26
  27    A standard format is defined for representing detached DNS
  28    information.  This is anticipated to be of use for storing
  29    information retrieved from the Domain Name System (DNS), including
  30    security information, in archival contexts or contexts not connected
  31    to the Internet.
  32
  33 Table of Contents
  34
  35    Abstract...................................................1
  36    1. Introduction............................................1
  37    2. General Format..........................................2
  38    2.1 Binary Format..........................................3
  39    2.2. Text Format...........................................4
  40    3. Usage Example...........................................4
  41    4. IANA Considerations.....................................4
  42    5. Security Considerations.................................4
  43    References.................................................5
  44    Author's Address...........................................5
  45    Full Copyright Statement...................................6
  46
  47 1. Introduction
  48
  49    The Domain Name System (DNS) is a replicated hierarchical distributed
  50    database system [RFC 1034, 1035] that can provide highly available
  51    service.  It provides the operational basis for Internet host name to
  52    address translation, automatic SMTP mail routing, and other basic
  53    Internet functions.  The DNS has been extended as described in [RFC
  54    2535] to permit the general storage of public cryptographic keys in
  55
  56
  57
  58 Eastlake                      Experimental                      [Page 1]
  59 \f
  60 RFC 2540                Detached DNS Information              March 1999
  61
  62
  63    the DNS and to enable the authentication of information retrieved
  64    from the DNS though digital signatures.
  65
  66    The DNS was not originally designed for storage of information
  67    outside of the active zones and authoritative master files that are
  68    part of the connected DNS.  However there may be cases where this is
  69    useful, particularly in connection with archived security
  70    information.
  71
  72 2. General Format
  73
  74    The formats used for detached Domain Name System (DNS) information
  75    are similar to those used for connected DNS information. The primary
  76    difference is that elements of the connected DNS system (unless they
  77    are an authoritative server for the zone containing the information)
  78    are required to count down the Time To Live (TTL) associated with
  79    each DNS Resource Record (RR) and discard them (possibly fetching a
  80    fresh copy) when the TTL reaches zero.  In contrast to this, detached
  81    information may be stored in a off-line file, where it can not be
  82    updated, and perhaps used to authenticate historic data or it might
  83    be received via non-DNS protocols long after it was retrieved from
  84    the DNS.  Therefore, it is not practical to count down detached DNS
  85    information TTL and it may be necessary to keep the data beyond the
  86    point where the TTL (which is defined as an unsigned field) would
  87    underflow.  To preserve information as to the freshness of this
  88    detached data, it is accompanied by its retrieval time.
  89
  90    Whatever retrieves the information from the DNS must associate this
  91    retrieval time with it.  The retrieval time remains fixed thereafter.
  92    When the current time minus the retrieval time exceeds the TTL for
  93    any particular detached RR, it is no longer a valid copy within the
  94    normal connected DNS scheme.  This may make it invalid in context for
  95    some detached purposes as well.  If the RR is a SIG (signature) RR it
  96    also has an expiration time.  Regardless of the TTL, it and any RRs
  97    it signs can not be considered authenticated after the signature
  98    expiration time.
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Eastlake                      Experimental                      [Page 2]
 115 \f
 116 RFC 2540                Detached DNS Information              March 1999
 117
 118
 119 2.1 Binary Format
 120
 121    The standard binary format for detached DNS information is as
 122    follows:
 123
 124                          1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 125      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
 126     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 127     |                      first retrieval time                     |
 128     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 129     |          RR count             |                               |
 130     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Resource Records (RRs)    |
 131     /                                                               /
 132     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 133     |                       next retrieval time                     |
 134     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 135     |          RR count             |                               |
 136     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Resource Records (RRs)    |
 137     /                                                               /
 138     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 139     /                              ...                              /
 140     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 141     |     hex 20    |
 142     +-+-+-+-+-+-+-+-+
 143
 144    Retrieval time - the time that the immediately following information
 145        was obtained from the connected DNS system.  It is an unsigned
 146        number of seconds since the start of 1 January 1970, GMT,
 147        ignoring leap seconds, in network (big-endian) order.  Note that
 148        this time can not be before the initial proposal of this
 149        standard.  Therefore, the initial byte of an actual retrieval
 150        time, considered as a 32 bit unsigned quantity, would always be
 151        larger than 20 hex.  The end of detached DNS information is
 152        indicated by a "retrieval time" field initial byte equal to 0x20.
 153        Use of a "retrieval time" field with a leading unsigned byte of
 154        zero indicates a 64 bit (actually 8 leading zero bits plus a 56
 155        bit quantity).  This 64 bit format will be required when
 156        retrieval time is larger than 0xFFFFFFFF, which is some time in
 157        the year 2106.  The meaning of retrieval times with an initial
 158        byte between 0x01 and 0x1F is reserved (see section 5).
 159        Retrieval times will not generally be 32 bit aligned with respect
 160        to each other due to the variable length nature of RRs.
 161
 162    RR count - an unsigned integer number (with bytes in network order)
 163        of following resource records retrieved at the preceding
 164        retrieval time.
 165
 166
 167
 168
 169
 170 Eastlake                      Experimental                      [Page 3]
 171 \f
 172 RFC 2540                Detached DNS Information              March 1999
 173
 174
 175    Resource Records - the actual data which is in the same format as if
 176        it were being transmitted in a DNS response.  In particular, name
 177        compression via pointers is permitted with the origin at the
 178        beginning of the particular detached information data section,
 179        just after the RR count.
 180
 181 2.2. Text Format
 182
 183    The standard text format for detached DNS information is as
 184    prescribed for zone master files [RFC 1035] except that the $INCLUDE
 185    control entry is prohibited and the new $DATE entry is required
 186    (unless the information set is empty). $DATE is followed by the date
 187    and time that the following information was obtained from the DNS
 188    system as described for retrieval time in section 2.1 above.  It is
 189    in the text format YYYYMMDDHHMMSS where YYYY is the year (which may
 190    be more than four digits to cover years after 9999), the first MM is
 191    the month number (01-12), DD is the day of the month (01-31), HH is
 192    the hour in 24 hours notation (00-23), the second MM is the minute
 193    (00-59), and SS is the second (00-59).  Thus a $DATE must appear
 194    before the first RR and at every change in retrieval time through the
 195    detached information.
 196
 197 3. Usage Example
 198
 199    A document might be authenticated by a key retrieved from the DNS in
 200    a KEY resource record (RR).  To later prove the authenticity of this
 201    document, it would be desirable to preserve the KEY RR for that
 202    public key, the SIG RR signing that KEY RR, the KEY RR for the key
 203    used to authenticate that SIG, and so on through SIG and KEY RRs
 204    until a well known trusted key is reached, perhaps the key for the
 205    DNS root or some third party authentication service. (In some cases
 206    these KEY RRs will actually be sets of KEY RRs with the same owner
 207    and class because SIGs actually sign such record sets.)
 208
 209    This information could be preserved as a set of detached DNS
 210    information blocks.
 211
 212 4. IANA Considerations
 213
 214    Allocation of meanings to retrieval time fields with a initial byte
 215    of between 0x01 and 0x1F requires an IETF consensus.
 216
 217 5. Security Considerations
 218
 219    The entirety of this document concerns a means to represent detached
 220    DNS information.  Such detached resource records may be security
 221    relevant and/or secured information as described in [RFC 2535].  The
 222    detached format provides no overall security for sets of detached
 223
 224
 225
 226 Eastlake                      Experimental                      [Page 4]
 227 \f
 228 RFC 2540                Detached DNS Information              March 1999
 229
 230
 231    information or for the association between retrieval time and
 232    information.  This can be provided by wrapping the detached
 233    information format with some other form of signature.  However, if
 234    the detached information is accompanied by SIG RRs, its validity
 235    period is indicated in those SIG RRs so the retrieval time might be
 236    of secondary importance.
 237
 238 References
 239
 240    [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
 241                 Facilities", STD 13, RFC 1034, November 1987.
 242
 243    [RFC 1035]   Mockapetris, P., " Domain Names - Implementation and
 244                 Specifications", STD 13, RFC 1035, November 1987.
 245
 246    [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
 247                 RFC 2535, March 1999.
 248
 249 Author's Address
 250
 251    Donald E. Eastlake 3rd
 252    IBM
 253    65 Shindegan Hill Road, RR #1
 254    Carmel, NY 10512
 255
 256    Phone:   +1-914-276-2668(h)
 257             +1-914-784-7913(w)
 258    Fax:     +1-914-784-3833(w)
 259    EMail:   dee3@us.ibm.com
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Eastlake                      Experimental                      [Page 5]
 283 \f
 284 RFC 2540                Detached DNS Information              March 1999
 285
 286
 287 Full Copyright Statement
 288
 289    Copyright (C) The Internet Society (1999).  All Rights Reserved.
 290
 291    This document and translations of it may be copied and furnished to
 292    others, and derivative works that comment on or otherwise explain it
 293    or assist in its implementation may be prepared, copied, published
 294    and distributed, in whole or in part, without restriction of any
 295    kind, provided that the above copyright notice and this paragraph are
 296    included on all such copies and derivative works.  However, this
 297    document itself may not be modified in any way, such as by removing
 298    the copyright notice or references to the Internet Society or other
 299    Internet organizations, except as needed for the purpose of
 300    developing Internet standards in which case the procedures for
 301    copyrights defined in the Internet Standards process must be
 302    followed, or as required to translate it into languages other than
 303    English.
 304
 305    The limited permissions granted above are perpetual and will not be
 306    revoked by the Internet Society or its successors or assigns.
 307
 308    This document and the information contained herein is provided on an
 309    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 310    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 311    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 312    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 313    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Eastlake                      Experimental                      [Page 6]
 339 \f