idnits 2.17.1 draft-eastlake-kitchen-sink-02.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-04-25) 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-02.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-eastlake-kitchen-sink-02.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-eastlake-kitchen-sink-02.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-02.txt,', but the file name used is 'draft-eastlake-kitchen-sink-02' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 61 lines 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 146 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 (October 1997) is 9689 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: '1035' on line 76 -- Looks like a reference, but probably isn't: '2065' on line 76 -- Looks like a reference, but probably isn't: '2046' on line 174 == Unused Reference: 'RFC 1035' is defined on line 284, but no explicit reference was found in the text == Unused Reference: 'RFC 2046' is defined on line 300, 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 1642 (Obsoleted by RFC 2152) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2044 (Obsoleted by RFC 2279) ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) Summary: 14 errors (**), 1 flaw (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT The Kitchen Sink Resource Record 2 Expires October 1997 4 The Kitchen Sink Resource Record 5 --- ------- ---- -------- ------ 7 Donald E. Eastlake 3rd 9 Status of This Document 11 This draft, file name draft-eastlake-kitchen-sink-02.txt, is intended 12 to be become a Proposed Standard RFC. Distribution of this document 13 is unlimited. Comments should be sent to 14 or to the author. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months. Internet-Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet- 24 Drafts as reference material or to cite them other than as a 25 ``working draft'' or ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 29 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 30 nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 31 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 33 Abstract 35 Periodically people are seized with a desire to put complex, bulky, 36 and/or obscurely structured data into the Domain Name System (DNS). 37 This draft defines a kitchen sink Resource Record that will satisfy 38 this lust by defining a new DNS resource record for the storage of 39 miscellaneous structured information. 41 Acknowledgements 43 The suggestions of the following persons have improved this document 44 and they are gratefully acknowledged: 46 Rob Austein 47 Johnny Eriksson 48 Michael A. Patton 50 Table of Contents 52 Status of This Document....................................1 53 Abstract...................................................1 55 Acknowledgements...........................................2 56 Table of Contents..........................................2 58 1. Introduction............................................3 60 2. Kitchen Sink Resource Record............................4 62 3. Master File Representation..............................7 63 4. Performance Considerations..............................7 64 5. Security Considerations.................................7 66 References.................................................8 68 Author's Address...........................................9 69 Expiration and File Name...................................9 71 1. Introduction 73 The Domain Name System (DNS) provides a replicated distributed secure 74 hierarchical database which stores "resource records" (RRs) under 75 hierarchical domain names. This data is structured into zones which 76 are independently maintained. [RFC 1034, 1035, 2065] 78 Numerous types of RRs have been defined. These support such critical 79 functions as host name to address translation (A, AAAA, etc. RRs), 80 automatic mail routing (MX etc. RRs), and other functions. In 81 addition, there are RRs defined related to the zone structure and 82 administration of the DNS (SOA, NS, and RP RRs), security (SIG, KEY, 83 and NXT RRs), etc. There is a TXT RR for the inclusion of general 84 human readable text. 86 New RRs that are reasonably spartan and designed with some care are 87 periodically added via the IETF standards process as new needs become 88 apparent. But there are periodically people who want to put some 89 complex and frequently large structured data in the DNS. They 90 usually come up with some kludge way of reinterpreting the TXT RR, 91 since that is one of the least constrained RR. This is likely a bad 92 idea since all previous kludge ways to reinterpreting the TXT RR have 93 sunk without a trace. (Well, if they actually got an RFC out, it's 94 still there, but, practically speaking, nobody actually uses it.) 96 If a new type of data is really needed for common use in the DNS, the 97 best course is to design a new RR that efficiently meets the need 98 through the IETF standards process. 100 People who want to shoe-horn bulky or complex and obscurely 101 structured data into the DNS, which may not appropriate there, don't 102 want to hear that. This draft defines an extremely general and 103 flexible RR which can be pointed out to such people. It includes 104 representations of OSI ASN.1, MIME, and, recursively, DNS RRs. 106 2. Kitchen Sink Resource Record 108 The symbol for the kitchen sink resource record is SINK. Its type 109 number is . 111 The RDATA portion of the SINK RR is structured as follows: 113 1 1 1 1 1 1 114 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 115 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 116 | coding | subcoding | 117 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 118 | / 119 / data / 120 / / 121 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 123 The "coding" and "subcoding" octets are always present. The "data" 124 portion is variable length and could be null in some cases. The size 125 of the "data" portion can always be determined by subtracting 2 from 126 the SINK resource record RDLENGTH. The coding octet gives the 127 general structure of the data. The subcoding octet provides 128 additional information depending on the value of the coding octet. 130 INITIAL ASSIGNED CODING/SUBCODING OCTET VALUES 132 CODING 134 0 - reserved. 136 1 - The SNMP subset of ASN.1. 137 2 - OSI ASN.1 1990 [ASN.1]. 138 3 - OSI ASN.1 1994. 139 4-62 - Reserved for IANA assignment for future versions of OSI ASN.*. 140 63 - Private abstract syntax notations. This coding value will not 141 be assigned to a standard abstract syntax notation. An OSI 142 Object Identifier (OID) preceded by a one byte unsigned length 143 appears at the beginning of the data area to indicate which 144 private abstract syntax is being used. 145 - For all ASN.* codings, the subcoding indicates what encoding 146 rules are in use as listed below. 148 ASN.* SUBCODINGS 149 0 - reserved. 150 1 - BER ( Basic Encoding Rules [BER] ). 151 2 - DER ( Distinguished Encoding Rules [DER] ). 152 3 - PER ( Packed Encoding Rules ) Aligned. 153 4 - PER Unaligned. 154 5 - CER ( Canonical Encoding Rules ). 155 6-253 - available for IANA assignment to future OSI encoding 156 rules. 157 254 - private. This subcoding will never be assigned to a 158 standard set of encoding rules. An OID preceded by a one 159 byte unsigned length appears at the beginning of the data 160 area to indicate which private encoding unless the coding 161 is 63 (private) in which case the private subcoding OID 162 appears in the data area just after the coding OID. 163 255 - reserved. 165 64 - DNS RRs. The data portion consists of DNS resource records as 166 they would be transmitted in a DNS response section. The 167 subcoding octet is the number of RRs in the data area as an 168 unsigned integer. Domain names may be compressed via pointers 169 as in DNS replies. The origin for the pointers is the beginning 170 of the RDATA section of the SINK RR. Thus the SINK RR is safe 171 to cache since only code that knows how to parse the data 172 portion need know of and can expand these compressions. 174 65 - MIME structured data [RFC 2045, 2046]. The data portion is a 175 MIME structured message. The "MIME-Version:" header line may be 176 omitted unless the version is other than "1.0". The top level 177 Content-Transfer-Encoding may be encoded into the subcoding 178 octet as indicated below. Note that, to some extent, the size 179 limitations of DNS RRs may be overcome in the MIME case by using 180 the "Content-Type: message/external-body" mechanism. 182 MIME SUBCODINGS 183 0 - reserved. 184 1 - 7bit. 185 2 - 8bit. 186 3 - binary. 187 4 - quoted-printable. 188 5 - base64. 189 6 - 253 - available for assignment to future content transfer 190 encodings. 191 254 - private. The data portion must start with an "x-" token 192 denoting the private content-transfer-encoding immediately 193 followed by one null (zero) octet followed by the remainder 194 of the MIME object. 195 255 - reserved. 197 66 - Text tagged data. The data potion consists of text formated as 198 specified in the TXT RR except that the first and every 199 subsequent odd numbered text item is considered to be a tag 200 labeling the immediately following text item. If there are an 201 odd number of text items overall, then the last is considered to 202 label a null text item. Syntax of the tags is as specified in 203 RFC 1738 for the "Common Internet Scheme Syntax" without the two 204 leading slashes ("//"). Thus any organization with a domain 205 name can assign tags without fear of conflict. 207 - The subcodings byte specifies the encoding of the labeled text 208 items as follows: 210 TEXT SUBCODINGS 211 0 - reserved. 212 1 - ASCII. 213 2 - UTF-7 [RFC 1642]. 214 3 - UTF-8 [RFC 2044]. 215 4 - ASCII with MIME header escapes [RFC 2047]. 216 5 - 253 - available for assignment to future text encodings. 217 254 - private. Each text item must start with a domain name 218 [RFC 1034] denoting the private text encoding immediately 219 followed by one null (zero) octet followed by the remainder 220 of the text item. 255 - reserved. 222 67-253 - Available for general assignment to codings by IANA. 224 254 - Private formats indicated by a URL. This coding will never be 225 assigned to a standard format. The format of the data portion 226 is indicated by an initial URL [RFC 1738] which is terminated by 227 a zero valued octet followed by the data with that format. The 228 subcoding octet is available for whatever use the private 229 formating wishes to make of it. The manner in which the URL 230 specifies the format is not defined but presumably the retriever 231 will recognize the URL or the data it points to. 233 255 - reserved. 235 NOTE: the existence of a DNS RR coding and the infinite possibilities 236 of ASN.*s and MIME permit nesting SINKs. 238 3. Master File Representation 240 SINK resource records (RRs) may appear as lines in zone master files. 241 The coding and subcoding appear as unsigned decimal integers. The 242 data portion can be quite long. It is represented in base 64 [RFC 243 2045] and may be divided up into any number of white space separated 244 substrings, down to single base 64 digits, which are concatenated to 245 obtain the full data. These substrings can span lines using the 246 standard parenthesis. (This type of base64 master file data is also 247 required to support the DNS KEY and SIG security RRs [RFC 2065] in 248 any case.) 250 4. Performance Considerations 252 DNS is optimized for small data transfers, generally not exceeding 253 512 bytes including overhead. Larger transfers work correctly and 254 efforts are underway to make them more efficient. 256 It is easy to create very large RRs or RR sets using SINK. DNS 257 administrators should think carefully about this and may wish to 258 discourage large RRs or RR sets. Consideration should also be given 259 to putting zones from which large RRs or RR sets will be commonly 260 retrieved on separate hosts which can be tuned for the load this will 261 represent. 263 5. Security Considerations 265 Since the SINK resource record can be used to store arbitrary data in 266 the DNS, this data could have security consequences, particularly if 267 it is control, executable, macro, or interpretable information or 268 very large. Due care should be taken. RFC 2065 covers data original 269 authentication of the data in the domain name system including SINK 270 RRs. 272 References 274 [ASN.1] Abstract Syntax Notation One, C.C.I.T.T. X.208. 276 [BER] Basic Encoding Rules for ASN.1, C.C.I.T.T. X.209. 278 [DER] Distinguished Encoding Rules for ASN.1, ISO/IEC 8825-1 | ITU-T 279 Rec. X.690.. 281 [RFC 1034] - P. Mockapetris, "Domain names - concepts and 282 facilities", 11/01/1987. 284 [RFC 1035] - P. Mockapetris, "Domain names - implementation and 285 specification", 11/01/1987. 287 [RFC 1642] - D. Goldsmith, M. Davis, "UTF-7 - A Mail-Safe 288 Transformation Format of Unicode", 07/13/1994. 290 [RFC 1738] - T. Berners-Lee, L. Masinter, M. McCahill, "Uniform 291 Resource Locators (URL)", 12/20/1994. 293 [RFC 2044] - F. Yergeau, "UTF-8, a transformation format of Unicode 294 and ISO 10646", 10/30/1996. 296 [RFC 2045] - N. Freed, N. Borenstein, "Multipurpose Internet Mail 297 Extensions (MIME) Part One: Format of Internet Message Bodies", 298 12/02/1996. 300 [RFC 2046] - N. Freed, N. Borenstein, "Multipurpose Internet Mail 301 Extensions (MIME) Part Two: Media Types", 12/02/1996. 303 [RFC 2047] - K. Moore, "MIME (Multipurpose Internet Mail Extensions) 304 Part Three: Message Header Extensions for Non-ASCII Text", 305 12/02/1996. 307 [RFC 2065] - D. Eastlake, C. Kaufman, "Domain Name System Security 308 Extensions", 01/03/1997. 310 Author's Address 312 Donald E. Eastlake 3rd 313 CyberCash, Inc. 314 318 Acton Street 315 Carlisle, MA 01741 USA 317 Telephone: +1 508 287 4877 318 +1 703 620-4200 (main office, Reston, VA) 319 FAX: +1 508 371 7148 320 EMail: dee@cybercash.com 322 Expiration and File Name 324 This draft expires October 1997. 326 Its file name is draft-eastlake-kitchen-sink-02.txt.