INTERNET-DRAFT                          The Kitchen Sink Resource Record
                                                           November 1996
                                                        Expires May 1997




                    The Kitchen Sink Resource Record
                    --- ------- ---- -------- ------

                         Donald E. Eastlake 3rd



Status of This Document

   This draft, file name draft-eastlake-kitchen-sink-00.txt, is intended
   to be become an Experimental Standard RFC.  Distribution of this
   document is unlimited. Comments should be sent to
   <namedroppers@internic.net> 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).



Abstract

   Periodically people are seized with a desire to put complex, bulky,
   and/or obscurely structured data into the Domain Name System (DNS).
   This draft defines a kitchen sink Resource Record that will satisfy
   this lust by defining a new DNS resource record for the storage of
   miscellaneous structured information.








Donald E. Eastlake 3rd                                          [Page 1]


INTERNET-DRAFT                          The Kitchen Sink Resource Record


Acknowledgements

   The suggestions of the following person have improved this document
   and he is gratefully acknowledged:

        Rob Austein



Table of Contents

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

      Acknowledgements...........................................2
      Table of Contents..........................................2

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

      2. Kitchen Sink Resource Record............................4

      3. Master File Representation..............................6
      4. Performance Considerations..............................6
      5. Security Considerations.................................6

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
























Donald E. Eastlake 3rd                                          [Page 2]


INTERNET-DRAFT                          The Kitchen Sink Resource Record


1. Introduction

   The Domain Name System (DNS) provides a replicated distributed secure
   hierarchical database which stores "resource records" (RRs) under
   hierarchical domain names.  This data is structured into zones which
   are independently maintained.  [RFC 1034, 1035, draft-ietf-dnssec-
   secext-10.txt]

   Numerous types of RRs have been defined.  These support such critical
   functions as host name to address translation (A, AAAA, etc.  RRs),
   automatic mail routing (MX etc. RRs), and other functions. In
   addition, there are RRs defined related to the zone structure and
   administration of the DNS (SOA, NS, and RP RRs), security (SIG, KEY,
   and NXT RRs), etc.  There is a TXT RR for the inclusion of general
   human readable text.

   New RRs that are reasonably spartan and designed with some care are
   periodically added via the IETF standards process as new needs become
   apparent.  But there are periodically people who want to put some
   complex and frequently large structured data in the DNS.  They
   usually come up with some kludge way of reinterpreting the TXT RR,
   since that is one of the least constrained RR.  This is likely a bad
   idea since all previous kludge ways to reinterpreting the TXT RR have
   sunk without a trace.  (Well, if they actually got an RFC out, it's
   still there, but, practically speaking, nobody actually uses it.)

   If a new type of data is really needed for common use in the DNS, the
   best course is to design a new RR that efficiently meets the need
   through the IETF standards process.

   People who want to shoe-horn bulky or complex and obscurely
   structured data into the DNS, which may not appropriate there, don't
   want to hear that. This draft defines an extremely general and
   flexible RR which can be pointed out to such people.  It includes
   representations of OSI ASN.1, MIME, and, recursively, DNS RRs.

















Donald E. Eastlake 3rd                                          [Page 3]


INTERNET-DRAFT                          The Kitchen Sink Resource Record


2. Kitchen Sink Resource Record

   The symbol for the kitchen sink resource record is SINK.  Its type
   number is <TBA>.

   The RDATA portion of the SINK RR is structured as follows:

                                          1  1  1  1  1  1
            0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |         coding        |       subcoding       |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                                               /
          /                     data                      /
          /                                               /
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   The "coding" and "subcoding" octets are always present.  The "data"
   portion is variable length and could be null in some cases.  The size
   of the "data" portion can always be determined by subtracting 2 from
   the SINK resource record RDLENGTH.  The coding octet gives the
   general structure of the data.  The subcoding octet provides
   additional information depending on the value of the coding octet.

        INITIAL ASSIGNED CODING/SUBCODING OCTET VALUES

   CODING

   0 - reserved.

   1 - The SNMP subset of ASN.1.
   2 - OSI ASN.1 1990 [ASN.1].
   3 - OSI ASN.1 1994.
   4-62 - Reserved for IANA assignment for future versions of OSI ASN.*.
   63 - Private abstract syntax notations.  This coding value will never
        be assigned to a standard abstract syntax notation.  An OSI
        Object Identifier (OID) preceded by a one byte unsigned length
        appears at the beginning of the data area to indicate which
        private abstract syntax is being used.
      - For all ASN.1 codings, the subcoding indicates what encoding
        rules are in use as listed  below.
        ASN.* SUBCODINGS
        0 - reserved.
        1 - BER ( Basic Encoding Rules [BER]).
        2 - DER ( Distinguished Encoding Rules [DER]).
        3 - PER ( Packed Encoding Rules ) Aligned.
        4 - PER Unaligned.
        5-253 - available for IANA assignment to future OSI encoding
             rules.
        254 - private.  This subcoding will never be assigned to a


Donald E. Eastlake 3rd                                          [Page 4]


INTERNET-DRAFT                          The Kitchen Sink Resource Record


             standard set of encoding rules.  An OID preceded by a one
             byte unsigned length appears at the beginning of the data
             area to indicate which private encoding unless the coding
             is 63 (private) in which case the private subcoding OID
             appears in the data area just after the coding OID.
        255 - reserved.

   64 - DNS RRs. The data portion consists of DNS resource records as
        they would be transmitted in a DNS response section.  The
        subcoding octet is the number of RRs in the data area as an
        unsigned integer.  Domain names may be abbreviated via pointers
        as in DNS replies.  The origin for the pointers is the beginning
        of the RDATA section of the SINK RR.

   65 - MIME structured data [RFC 1521, 1522].  The data portion is a
        MIME structured message.  The "MIME-Version:" header line may be
        omitted unless the version is other than "1.0".  The top level
        Content-Transfer-Encoding may be encoded into the subcoding
        octet as indicated below.  Note that, to some extent, the size
        limitations of DNS RRs may be overcome in the MIME case by using
        the "Content-Type: message/external-body" mechanism.
        MIME SUBCODINGS
        0 - reserved.
        1 - 7bit.
        2 - 8bit.
        3 - binary.
        4 - quoted-printable.
        5 - base64.
        6 - private.  The data portion must start with an "x-" token
             denoting the private content-transfer-encoding immediately
             followed by one null (zero) octet followed by the remainder
             of the MIME object.
        7 - 254 - available for assignment to future content transfer
             encodings.  255 - reserved.

   66-253 - Available for general assignment to codings by IANA.

   254 - Private formats indicated by a URL.  This coding will never be
        assigned to a standard format.  The format of the data portion
        is indicated by an initial URL [RFC 1738] which is terminated by
        a zero valued octet followed by the data with that format.  The
        subcoding octet is available for whatever use the private
        formating wishes to make of it.  The manner in which the URL
        specifies the format is not defined but presumably the retriever
        will recognize the URL or the data it points to.

   255 - reserved.

   NOTE: the existence of a DNS RR coding and the infinite possibilities
   of ASN.*s and MIME permit nesting SINKs.


Donald E. Eastlake 3rd                                          [Page 5]


INTERNET-DRAFT                          The Kitchen Sink Resource Record


3. Master File Representation

   SINK resource records (RRs) may appear as lines in zone master files.
   The coding and subcoding appear as unsigned decimal integers.  The
   data portion can be quite long.  It is represented in base 64 [RFC
   1521] and may be divided up into any number of white space separated
   substrings, down to single base 64 digits, which are concatenated to
   obtain the full data.  These substrings can span lines using the
   standard parenthesis.  [This type of base64 master file data is
   required to support the DNS KEY and SIG security RRs in any case.]



4. Performance Considerations

   DNS is optimized for small data transfers, generally not exceeding
   512 bytes including overhead.  Larger transfers work correctly and
   efforts are underway to make them more efficient.

   It is easy to create very large RRs or RR sets using SINK.  DNS
   administrators should think carefully about this and may wish to
   discourage large RRs or RR sets.  Consideration should also be given
   to putting zones from which large RRs or RR sets will be commonly
   retrieved on separate hosts which can be tuned for the load this will
   represent.



5. Security Considerations

   Since the SINK resource record can be used to store arbitrary data in
   the DNS, this data could have security consequences, particularly if
   it is control, executable, macro, or interpretable information.  Due
   care should be taken.  draft-ietf-dnssec-secext-10.txt covers data
   original authentication of the data in the domain name system
   including SINK RRs.
















Donald E. Eastlake 3rd                                          [Page 6]


INTERNET-DRAFT                          The Kitchen Sink Resource Record


References

   [ASN.1] Abstract Syntax Notation One, C.C.I.T.T. X.208.

   [BER] Basic Encoding Rules for ASN.1, C.C.I.T.T. X.209.

   [DER] Distinguished Encoding Rules for ASN.1, ISO/IEC 8825-1 | ITU-T
   Rec. X.690..

   draft-ietf-dnssec-secext-10.txt

   [RFC 1034] - P. Mockapetris, "Domain names - concepts and
   facilities", 11/01/1987.

   [RFC 1035] - P. Mockapetris, "Domain names - implementation and
   specification", 11/01/1987.

   [RFC 1521] - N. Borenstein, N. Freed, "MIME  (Multipurpose Internet
   Mail Extensions) Part One:  Mechanisms for Specifying and Describing
   the Format of Internet Message Bodies", 09/23/1993.

   [RFC 1522] - K. Moore, "MIME (Multipurpose Internet Mail Extensions)
   Part Two: Message Header Extensions for Non-ASCII Text", 09/23/1993.

   [RFC 1738] - T. Berners-Lee, L. Masinter, M. McCahill, "Uniform
   Resource Locators (URL)", 12/20/1994.



Author's Address

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

   Telephone:   +1 508 287 4877
                +1 703 620-4200 (main office, Reston, VA)
   FAX:         +1 508 371 7148
   EMail:       dee@cybercash.com



Expiration and File Name

   This draft expires May 1997.

   Its file name is draft-eastlake-kitchen-sink-00.txt.




Donald E. Eastlake 3rd                                          [Page 7]