idnits 2.17.1 draft-ietf-dnsind-kitchen-sink-02.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: ---------------------------------------------------------------------------- ** 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? == 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 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 209: '... subcoding octet MUST be ignored and S...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1999) is 8989 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 90 -- Looks like a reference, but probably isn't: '2535' on line 90 -- Looks like a reference, but probably isn't: '2046' on line 230 == Unused Reference: 'RFC 1035' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'RFC 2046' is defined on line 442, but no explicit reference was found in the text ** 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: 9 errors (**), 0 flaws (~~), 4 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 March 2000 September 1999 4 draft-ietf-dnsind-kitchen-sink-02.txt 6 The Kitchen Sink DNS Resource Record 7 --- ------- ---- --- -------- ------ 9 Donald E. Eastlake 3rd 11 Status of This Document 13 This draft, file name draft-ietf-dnsind-kitchen-sink-02.txt, is 14 intended to be become an Experimental RFC. Distribution of this 15 document is unlimited. Comments should be sent to 16 or to the author. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months. Internet-Drafts may be updated, replaced, or obsoleted by 26 other documents at any time. It is not appropriate to use Internet- 27 Drafts as reference material or to cite them other than as a 28 ``working draft'' or ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The Internet Society (1999). All Rights Reserved 40 Abstract 42 Periodically people desire to put proprietary, complex, and/or 43 obscure data into the Domain Name System (DNS). This draft defines a 44 kitchen sink Resource Record that will satisfy this desire for the 45 storage of miscellaneous structured information. 47 Acknowledgements 49 The suggestions or information provided by the following persons have 50 improved this document and they are gratefully acknowledged: 52 Rob Austein 53 Matt Crawford 54 Johnny Eriksson 55 Phillip H. Griffin 56 Michael A. Patton 57 David Singer 59 Table of Contents 61 Status of This Document....................................1 62 Copyright Notice...........................................1 63 Abstract...................................................1 65 Acknowledgements...........................................2 66 Table of Contents..........................................2 68 1. Introduction............................................3 69 2. Kitchen Sink Resource Record............................3 70 2.1 The Meaning Octet......................................4 71 2.2 The Coding and Subcoding Octets........................5 72 2.2.1 ASN.1 Subcodings.....................................7 73 2.2.2 MIME Subcodings......................................7 74 2.2.3 Text Subcodings......................................8 75 3. Master File Representation..............................8 76 4. Performance Considerations..............................9 77 5. Security Considerations.................................9 78 6. IANA Considerations.....................................9 79 7. Full Copyright Statement................................9 81 References................................................11 82 Author's Address..........................................12 83 Expiration and File Name..................................12 85 1. Introduction 87 The Domain Name System (DNS) provides a replicated distributed secure 88 hierarchical database which stores "resource records" (RRs) under 89 hierarchical domain names. This data is structured into zones which 90 are independently maintained. [RFC 1034, 1035, 2535] 92 Numerous types of RRs have been defined. These support such critical 93 functions as host name to address translation (A, AAAA, etc. RRs), 94 automatic mail routing (MX etc. RRs), and other functions. In 95 addition, there are RRs defined related to the zone structure and 96 administration of the DNS (SOA, NS, and RP RRs), security (SIG, KEY, 97 and NXT RRs), etc. There is a TXT RR for the inclusion of general 98 human readable text. 100 New RRs that are reasonably simple and designed via the open IETF 101 standards process are periodically added as new needs become 102 apparent. But there are people who want to put some proprietary, 103 complex and/or non-standard structured data in the DNS. In the past 104 they have frequently come up with some way of reinterpreting the TXT 105 RR, since that is one of the least constrained RRs. This is likely a 106 bad idea since all previous ways to reinterpreting the TXT RR have 107 sunk without a trace. (Well, if they actually got an RFC out, it's 108 still there, but, practically speaking, almost nobody actually uses 109 it.) 111 If a new type of data is needed for a global interoperable use in the 112 DNS, the best course is to design a new RR that meets the need 113 through the IETF standards process. This draft defines an extremely 114 general and flexible RR which can be used for other data, such as 115 proprietary data, where global interoperability is not a 116 consideration. It includes representations of OSI ASN.1, MIME, XML, 117 and, recursively, DNS RRs. 119 2. Kitchen Sink Resource Record 121 The symbol for the kitchen sink resource record is SINK. Its type 122 number is 40. This type is defined across all DNS classes. 124 The RDATA portion of the SINK RR is structured as follows: 126 1 1 1 1 1 1 127 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 128 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 129 | meaning | coding | 130 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 131 | subcoding | / 132 +--+--+--+--+--+--+--+--+ / 133 / data / 134 / / 135 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 137 The "meaning", "coding", and "subcoding" octets are always present. 138 The "data" portion is variable length and could be null in some 139 cases. The size of the "data" portion can always be determined by 140 subtracting 3 from the SINK resource record RDLENGTH. The coding 141 octet gives the general structure of the data. The subcoding octet 142 provides additional information depending on the value of the coding 143 nibble. 145 All references to "domain name" in this document mean a domain name 146 in the DNS CLASS of the SINK RR. 148 2.1 The Meaning Octet 150 The meaning octet indicates whether any semantic tagging appears at 151 the beginning of the data field and the format of such semantic 152 tagging. This contrasts with the coding and subcoding octets which 153 merely indicate format. The inclusion of such semantic tagging is 154 encouraged and it is expected to be the primary means by which 155 applications determine if a SINK RR is of the variety in which they 156 have interest. 158 It is noted that multiple popular uses of SINK could develop that are 159 not distinguished by using different parts of the DNS name space or 160 different DNS classes. If this occurs, retrievals may fetch large 161 sets of SINK RR to be sorted through at the application level. 162 Should this occur, such popular uses of SINK should obtain and 163 migrate to their own RR number using normal RR number allocation 164 procedures. In addition, it would be possible to define an extended 165 query operation that selects from among SINK RRs based on the 166 semantic tag. 168 The types of tags available are chosen to be globally unique and 169 under the control of some "owner". The owner designates the meaning 170 associated with the tags they control. Where the tag is a URI, it is 171 recommended that a retrieval from the URI fetch material that would 172 be helpful in determining this meaning. No a priori method is 173 defined for determining the meaning of other tags beside an out of 174 band question to the owner. 176 INITIAL ASSIGNED MEANING VALUES 178 0 - reserved. 180 1 - none. 181 2 - OID. 182 3 - domain name. 183 4 - URI. 185 5-254 - available for assignment, see section 6. 187 255 - reserved. 189 A meaning octet value of 1 indicates that there is no semantic 190 tagging at the beginning of the data area. The information, whatever 191 it is, starts at the beginning of the data field and is coded 192 according to the coding and subcoding octets. 194 Meaning octet values of 2, 3, or 4, indicate, on the other hand, that 195 a semantic tag is present. A value of two indicates that a BER 196 [X.690] encoded OID appears prefixed by a single unsigned octet of 197 OID length count. A value of three indicates that a DNS domain name 198 appears in wire format with name compression prohibited. And a value 199 of four indicates that a null (zero) octet terminated URI appears. 201 2.2 The Coding and Subcoding Octets 203 The coding octet gives the major method by which the data in the data 204 field is encoded. It should always have a meaningful value. The 205 subcoding octet is intended to give additional coding details. 206 Although the subcoding octet is always present, it must be 207 interpreted in the context of the coding octet. For any coding octet 208 value which does not specify subcoding octet value meanings, the 209 subcoding octet MUST be ignored and SHOULD be zero. 211 While not explicitly mentioned below, the data field will actually 212 start with a semantic tag if indicated by the meaning octet. If such 213 a semantic tag is present, any data prefix required by the coding or 214 subcoding octet is placed after the semantic tag and before the data. 216 CODING OCTET VALUES 218 0 - reserved. 220 1 - DNS RRs. The data portion consists of DNS resource records 221 as they would be transmitted in a DNS response section. The 222 subcoding octet is the number of RRs in the data area as an 223 unsigned integer. Domain names may be compressed via pointers 224 as in DNS replies. The origin for the pointers is the beginning 225 of the RDATA section of the SINK RR. Thus the SINK RR is safe 226 to cache since only code that knows how to parse the data 227 portion of a SINK RR need know of and can expand these 228 compressions. 230 2 - MIME structured data [RFC 2045, 2046]. The data portion is 231 a MIME structured message. The "MIME-Version:" header line may 232 be omitted unless the version is other than "1.0". The top 233 level Content-Transfer-Encoding may be encoded into the 234 subcoding octet (see section 2.2.2). Note that, to some extent, 235 the size limitations of DNS RRs may be overcome in the MIME case 236 by using the "Content-Type: message/external-body" mechanism. 238 3 - Text tagged data. The data potion consists of text formated 239 as specified in the TXT RR except that the first and every 240 subsequent odd numbered text item is considered to be a tag 241 labeling the immediately following text item. If there are an 242 odd number of text items overall, then the last is considered to 243 label a null text item. Syntax of the tags is as specified in 244 RFC 2396 for the "Authority Component" without the two leading 245 slashes ("//") or trailing slash using the DNS for authority. 246 Thus any organization with a domain name can assign tags without 247 fear of conflict. The subcodings octet specifies the encoding 248 of the labeled text items as specified in section 2.2.3. 250 4 - HTML. The subcoding octet indicates the version of HTML 251 with the major version number in the upper nibble and the minor 252 version number in the lower nibble. Thus, for example, HTML 3.2 253 would be indicated by a 0x32 octet. 255 5 - XML. The subcoding octet is the version of XML, currently 256 1. 258 6 - ASN.1 [X.680, etc.]. See section 2.2.1. 260 7-251 - Available for assignment, see section 6. 262 252 - Private coding format indicated by an OID. The format of 263 the data portion is indicated by an initial BER encoded OID 264 which is prefixed by a one octet unsigned length count for the 265 OID. The subcoding octet is available for whatever use the 266 private formating wishes to make of it. 268 253 - Private coding format indicated by a domain name. The 269 format of the data portion is indicated by an initial wire 270 format domain name with compression prohibited. (Such names are 271 self delimiting.) The subcoding octet is available for whatever 272 use the private formating wishes to make of it. 274 254 - Private coding format indicated by a URI. The format of 275 the data portion is indicated by an initial URI [RFC 2396] which 276 is terminated by a zero (null) valued octet followed by the data 277 with that format. The subcoding octet is available for whatever 278 use the private formating wishes to make of it. The manner in 279 which the URI specifies the format is not defined but presumably 280 the retriever will recognize the URI by some pattern match. 282 255 - reserved. 284 NOTE: the existence of a DNS RR coding and the infinite possibilities 285 of ASN.1, XML, and MIME permit one to SINK to even greater depths by 286 nesting. 288 2.2.1 ASN.1 Subcodings 290 For ASN.1 [X.680, etc.] data, a specific concrete encoding must be 291 chosen as indicated by the subcoding octet. 293 ASN.* SUBCODINGS 295 0 - reserved. 296 1 - BER ( Basic Encoding Rules [X.690] ). 297 2 - DER ( Distinguished Encoding Rules [X.690] ). 298 3 - PER ( Packed Encoding Rules ) Aligned [X.691]. 299 4 - PER Unaligned [X.691]. 300 5 - CER ( Canonical Encoding Rules [X.690] ). 301 6-253 - available for assignment, see section 6. 302 254 - private. This subcoding will never be assigned to a standard 303 set of encoding rules. An OID preceded by a one octet unsigned 304 length of OID appears at the beginning of the data area after 305 the ASN coding OID. 306 255 - reserved. 308 2.2.2 MIME Subcodings 310 If the coding octet indicates the data is MIME structured, the 311 precise encoding is given by the subcoding octets as listed below. 313 MIME SUBCODINGS 315 0 - reserved, see section 6. 316 1 - 7bit. 317 2 - 8bit. 319 3 - binary. 320 4 - quoted-printable. 321 5 - base64. 322 6 - 253 - available for assignment, see section 6. 323 254 - private. The data portion must start with an "x-" or "X-" 324 token denoting the private content-transfer-encoding immediately 325 followed by one null (zero) octet followed by the remainder of 326 the MIME object. 327 255 - reserved, see section 6. 329 2.2.3 Text Subcodings 331 If the coding octet indicates the data is text, the exact encoding of 332 the text items is indicated by the subcoding octet as follows: 334 TEXT SUBCODINGS 336 0 - reserved, see section 6. 337 1 - ASCII. 338 2 - UTF-7 [RFC 1642]. 339 3 - UTF-8 [RFC 2044]. 340 4 - ASCII with MIME header escapes [RFC 2047]. 341 5 - 253 - available for assignment, see section 6. 342 254 - private. Each text item must start with a domain name [RFC 343 1034] in wire format without compression denoting the private 344 text encoding immediately followed by the remainder of the text 345 item. 346 255 - reserved, see section 6. 348 3. Master File Representation 350 SINK resource records may appear as lines in zone master files. The 351 meaning, coding, and subcoding appear as unsigned decimal integers. 352 The data portion can be quite long. It is represented in base 64 353 [RFC 2045] and may be divided up into any number of white space 354 separated substrings, down to single base 64 digits, which are 355 concatenated to obtain the full data. These substrings can span 356 lines using the standard parenthesis notation. (This type of base64 357 master file data is also required to support the DNS KEY and SIG 358 security RRs [RFC 2535].) 360 4. Performance Considerations 362 Currently DNS is optimized for small data transfers, generally not 363 exceeding 512 octets including overhead. Larger transfers are less 364 efficient but do work correctly and efforts are underway to make them 365 more efficient. 367 It is easy to create very large RRs or RR sets using SINK. DNS 368 administrators should think about this and may wish to discourage 369 large RRs or RR sets. Consideration should also be given to putting 370 zones from which large RRs or RR sets will be commonly retrieved on 371 separate hosts which can be tuned for the load this will represent. 373 5. Security Considerations 375 Since the SINK resource record can be used to store arbitrary data in 376 the DNS, this data could have security consequences, particularly if 377 it is control, executable, macro, or interpretable information or 378 very large and might cause buffer overflow. Due care should be 379 taken. 381 [RFC 2535] covers data original authentication of the data in the 382 domain name system including SINK RRs. 384 6. IANA Considerations 386 Assignment of specific meaning to the values listed herein as 387 "reserved" requires an IETF standards action. 389 All other assignments of available meaning, coding, or subcoding 390 octet values are by IETF consensus. 392 The many provisions for private indicita specified by separately 393 allocated OIDs, domain names, or URIs should cover most requirements 394 for private or proprietary values. 396 7. Full Copyright Statement 398 Copyright (C) The Internet Society (1999). All Rights Reserved. 400 This document and translations of it may be copied and furnished to 401 others, and derivative works that comment on or otherwise explain it 402 or assist in its implementation may be prepared, copied, published 403 and distributed, in whole or in part, without restriction of any 404 kind, provided that the above copyright notice and this paragraph are 405 included on all such copies and derivative works. However, this 406 document itself may not be modified in any way, such as by removing 407 the copyright notice or references to the Internet Society or other 408 Internet organizations, except as needed for the purpose of 409 developing Internet standards in which case the procedures for 410 copyrights defined in the Internet Standards process must be 411 followed, or as required to translate it into languages other than 412 English. 414 The limited permissions granted above are perpetual and will not be 415 revoked by the Internet Society or its successors or assigns. 417 This document and the information contained herein is provided on an 418 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 419 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 420 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 421 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 422 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 424 References 426 [RFC 1034] - P. Mockapetris, "Domain names - concepts and 427 facilities", 11/01/1987. 429 [RFC 1035] - P. Mockapetris, "Domain names - implementation and 430 specification", 11/01/1987. 432 [RFC 1642] - D. Goldsmith, M. Davis, "UTF-7 - A Mail-Safe 433 Transformation Format of Unicode", 07/13/1994. 435 [RFC 2044] - F. Yergeau, "UTF-8, a transformation format of Unicode 436 and ISO 10646", 10/30/1996. 438 [RFC 2045] - N. Freed, N. Borenstein, "Multipurpose Internet Mail 439 Extensions (MIME) Part One: Format of Internet Message Bodies", 440 12/02/1996. 442 [RFC 2046] - N. Freed, N. Borenstein, "Multipurpose Internet Mail 443 Extensions (MIME) Part Two: Media Types", 12/02/1996. 445 [RFC 2047] - K. Moore, "MIME (Multipurpose Internet Mail Extensions) 446 Part Three: Message Header Extensions for Non-ASCII Text", 447 12/02/1996. 449 [RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform 450 Resource Identifiers (URI): Generic Syntax", August 1998. 452 [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", 453 March 1999. 455 [X.680] - ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998, 456 Information Technology - Abstract Syntax Notation One (ASN.1): 457 Specification of Basic Notation 459 [X.681] - ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998, 460 Information Technology - Abstract Syntax Notation One (ASN.1): 461 Information Object Specification 463 [X.682] - ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998, 464 Information Technology - Abstract Syntax Notation One (ASN.1): 465 Constraint Specification 467 [X.683] - ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998, 468 Information Technology - Abstract Syntax Notation One (ASN.1): 469 Parameterization of ASN.1 Specifications 471 [X.690] - ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998, 472 Information Technology - ASN.1 Encoding Rules: Specification of Basic 473 Encoding Rules (BER), Canonical Encoding Rules (CER) and 474 Distinguished Encoding Rules (DER) 476 [X.691] - ITU-T Recommendation X.691 (1997) | ISO/IEC 8825-2:1998, 477 Information Technology - ASN.1 Encoding Rules: Specification of 478 Packed Encoding Rules (PER) 480 Author's Address 482 Donald E. Eastlake 3rd 483 IBM 484 65 Shindegan Hill Road 485 Carmel, 10512 USA 487 Telephone: +1 914-276-2668 (h) 488 +1 914-784-7913 (w) 489 FAX: +1 914-784-3833 (w) 490 EMail: dee3@us.ibm.com 492 Expiration and File Name 494 This draft expires March 2000. 496 Its file name is draft-ietf-dnsind-kitchen-sink-02.txt.