INTERNET-DRAFT The Kitchen Sink Resource Record April 1997 Expires October 1997 The Kitchen Sink Resource Record --- ------- ---- -------- ------ Donald E. Eastlake 3rd Status of This Document This draft, file name draft-eastlake-kitchen-sink-02.txt, is intended to be become a Proposed Standard RFC. Distribution of this document is unlimited. Comments should be sent to 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 persons have improved this document and they are gratefully acknowledged: Rob Austein Johnny Eriksson Michael A. Patton 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..............................7 4. Performance Considerations..............................7 5. Security Considerations.................................7 References.................................................8 Author's Address...........................................9 Expiration and File Name...................................9 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, 2065] 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 . 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 not 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.* 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 - CER ( Canonical Encoding Rules ). 6-253 - available for IANA assignment to future OSI encoding Donald E. Eastlake 3rd [Page 4] INTERNET-DRAFT The Kitchen Sink Resource Record rules. 254 - private. This subcoding will never be assigned to a 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 compressed via pointers as in DNS replies. The origin for the pointers is the beginning of the RDATA section of the SINK RR. Thus the SINK RR is safe to cache since only code that knows how to parse the data portion need know of and can expand these compressions. 65 - MIME structured data [RFC 2045, 2046]. 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 - 253 - available for assignment to future content transfer encodings. 254 - 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. 255 - reserved. 66 - Text tagged data. The data potion consists of text formated as specified in the TXT RR except that the first and every subsequent odd numbered text item is considered to be a tag labeling the immediately following text item. If there are an odd number of text items overall, then the last is considered to label a null text item. Syntax of the tags is as specified in RFC 1738 for the "Common Internet Scheme Syntax" without the two leading slashes ("//"). Thus any organization with a domain name can assign tags without fear of conflict. Donald E. Eastlake 3rd [Page 5] INTERNET-DRAFT The Kitchen Sink Resource Record - The subcodings byte specifies the encoding of the labeled text items as follows: TEXT SUBCODINGS 0 - reserved. 1 - ASCII. 2 - UTF-7 [RFC 1642]. 3 - UTF-8 [RFC 2044]. 4 - ASCII with MIME header escapes [RFC 2047]. 5 - 253 - available for assignment to future text encodings. 254 - private. Each text item must start with a domain name [RFC 1034] denoting the private text encoding immediately followed by one null (zero) octet followed by the remainder of the text item. 255 - reserved. 67-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 6] 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 2045] 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 also required to support the DNS KEY and SIG security RRs [RFC 2065] 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 or very large. Due care should be taken. RFC 2065 covers data original authentication of the data in the domain name system including SINK RRs. Donald E. Eastlake 3rd [Page 7] 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.. [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 1642] - D. Goldsmith, M. Davis, "UTF-7 - A Mail-Safe Transformation Format of Unicode", 07/13/1994. [RFC 1738] - T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource Locators (URL)", 12/20/1994. [RFC 2044] - F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 10646", 10/30/1996. [RFC 2045] - N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", 12/02/1996. [RFC 2046] - N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", 12/02/1996. [RFC 2047] - K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", 12/02/1996. [RFC 2065] - D. Eastlake, C. Kaufman, "Domain Name System Security Extensions", 01/03/1997. Donald E. Eastlake 3rd [Page 8] INTERNET-DRAFT The Kitchen Sink Resource Record 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 October 1997. Its file name is draft-eastlake-kitchen-sink-02.txt. Donald E. Eastlake 3rd [Page 9]