idnits 2.17.1 draft-ietf-dnsind-kitchen-sink-01.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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 65 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 204: '... subcoding octet MUST be ignored and S...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (August 1999) is 9020 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 88 -- Looks like a reference, but probably isn't: '2535' on line 88 -- Looks like a reference, but probably isn't: '2046' on line 226 == Unused Reference: 'RFC 1035' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'RFC 2046' is defined on line 410, 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 February 2000 August 1999 5 draft-ietf-dnsind-kitchen-sink-01.txt 7 The Kitchen Sink DNS Resource Record 8 --- ------- ---- --- -------- ------ 10 Donald E. Eastlake 3rd 12 Status of This Document 14 This draft, file name draft-ietf-dnsind-kitchen-sink-01.txt, is 15 intended to be become a Proposed Standard RFC. Distribution of this 16 document is unlimited. Comments should be sent to 17 or to the author. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months. Internet-Drafts may be updated, replaced, or obsoleted by 27 other documents at any time. It is not appropriate to use Internet- 28 Drafts as reference material or to cite them other than as a 29 ``working draft'' or ``work in progress.'' 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 To view the entire list of current Internet-Drafts, please check the 38 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 39 Directories as listed at . 41 Abstract 43 Periodically people desire to put proprietary, complex, and/or 44 obscure data into the Domain Name System (DNS). This draft defines a 45 kitchen sink Resource Record that will satisfy this desire for the 46 storage of miscellaneous structured information. 48 Acknowledgements 50 The suggestions or information provided by the following persons have 51 improved this document and they are gratefully acknowledged: 53 Rob Austein 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 Abstract...................................................1 64 Acknowledgements...........................................2 65 Table of Contents..........................................2 67 1. Introduction............................................3 68 2. Kitchen Sink Resource Record............................3 69 2.1 The Meaning Octet......................................4 70 2.2 The Coding and Subcoding Octets........................5 71 2.2.1 ASN.1 Subcodings.....................................7 72 2.2.2 MIME Subcodings......................................7 73 2.2.3 Text Subcodings......................................8 74 3. Master File Representation..............................8 75 4. Performance Considerations..............................8 76 5. Security Considerations.................................9 77 6. IANA Considerations.....................................9 79 References................................................10 80 Author's Address..........................................11 81 Expiration and File Name..................................11 83 1. Introduction 85 The Domain Name System (DNS) provides a replicated distributed secure 86 hierarchical database which stores "resource records" (RRs) under 87 hierarchical domain names. This data is structured into zones which 88 are independently maintained. [RFC 1034, 1035, 2535] 90 Numerous types of RRs have been defined. These support such critical 91 functions as host name to address translation (A, AAAA, etc. RRs), 92 automatic mail routing (MX etc. RRs), and other functions. In 93 addition, there are RRs defined related to the zone structure and 94 administration of the DNS (SOA, NS, and RP RRs), security (SIG, KEY, 95 and NXT RRs), etc. There is a TXT RR for the inclusion of general 96 human readable text. 98 New RRs that are reasonably simple and designed via the open IETF 99 standards process are periodically added as new needs become 100 apparent. But there are periodically people who want to put some 101 proprietary, complex and/or non-standard structured data in the DNS. 102 In the past they have frequently come up with some way of 103 reinterpreting the TXT RR, since that is one of the least constrained 104 RRs. This is likely a bad idea since all previous ways to 105 reinterpreting the TXT RR have sunk without a trace. (Well, if they 106 actually got an RFC out, it's still there, but, practically speaking, 107 almost nobody actually uses it.) 109 If a new type of data is needed for a global interoperable use in the 110 DNS, the best course is to design a new RR that meets the need 111 through the IETF standards process. This draft defines an extremely 112 general and flexible RR which can be used for other data, such as 113 proprietary data, where global interoperability is not a 114 consideration. It includes representations of OSI ASN.1, MIME, XML, 115 and, recursively, DNS RRs. 117 2. Kitchen Sink Resource Record 119 The symbol for the kitchen sink resource record is SINK. Its type 120 number is 40. This type is defined across all DNS classes. 122 The RDATA portion of the SINK RR is structured as follows: 124 1 1 1 1 1 1 125 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 126 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 127 | meaning | coding | 128 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 129 | subcoding | / 130 +--+--+--+--+--+--+--+--+ / 131 / data / 132 / / 133 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 135 The "meaning", "coding", and "subcoding" octets are always present. 136 The "data" portion is variable length and could be null in some 137 cases. The size of the "data" portion can always be determined by 138 subtracting 3 from the SINK resource record RDLENGTH. The coding 139 octet gives the general structure of the data. The subcoding octet 140 provides additional information depending on the value of the coding 141 nibble. 143 All references to "domain name" in this document mean domain name in 144 the IP DNS class. 146 Although it is unlikely, it is noted that multiple popular uses of 147 SINK might develop that are not distinguished by using different 148 parts of the DNS name space or different DNS classes. If this 149 occurs, retrievals may fetch large sets of SINK RRs which will likely 150 have to be sorted through at the application level. Should this 151 occur, such popular uses of SINK should obtain and migrate to their 152 own RR number using normal RR number allocation procedures or it 153 would be possible to define an extended query operation that used a 154 more fine grained selection method than just the RR type. 156 2.1 The Meaning Octet 158 The meaning octet indicates whether any semantic labeling appears at 159 the beginning of the data field and the format of such semantic 160 labeling. This contrasts with the coding and subcoding octets which 161 merely indicate format. 163 The types of labels available are chosen to be globally unique and 164 under the control of some "owner". The owner designates the meaning 165 associated with the labels they control. Where the label is a URI, 166 it is recommended that a retrieval from the URI fetch material that 167 would be helpful in determining this meaning. No a priori method is 168 defined for determining the meaning of other labels beside an out of 169 band question to the owner. 171 INITIAL ASSIGNED MEANING VALUES 173 0 - reserved. 175 1 - none. 176 2 - OID. 177 3 - domain name. 178 4 - URI. 180 5-254 - available for assignment, see section 6. 182 255 - reserved. 184 A meaning octet value of 1 indicates that there is no semantic 185 labeling at the beginning of the data area. The information, 186 whatever it is, starts at the beginning of the data field and is 187 coded according to the coding and subcoding octets. 189 Meaning octet values of 2, 3, or 4, indicate, on the other hand, that 190 a semantic label is present. A value of two indicates that a BER 191 [X.690] encoded OID appears prefixed by a single unsigned octet of 192 OID length count. A value of three indicates that a DNS domain name 193 appears in wire format with name compression prohibited. And a value 194 of four indicates that a null (zero) octet terminated URI appears. 196 2.2 The Coding and Subcoding Octets 198 The coding octet gives the major method by which the data in the data 199 field is encoded. It should always have a meaningful value. The 200 subcoding octet is intended to give additional coding details. 201 Although the subcoding octet is always present, it must be 202 interpreted in the context of the coding octet. For any coding octet 203 value which does not specify subcoding octet value meanings, the 204 subcoding octet MUST be ignored and SHOULD be zero. 206 While not explicitly mentioned below, the data field will actually 207 start with a semantic label if indicated by the meaning octet. If 208 such a semantic label is present, any data prefix required by the 209 coding or subcoding octet is placed after the semantic label and 210 before the data. 212 CODING OCTET VALUES 214 0 - reserved. 216 1 - DNS RRs. The data portion consists of DNS resource records 217 as they would be transmitted in a DNS response section. The 218 subcoding octet is the number of RRs in the data area as an 219 unsigned integer. Domain names may be compressed via pointers 220 as in DNS replies. The origin for the pointers is the beginning 221 of the RDATA section of the SINK RR. Thus the SINK RR is safe 222 to cache since only code that knows how to parse the data 223 portion of a SINK RR need know of and can expand these 224 compressions. 226 2 - MIME structured data [RFC 2045, 2046]. The data portion is 227 a MIME structured message. The "MIME-Version:" header line may 228 be omitted unless the version is other than "1.0". The top 229 level Content-Transfer-Encoding may be encoded into the 230 subcoding octet (see section 2.2.2). Note that, to some extent, 231 the size limitations of DNS RRs may be overcome in the MIME case 232 by using the "Content-Type: message/external-body" mechanism. 234 3 - Text tagged data. The data potion consists of text formated 235 as specified in the TXT RR except that the first and every 236 subsequent odd numbered text item is considered to be a tag 237 labeling the immediately following text item. If there are an 238 odd number of text items overall, then the last is considered to 239 label a null text item. Syntax of the tags is as specified in 240 RFC 2396 for the "Authority Component" without the two leading 241 slashes ("//") or trailing slash using the DNS for authority. 242 Thus any organization with a domain name can assign tags without 243 fear of conflict. The subcodings octet specifies the encoding 244 of the labeled text items as specified in section 2.2.3. 246 4 - HTML. The subcoding octet indicates the version of HTML 247 with the major version number in the upper nibble and the minor 248 version number in the lower nibble. Thus, for example, HTML 3.2 249 would be indicated by a 0x32 octet. 251 5 - XML. The subcoding octet is the version of XML, currently 252 1. 254 6 - ASN.1 [X.680, etc.]. See section 2.2.1. 256 7-251 - Available for assignment, see section 6. 258 252 - Private coding format indicated by an OID. The format of 259 the data portion is indicated by an initial BER encoded OID 260 which is prefixed by a one octet unsigned length count for the 261 OID. The subcoding octet is available for whatever use the 262 private formating wishes to make of it. 264 253 - Private coding format indicated by a domain name. The 265 format of the data portion is indicated by an initial wire 266 format domain name with compression prohibited. (Such names are 267 self delimiting.) The subcoding octet is available for whatever 268 use the private formating wishes to make of it. 270 254 - Private coding format indicated by a URI. The format of 271 the data portion is indicated by an initial URI [RFC 2396] which 272 is terminated by a zero (null) valued octet followed by the data 273 with that format. The subcoding octet is available for whatever 274 use the private formating wishes to make of it. The manner in 275 which the URI specifies the format is not defined but presumably 276 the retriever will recognize the URI by some pattern match. 278 255 - reserved. 280 NOTE: the existence of a DNS RR coding and the infinite possibilities 281 of ASN.1, XML, and MIME permit one to SINK to even greater depths by 282 nesting. 284 2.2.1 ASN.1 Subcodings 286 For ASN.1 [X.680, etc.] data, a specific concrete encoding must be 287 chosen as indicated by the subcoding octet. 289 ASN.* SUBCODINGS 291 0 - reserved. 292 1 - BER ( Basic Encoding Rules [X.690] ). 293 2 - DER ( Distinguished Encoding Rules [X.690] ). 294 3 - PER ( Packed Encoding Rules ) Aligned [X.691]. 295 4 - PER Unaligned [X.691]. 296 5 - CER ( Canonical Encoding Rules [X.690] ). 297 6-253 - available for assignment, see section 6. 298 254 - private. This subcoding will never be assigned to a standard 299 set of encoding rules. An OID preceded by a one octet unsigned 300 length of OID appears at the beginning of the data area after 301 the ASN coding OID. 302 255 - reserved. 304 2.2.2 MIME Subcodings 306 If the coding octet indicates the data is MIME structured, the 307 precise encoding is given by the subcoding octets as listed below. 309 MIME SUBCODINGS 311 0 - reserved, see section 6. 312 1 - 7bit. 313 2 - 8bit. 314 3 - binary. 315 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 notation. (This type of base64 353 master file data is also required to support the DNS KEY and SIG 354 security RRs [RFC 2535].) 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 about this and may wish to discourage 365 large RRs or RR sets. Consideration should also be given to putting 366 zones from which large RRs or RR sets will be commonly retrieved on 367 separate hosts which can be tuned for the load this will represent. 369 5. Security Considerations 371 Since the SINK resource record can be used to store arbitrary data in 372 the DNS, this data could have security consequences, particularly if 373 it is control, executable, macro, or interpretable information or 374 very large and might cause buffer overflow. Due care should be 375 taken. 377 [RFC 2535] covers data original authentication of the data in the 378 domain name system including SINK RRs. 380 6. IANA Considerations 382 Assignment of specific meaning to the values listed herein as 383 "reserved" requires an IETF standards action. 385 All other assignments of available meaning, coding, or subcoding 386 octet values are by IETF consensus. 388 The many provisions for private indicita specified by separately 389 allocated OIDs, domain names, or URIs should cover most requirements 390 for private or proprietary values. 392 References 394 [RFC 1034] - P. Mockapetris, "Domain names - concepts and 395 facilities", 11/01/1987. 397 [RFC 1035] - P. Mockapetris, "Domain names - implementation and 398 specification", 11/01/1987. 400 [RFC 1642] - D. Goldsmith, M. Davis, "UTF-7 - A Mail-Safe 401 Transformation Format of Unicode", 07/13/1994. 403 [RFC 2044] - F. Yergeau, "UTF-8, a transformation format of Unicode 404 and ISO 10646", 10/30/1996. 406 [RFC 2045] - N. Freed, N. Borenstein, "Multipurpose Internet Mail 407 Extensions (MIME) Part One: Format of Internet Message Bodies", 408 12/02/1996. 410 [RFC 2046] - N. Freed, N. Borenstein, "Multipurpose Internet Mail 411 Extensions (MIME) Part Two: Media Types", 12/02/1996. 413 [RFC 2047] - K. Moore, "MIME (Multipurpose Internet Mail Extensions) 414 Part Three: Message Header Extensions for Non-ASCII Text", 415 12/02/1996. 417 [RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform 418 Resource Identifiers (URI): Generic Syntax", August 1998. 420 [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", 421 March 1999. 423 [X.680] - ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998, 424 Information Technology - Abstract Syntax Notation One (ASN.1): 425 Specification of Basic Notation 427 [X.681] - ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998, 428 Information Technology - Abstract Syntax Notation One (ASN.1): 429 Information Object Specification 431 [X.682] - ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998, 432 Information Technology - Abstract Syntax Notation One (ASN.1): 433 Constraint Specification 435 [X.683] - ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998, 436 Information Technology - Abstract Syntax Notation One (ASN.1): 437 Parameterization of ASN.1 Specifications 439 [X.690] - ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998, 440 Information Technology - ASN.1 Encoding Rules: Specification of Basic 441 Encoding Rules (BER), Canonical Encoding Rules (CER) and 442 Distinguished Encoding Rules (DER) 444 [X.691] - ITU-T Recommendation X.691 (1997) | ISO/IEC 8825-2:1998, 445 Information Technology - ASN.1 Encoding Rules: Specification of 446 Packed Encoding Rules (PER) 448 Author's Address 450 Donald E. Eastlake 3rd 451 IBM 452 65 Shindegan Hill Road 453 Carmel, 10512 USA 455 Telephone: +1 914-276-2668 (h) 456 +1 914-784-7913 (w) 457 FAX: +1 914-784-3833 (w) 458 EMail: dee3@us.ibm.com 460 Expiration and File Name 462 This draft expires February 2000. 464 Its file name is draft-ietf-dnsind-kitchen-sink-01.txt.