idnits 2.17.1 draft-eastlake-kitchen-sink-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-eastlake-kitchen-sink-00.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-eastlake-kitchen-sink-00.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-eastlake-kitchen-sink-00.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-eastlake-kitchen-sink-00.txt,', but the file name used is 'draft-eastlake-kitchen-sink-00' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 145 has weird spacing: '... listed below...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 1997) is 9814 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1522' on line 169 == Unused Reference: 'RFC 1034' is defined on line 250, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 253, but no explicit reference was found in the text == Unused Reference: 'RFC 1522' is defined on line 260, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BER' -- Possible downref: Non-RFC (?) normative reference: ref. 'DER' ** Obsolete normative reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1522 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) Summary: 13 errors (**), 1 flaw (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT The Kitchen Sink Resource Record 2 November 1996 3 Expires May 1997 5 The Kitchen Sink Resource Record 6 --- ------- ---- -------- ------ 8 Donald E. Eastlake 3rd 10 Status of This Document 12 This draft, file name draft-eastlake-kitchen-sink-00.txt, is intended 13 to be become an Experimental Standard RFC. Distribution of this 14 document is unlimited. Comments should be sent to 15 or to the author. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months. Internet-Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet- 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 30 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 31 nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 32 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 34 Abstract 36 Periodically people are seized with a desire to put complex, bulky, 37 and/or obscurely structured data into the Domain Name System (DNS). 38 This draft defines a kitchen sink Resource Record that will satisfy 39 this lust by defining a new DNS resource record for the storage of 40 miscellaneous structured information. 42 Acknowledgements 44 The suggestions of the following person have improved this document 45 and he is gratefully acknowledged: 47 Rob Austein 49 Table of Contents 51 Status of This Document....................................1 52 Abstract...................................................1 54 Acknowledgements...........................................2 55 Table of Contents..........................................2 57 1. Introduction............................................3 59 2. Kitchen Sink Resource Record............................4 61 3. Master File Representation..............................6 62 4. Performance Considerations..............................6 63 5. Security Considerations.................................6 65 References.................................................7 66 Author's Address...........................................7 67 Expiration and File Name...................................7 69 1. Introduction 71 The Domain Name System (DNS) provides a replicated distributed secure 72 hierarchical database which stores "resource records" (RRs) under 73 hierarchical domain names. This data is structured into zones which 74 are independently maintained. [RFC 1034, 1035, draft-ietf-dnssec- 75 secext-10.txt] 77 Numerous types of RRs have been defined. These support such critical 78 functions as host name to address translation (A, AAAA, etc. RRs), 79 automatic mail routing (MX etc. RRs), and other functions. In 80 addition, there are RRs defined related to the zone structure and 81 administration of the DNS (SOA, NS, and RP RRs), security (SIG, KEY, 82 and NXT RRs), etc. There is a TXT RR for the inclusion of general 83 human readable text. 85 New RRs that are reasonably spartan and designed with some care are 86 periodically added via the IETF standards process as new needs become 87 apparent. But there are periodically people who want to put some 88 complex and frequently large structured data in the DNS. They 89 usually come up with some kludge way of reinterpreting the TXT RR, 90 since that is one of the least constrained RR. This is likely a bad 91 idea since all previous kludge ways to reinterpreting the TXT RR have 92 sunk without a trace. (Well, if they actually got an RFC out, it's 93 still there, but, practically speaking, nobody actually uses it.) 95 If a new type of data is really needed for common use in the DNS, the 96 best course is to design a new RR that efficiently meets the need 97 through the IETF standards process. 99 People who want to shoe-horn bulky or complex and obscurely 100 structured data into the DNS, which may not appropriate there, don't 101 want to hear that. This draft defines an extremely general and 102 flexible RR which can be pointed out to such people. It includes 103 representations of OSI ASN.1, MIME, and, recursively, DNS RRs. 105 2. Kitchen Sink Resource Record 107 The symbol for the kitchen sink resource record is SINK. Its type 108 number is . 110 The RDATA portion of the SINK RR is structured as follows: 112 1 1 1 1 1 1 113 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 114 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 115 | coding | subcoding | 116 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 117 | / 118 / data / 119 / / 120 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 122 The "coding" and "subcoding" octets are always present. The "data" 123 portion is variable length and could be null in some cases. The size 124 of the "data" portion can always be determined by subtracting 2 from 125 the SINK resource record RDLENGTH. The coding octet gives the 126 general structure of the data. The subcoding octet provides 127 additional information depending on the value of the coding octet. 129 INITIAL ASSIGNED CODING/SUBCODING OCTET VALUES 131 CODING 133 0 - reserved. 135 1 - The SNMP subset of ASN.1. 136 2 - OSI ASN.1 1990 [ASN.1]. 137 3 - OSI ASN.1 1994. 138 4-62 - Reserved for IANA assignment for future versions of OSI ASN.*. 139 63 - Private abstract syntax notations. This coding value will never 140 be assigned to a standard abstract syntax notation. An OSI 141 Object Identifier (OID) preceded by a one byte unsigned length 142 appears at the beginning of the data area to indicate which 143 private abstract syntax is being used. 144 - For all ASN.1 codings, the subcoding indicates what encoding 145 rules are in use as listed below. 146 ASN.* SUBCODINGS 147 0 - reserved. 148 1 - BER ( Basic Encoding Rules [BER]). 149 2 - DER ( Distinguished Encoding Rules [DER]). 150 3 - PER ( Packed Encoding Rules ) Aligned. 151 4 - PER Unaligned. 152 5-253 - available for IANA assignment to future OSI encoding 153 rules. 154 254 - private. This subcoding will never be assigned to a 155 standard set of encoding rules. An OID preceded by a one 156 byte unsigned length appears at the beginning of the data 157 area to indicate which private encoding unless the coding 158 is 63 (private) in which case the private subcoding OID 159 appears in the data area just after the coding OID. 160 255 - reserved. 162 64 - DNS RRs. The data portion consists of DNS resource records as 163 they would be transmitted in a DNS response section. The 164 subcoding octet is the number of RRs in the data area as an 165 unsigned integer. Domain names may be abbreviated via pointers 166 as in DNS replies. The origin for the pointers is the beginning 167 of the RDATA section of the SINK RR. 169 65 - MIME structured data [RFC 1521, 1522]. The data portion is a 170 MIME structured message. The "MIME-Version:" header line may be 171 omitted unless the version is other than "1.0". The top level 172 Content-Transfer-Encoding may be encoded into the subcoding 173 octet as indicated below. Note that, to some extent, the size 174 limitations of DNS RRs may be overcome in the MIME case by using 175 the "Content-Type: message/external-body" mechanism. 176 MIME SUBCODINGS 177 0 - reserved. 178 1 - 7bit. 179 2 - 8bit. 180 3 - binary. 181 4 - quoted-printable. 182 5 - base64. 183 6 - private. The data portion must start with an "x-" token 184 denoting the private content-transfer-encoding immediately 185 followed by one null (zero) octet followed by the remainder 186 of the MIME object. 187 7 - 254 - available for assignment to future content transfer 188 encodings. 255 - reserved. 190 66-253 - Available for general assignment to codings by IANA. 192 254 - Private formats indicated by a URL. This coding will never be 193 assigned to a standard format. The format of the data portion 194 is indicated by an initial URL [RFC 1738] which is terminated by 195 a zero valued octet followed by the data with that format. The 196 subcoding octet is available for whatever use the private 197 formating wishes to make of it. The manner in which the URL 198 specifies the format is not defined but presumably the retriever 199 will recognize the URL or the data it points to. 201 255 - reserved. 203 NOTE: the existence of a DNS RR coding and the infinite possibilities 204 of ASN.*s and MIME permit nesting SINKs. 206 3. Master File Representation 208 SINK resource records (RRs) may appear as lines in zone master files. 209 The coding and subcoding appear as unsigned decimal integers. The 210 data portion can be quite long. It is represented in base 64 [RFC 211 1521] and may be divided up into any number of white space separated 212 substrings, down to single base 64 digits, which are concatenated to 213 obtain the full data. These substrings can span lines using the 214 standard parenthesis. [This type of base64 master file data is 215 required to support the DNS KEY and SIG security RRs in any case.] 217 4. Performance Considerations 219 DNS is optimized for small data transfers, generally not exceeding 220 512 bytes including overhead. Larger transfers work correctly and 221 efforts are underway to make them more efficient. 223 It is easy to create very large RRs or RR sets using SINK. DNS 224 administrators should think carefully about this and may wish to 225 discourage large RRs or RR sets. Consideration should also be given 226 to putting zones from which large RRs or RR sets will be commonly 227 retrieved on separate hosts which can be tuned for the load this will 228 represent. 230 5. Security Considerations 232 Since the SINK resource record can be used to store arbitrary data in 233 the DNS, this data could have security consequences, particularly if 234 it is control, executable, macro, or interpretable information. Due 235 care should be taken. draft-ietf-dnssec-secext-10.txt covers data 236 original authentication of the data in the domain name system 237 including SINK RRs. 239 References 241 [ASN.1] Abstract Syntax Notation One, C.C.I.T.T. X.208. 243 [BER] Basic Encoding Rules for ASN.1, C.C.I.T.T. X.209. 245 [DER] Distinguished Encoding Rules for ASN.1, ISO/IEC 8825-1 | ITU-T 246 Rec. X.690.. 248 draft-ietf-dnssec-secext-10.txt 250 [RFC 1034] - P. Mockapetris, "Domain names - concepts and 251 facilities", 11/01/1987. 253 [RFC 1035] - P. Mockapetris, "Domain names - implementation and 254 specification", 11/01/1987. 256 [RFC 1521] - N. Borenstein, N. Freed, "MIME (Multipurpose Internet 257 Mail Extensions) Part One: Mechanisms for Specifying and Describing 258 the Format of Internet Message Bodies", 09/23/1993. 260 [RFC 1522] - K. Moore, "MIME (Multipurpose Internet Mail Extensions) 261 Part Two: Message Header Extensions for Non-ASCII Text", 09/23/1993. 263 [RFC 1738] - T. Berners-Lee, L. Masinter, M. McCahill, "Uniform 264 Resource Locators (URL)", 12/20/1994. 266 Author's Address 268 Donald E. Eastlake 3rd 269 CyberCash, Inc. 270 318 Acton Street 271 Carlisle, MA 01741 USA 273 Telephone: +1 508 287 4877 274 +1 703 620-4200 (main office, Reston, VA) 275 FAX: +1 508 371 7148 276 EMail: dee@cybercash.com 278 Expiration and File Name 280 This draft expires May 1997. 282 Its file name is draft-eastlake-kitchen-sink-00.txt.