INTERNET-DRAFT The Kitchen Sink Resource Record
March 1997
Expires September 1997
The Kitchen Sink Resource Record
--- ------- ---- -------- ------
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-eastlake-kitchen-sink-01.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. [Since the last version,
tagged text items have been added and minor updates and changes for
consistency made.]
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 <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.* 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.
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT The Kitchen Sink Resource Record
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 parsing 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. Tags are encoded as specified in RFC
1738 for the "Common Internet Scheme Syntax" without the two
leading slashes ("//").
- The subcodings byte specifies the encoding of the labeled text
items as follows:
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT The Kitchen Sink Resource Record
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. The 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
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. 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 September 1997.
Its file name is draft-eastlake-kitchen-sink-01.txt.
Donald E. Eastlake 3rd [Page 9]
