idnits 2.17.1 draft-ietf-dnsind-kitchen-sink-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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? ** Bad filename characters: the document name given in the document, 'draft-ietf-dnsind-kitchen-sink-00.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnsind-kitchen-sink-00.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnsind-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-ietf-dnsind-kitchen-sink-00.txt,', but the file name used is 'draft-ietf-dnsind-kitchen-sink-00' == 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 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 206: '... subcoding octet MUST be ignored and S...' Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (June 1999) is 9074 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 87 -- Looks like a reference, but probably isn't: '2046' on line 229 == Unused Reference: 'RFC 1035' is defined on line 402, but no explicit reference was found in the text == Unused Reference: 'RFC 2046' is defined on line 415, 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 2044 (Obsoleted by RFC 2279) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 12 errors (**), 1 flaw (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake, 3rd 2 IBM 3 Expires December 1999 June 1999 5 The Kitchen Sink Resource Record 6 --- ------- ---- -------- ------ 8 Donald E. Eastlake 3rd 10 Status of This Document 12 This draft, file name draft-ietf-dnsind-kitchen-sink-00.txt, is 13 intended to be become a Proposed 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 and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months. Internet-Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet- 26 Drafts as reference material or to cite them other than as a 27 ``working draft'' or ``work in progress.'' 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 To view the entire list of current Internet-Drafts, please check the 36 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 37 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 38 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 39 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 41 Abstract 43 Periodically people are seized with a desire to put proprietary, 44 complex, and/or obscure data into the Domain Name System (DNS). This 45 draft defines a kitchen sink Resource Record that will satisfy this 46 desire for the storage of miscellaneous structured information. 48 Acknowledgements 50 The suggestions of the following persons have improved this document 51 and they are gratefully acknowledged: 53 Rob Austein 54 Johnny Eriksson 55 Michael A. Patton 57 Table of Contents 59 Status of This Document....................................1 60 Abstract...................................................1 62 Acknowledgements...........................................2 63 Table of Contents..........................................2 65 1. Introduction............................................3 66 2. Kitchen Sink Resource Record............................3 67 2.1 The Meaning Octet......................................4 68 2.2 The Coding and Subcoding Octets........................5 69 2.2.1 ASN.* Subcodings.....................................7 70 2.2.2 MIME Subcodings......................................7 71 2.2.3 Text Subcodings......................................8 72 3. Master File Representation..............................8 73 4. Performance Considerations..............................9 74 5. Security Considerations.................................9 75 6. IANA Considerations.....................................9 77 References................................................10 79 Author's Address..........................................11 80 Expiration and File Name..................................11 82 1. Introduction 84 The Domain Name System (DNS) provides a replicated distributed secure 85 hierarchical database which stores "resource records" (RRs) under 86 hierarchical domain names. This data is structured into zones which 87 are independently maintained. [RFC 1034, 1035] 89 Numerous types of RRs have been defined. These support such critical 90 functions as host name to address translation (A, AAAA, etc. RRs), 91 automatic mail routing (MX etc. RRs), and other functions. In 92 addition, there are RRs defined related to the zone structure and 93 administration of the DNS (SOA, NS, and RP RRs), security (SIG, KEY, 94 and NXT RRs), etc. There is a TXT RR for the inclusion of general 95 human readable text. 97 New RRs that are reasonably spar tan and designed with some care are 98 periodically added via the IETF standards process as new needs become 99 apparent. But there are periodically people who want to put some 100 prorietary, complex and/or large structured data in the DNS. They 101 frequently come up with some way of reinterpreting the TXT RR, since 102 that is one of the least constrained RR. This is likely a bad idea 103 since all previous ways to reinterpreting the TXT RR have sunk 104 without a trace. (Well, if they actually got an RFC out, it's still 105 there, but, practically speaking, nobody actually uses it.) 107 If a new type of data is strongly needed for common interoperable use 108 in the DNS, the best course is to design a new RR that efficiently 109 meets the need through the IETF standards process. This draft 110 defines an extremely general and flexible RR which can be used for 111 other data, such as proprietary data where global interoperability is 112 not a consideration. It includes representations of OSI ASN.1, MIME, 113 XML, and, recursively, DNS RRs. 115 2. Kitchen Sink Resource Record 117 The symbol for the kitchen sink resource record is SINK. Its type 118 number is . 120 The RDATA portion of the SINK RR is structured as follows: 122 1 1 1 1 1 1 123 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 124 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 125 | meaning | coding | 126 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 127 | subcoding | / 128 +--+--+--+--+--+--+--+--+ / 129 / data / 130 / / 131 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 133 The "meaning", "coding", and "subcoding" octets are always present. 134 The "data" portion is variable length and could be null in some 135 cases. The size of the "data" portion can always be determined by 136 subtracting 2 from the SINK resource record RDLENGTH. The coding 137 octet gives the general structure of the data. The subcoding octet 138 provides additional information depending on the value of the coding 139 nibble. 141 [The primary objection to the previous version of this draft (draft- 142 eastlake-kitchen-sink-05.txt) which I do not feel is answered by 143 revision is as follows: If several different uses of SINK become 144 popular, then DNS retrievals, which are based on RR type only, will 145 get them all possibly resulting in wasted transfer bandwidth, 146 unnecessary TCP (as opposed to UDP) transfers, etc. 148 I do not think this will be a serious problem and if it becomes one, 149 future changes can be made such as a special DNS "extended query" 150 that allows finer specification. 152 The only alternative I have thought of is to allocate a block of RR 153 types to SINK. Then determine the actual RR type to use based on a 154 hash of the meaning, coding, and subcoding octets and of any prefixes 155 in the "data" fields based on those octets. But this would not 156 guarantee that two or more popular SINK RRs wouldn't collide.] 158 2.1 The Meaning Octet 160 The meaning octet indicates whether any semantic labeling appears at 161 the beginning of the data field and the format of such semantic 162 labeling. This contrasts with the coding and subcoding octets which 163 merely indicate format. 165 The types of labels available are chosen to be globally unique and 166 under the control of some "owner". The owner designates the meaning 167 associated with the labels they control. Where the label is a URI, 168 it is recommended that a retrieval from the URI fetch material that 169 would be helpful in determining this meaning. No a priori method is 170 defined for determining the meaning of other labels other than an out 171 of band to the owner. 173 INITIAL ASSIGNED MEANING VALUES 175 0 - reserved. 177 1 - none. 178 2 - OID. 179 3 - domain name. 180 4 - URI. 182 5-254 - available for assignment, see section 6. 184 255 - reserved. 186 A meaning octet value of 1 indicates that there is no semantic 187 labeling at the beginning of the data area. The information, 188 whatever it is, coded according to the coding and subcoding octets, 189 starts at the beginning of the data field. 191 Meaning octet values of 2, 3, or 4, indicate, on the other hand, that 192 a semantic label is present. A value of two indicates that a BER 193 [BER] encoded OID appears prefixed by an OID length count as a single 194 unsigned octet. A value of three indicates that a DNS domain name 195 appears in wire format with name compression prohibited. And a value 196 of four indicates that a null octet terminated URI appears. 198 2.2 The Coding and Subcoding Octets 200 The coding octet gives the major method by which the data in the data 201 field is encoded. It should always have a meaningful value. The 202 subcoding octet is intended to give additional coding details. 203 Although the subcoding octet is always present, it must be 204 interpreted in the context of the coding octet. For any coding octet 205 value which does not specify subcoding octet value meanings, the 206 subcoding octet MUST be ignored and SHOULD be zero. 208 While not explicitly mentioned below, the data field will actually 209 start with a semantic label is indicated by the meaning octet. If 210 such a semantic label is present, any data prefix required by the 211 coding or subcoding octet. 213 CODING OCTET VALUES 215 0 - reserved. 217 1 - ASN.1. See section 2.2.1. 219 2 - DNS RRs. The data portion consists of DNS resource records 220 as they would be transmitted in a DNS response section. The 221 subcoding octet is the number of RRs in the data area as an 222 unsigned integer. Domain names may be compressed via pointers 223 as in DNS replies. The origin for the pointers is the beginning 224 of the RDATA section of the SINK RR. Thus the SINK RR is safe 225 to cache since only code that knows how to parse the data 226 portion of a SINK RR need know of and can expand these 227 compressions. 229 3 - MIME structured data [RFC 2045, 2046]. The data portion is 230 a MIME structured message. The "MIME-Version:" header line may 231 be omitted unless the version is other than "1.0". The top 232 level Content-Transfer-Encoding may be encoded into the 233 subcoding octet (see section 2.2.2). Note that, to some extent, 234 the size limitations of DNS RRs may be overcome in the MIME case 235 by using the "Content-Type: message/external-body" mechanism. 237 4 - Text tagged data. The data potion consists of text formated 238 as specified in the TXT RR except that the first and every 239 subsequent odd numbered text item is considered to be a tag 240 labeling the immediately following text item. If there are an 241 odd number of text items overall, then the last is considered to 242 label a null text item. Syntax of the tags is as specified in 243 RFC 2396 for the "Authority Component" without the two leading 244 slashes ("//") or trailing slash using the DNS for authority. 245 Thus any organization with a domain name can assign tags without 246 fear of conflict. The subcodings octet specifies the encoding 247 of the labeled text items as specified in section 2.2.3. 249 5 - HTML. The subcoding octet indicates the version of HTML. 251 6 - XML. The subcoding octet is not used. 253 7-251 - Available for assignment, see section 6. 255 252 - Private coding format indicated by an OID. The format of 256 the data portion is indicated by an initial BER encoded OID 257 which is prefixed by an OID octet count give as an unsigned 258 octet. The subcoding octet is available for whatever use the 259 private formating wishes to make of it. 261 253 - Private coding format indicated by a domain name. The 262 format of the data portion is indicated by an initial wire 263 format domain name with compression prohibited. The subcoding 264 octet is available for whatever use the private formating wishes 265 to make of it. 267 254 - Private coding format indicated by a URI. The format of 268 the data portion is indicated by an initial URI [RFC 2396] which 269 is terminated by a zero valued octet followed by the data with 270 that format. The subcoding octet is available for whatever use 271 the private formating wishes to make of it. The manner in which 272 the URL specifies the format is not defined but presumably the 273 retriever will recognize the URI. 275 255 - reserved. 277 NOTE: the existence of a DNS RR coding and the infinite possibilities 278 of ASN.*s, XML, and MIME permit one to SINK to even greater depths by 279 nesting SINKs. 281 2.2.1 ASN.* Subcodings 283 If the coding octet indicates the data is ASN.1 derived, then the 284 data is prefixed by an OID designating the version of ASN.1 used. 285 [Can anyone provide the values for the common varieties of ASN.1?] 287 For ASN.* data, a specific concrete encoding must be chosen as 288 indicated by the subcoding octet. 290 ASN.* SUBCODINGS 292 0 - reserved. 293 1 - BER ( Basic Encoding Rules [BER] ). 294 2 - DER ( Distinguished Encoding Rules [DER] ). 295 3 - PER ( Packed Encoding Rules ) Aligned. 296 4 - PER Unaligned. 297 5 - CER ( Canonical Encoding Rules ). 298 6-253 - available for assignment, see section 6. 299 254 - private. This subcoding will never be assigned to a standard 300 set of encoding rules. An OID preceded by a one octet unsigned 301 length appears at the beginning of the data area after the ASN 302 coding OID. 303 255 - reserved. 305 2.2.2 MIME Subcodings 307 If the coding octet indicates the data is MIME structured, the 308 precise encoding is given by the subcoding octets as listed below. 310 MIME SUBCODINGS 312 0 - reserved, see section 6. 313 1 - 7bit. 314 2 - 8bit. 315 3 - binary. 316 4 - quoted-printable. 317 5 - base64. 318 6 - 253 - available for assignment, see section 6. 319 254 - private. The data portion must start with an "x-" token 320 denoting the private content-transfer-encoding immediately 321 followed by one null (zero) octet followed by the remainder of 322 the MIME object. 323 255 - reserved, see section 6. 325 2.2.3 Text Subcodings 327 If the coding octet indicates the data is text, the exact encoding of 328 the text items is indicated by the subcoding octet as follows: 330 TEXT SUBCODINGS 332 0 - reserved, see section 6. 333 1 - ASCII. 334 2 - UTF-7 [RFC 1642]. 335 3 - UTF-8 [RFC 2044]. 336 4 - ASCII with MIME header escapes [RFC 2047]. 337 5 - 253 - available for assignment, see section 6. 338 254 - private. Each text item must start with a domain name [RFC 339 1034] denoting the private text encoding immediately followed by 340 one null (zero) octet followed by the remainder of the text 341 item. 342 255 - reserved, see section 6. 344 3. Master File Representation 346 SINK resource records may appear as lines in zone master files. The 347 meaning, coding, and subcoding appear as unsigned decimal integers. 348 The data portion can be quite long. It is represented in base 64 349 [RFC 2045] and may be divided up into any number of white space 350 separated substrings, down to single base 64 digits, which are 351 concatenated to obtain the full data. These substrings can span 352 lines using the standard parenthesis. (This type of base64 master 353 file data is also required to support the DNS KEY and SIG security 354 RRs [RFC 2535] in any case.) 356 4. Performance Considerations 358 Currently DNS is optimized for small data transfers, generally not 359 exceeding 512 octets including overhead. Larger transfers are less 360 efficient but do work correctly and efforts are underway to make them 361 more efficient. 363 It is easy to create very large RRs or RR sets using SINK. DNS 364 administrators should think carefully about this and may wish to 365 discourage large RRs or RR sets. Consideration should also be given 366 to putting zones from which large RRs or RR sets will be commonly 367 retrieved on separate hosts which can be tuned for the load this will 368 represent. 370 5. Security Considerations 372 Since the SINK resource record can be used to store arbitrary data in 373 the DNS, this data could have security consequences, particularly if 374 it is control, executable, macro, or interpretable information or 375 very large and might cause buffer overflow. Due care should be 376 taken. [RFC 2535] covers data original authentication of the data in 377 the domain name system including SINK RRs. 379 6. IANA Considerations 381 Assignment of specific meaning to the values listed herein as 382 "reserved" requires an IETF standards action. 384 All other assignments are by IETF consensus. 386 The many provisions for private indicita specified by separately 387 allocated OIDs, domain names, or URIs should cover most requirements 388 for private or proprietary values. 390 References 392 [ASN.1] Abstract Syntax Notation One, C.C.I.T.T. X.208. 394 [BER] Basic Encoding Rules for ASN.1, C.C.I.T.T. X.209. 396 [DER] Distinguished Encoding Rules for ASN.1, ISO/IEC 8825-1 | ITU-T 397 Rec. X.690.. 399 [RFC 1034] - P. Mockapetris, "Domain names - concepts and 400 facilities", 11/01/1987. 402 [RFC 1035] - P. Mockapetris, "Domain names - implementation and 403 specification", 11/01/1987. 405 [RFC 1642] - D. Goldsmith, M. Davis, "UTF-7 - A Mail-Safe 406 Transformation Format of Unicode", 07/13/1994. 408 [RFC 2044] - F. Yergeau, "UTF-8, a transformation format of Unicode 409 and ISO 10646", 10/30/1996. 411 [RFC 2045] - N. Freed, N. Borenstein, "Multipurpose Internet Mail 412 Extensions (MIME) Part One: Format of Internet Message Bodies", 413 12/02/1996. 415 [RFC 2046] - N. Freed, N. Borenstein, "Multipurpose Internet Mail 416 Extensions (MIME) Part Two: Media Types", 12/02/1996. 418 [RFC 2047] - K. Moore, "MIME (Multipurpose Internet Mail Extensions) 419 Part Three: Message Header Extensions for Non-ASCII Text", 420 12/02/1996. 422 [RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform 423 Resource Identifiers (URI): Generic Syntax", August 1998. 425 [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", 426 March 1999. 428 Author's Address 430 Donald E. Eastlake 3rd 431 IBM 432 65 Shindegan Hill Road 433 Carmel, 10512 USA 435 Telephone: +1 914-276-2668 (h) 436 +1 914-784-7913 (w) 437 FAX: +1 914-784-3833 (w) 438 EMail: dee3@us.ibm.com 440 Expiration and File Name 442 This draft expires December 1999. 444 Its file name is draft-ietf-dnsind-kitchen-sink-00.txt.