doc/expired/draft-ietf-dnsind-kitchen-sink-02.txt

   1 INTERNET-DRAFT                                   Donald E. Eastlake, 3rd
   2                                                                      IBM
   3 Expires March 2000                                        September 1999
   4 draft-ietf-dnsind-kitchen-sink-02.txt
   5
   6
   7
   8                   The Kitchen Sink DNS Resource Record
   9                   --- ------- ---- --- -------- ------
  10
  11                          Donald E. Eastlake 3rd
  12
  13
  14
  15 Status of This Document
  16
  17    This draft, file name draft-ietf-dnsind-kitchen-sink-02.txt, is
  18    intended to be become an Experimental RFC.  Distribution of this
  19    document is unlimited. Comments should be sent to
  20    <namedroppers@internic.net> or to the author.
  21
  22    This document is an Internet-Draft and is in full conformance with
  23    all provisions of Section 10 of RFC2026.  Internet-Drafts are working
  24    documents of the Internet Engineering Task Force (IETF), its areas,
  25    and its working groups.  Note that other groups may also distribute
  26    working documents as Internet-Drafts.
  27
  28    Internet-Drafts are draft documents valid for a maximum of six
  29    months.  Internet-Drafts may be updated, replaced, or obsoleted by
  30    other documents at any time.  It is not appropriate to use Internet-
  31    Drafts as reference material or to cite them other than as a
  32    ``working draft'' or ``work in progress.''
  33
  34    The list of current Internet-Drafts can be accessed at
  35    http://www.ietf.org/ietf/1id-abstracts.txt
  36
  37    The list of Internet-Draft Shadow Directories can be accessed at
  38    http://www.ietf.org/shadow.html.
  39
  40
  41
  42 Copyright Notice
  43
  44    Copyright (C) The Internet Society (1999).  All Rights Reserved
  45
  46
  47
  48 Abstract
  49
  50    Periodically people desire to put proprietary, complex, and/or
  51    obscure data into the Domain Name System (DNS).  This draft defines a
  52    kitchen sink Resource Record that will satisfy this desire for the
  53    storage of miscellaneous structured information.
  54
  55
  56
  57
  58 D. Eastlake 3rd                                                 [Page 1]
  59 \f
  60
  61 INTERNET-DRAFT                          The Kitchen Sink Resource Record
  62
  63
  64 Acknowledgements
  65
  66    The suggestions or information provided by the following persons have
  67    improved this document and they are gratefully acknowledged:
  68
  69             Rob Austein
  70             Matt Crawford
  71             Johnny Eriksson
  72             Phillip H. Griffin
  73             Michael A. Patton
  74             David Singer
  75
  76
  77
  78 Table of Contents
  79
  80       Status of This Document....................................1
  81       Copyright Notice...........................................1
  82       Abstract...................................................1
  83
  84       Acknowledgements...........................................2
  85       Table of Contents..........................................2
  86
  87       1. Introduction............................................3
  88       2. Kitchen Sink Resource Record............................3
  89       2.1 The Meaning Octet......................................4
  90       2.2 The Coding and Subcoding Octets........................5
  91       2.2.1 ASN.1 Subcodings.....................................7
  92       2.2.2 MIME Subcodings......................................7
  93       2.2.3 Text Subcodings......................................8
  94       3. Master File Representation..............................8
  95       4. Performance Considerations..............................9
  96       5. Security Considerations.................................9
  97       6. IANA Considerations.....................................9
  98       7. Full Copyright Statement................................9
  99
 100       References................................................11
 101       Author's Address..........................................12
 102       Expiration and File Name..................................12
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116 D. Eastlake 3rd                                                 [Page 2]
 117 \f
 118
 119 INTERNET-DRAFT                          The Kitchen Sink Resource Record
 120
 121
 122 1. Introduction
 123
 124    The Domain Name System (DNS) provides a replicated distributed secure
 125    hierarchical database which stores "resource records" (RRs) under
 126    hierarchical domain names.  This data is structured into zones which
 127    are independently maintained.  [RFC 1034, 1035, 2535]
 128
 129    Numerous types of RRs have been defined.  These support such critical
 130    functions as host name to address translation (A, AAAA, etc.  RRs),
 131    automatic mail routing (MX etc. RRs), and other functions. In
 132    addition, there are RRs defined related to the zone structure and
 133    administration of the DNS (SOA, NS, and RP RRs), security (SIG, KEY,
 134    and NXT RRs), etc.  There is a TXT RR for the inclusion of general
 135    human readable text.
 136
 137    New RRs that are reasonably simple and designed via the open IETF
 138    standards process are periodically added as new needs become
 139    apparent.  But there are people who want to put some proprietary,
 140    complex and/or non-standard structured data in the DNS.  In the past
 141    they have frequently come up with some way of reinterpreting the TXT
 142    RR, since that is one of the least constrained RRs.  This is likely a
 143    bad idea since all previous ways to reinterpreting the TXT RR have
 144    sunk without a trace.  (Well, if they actually got an RFC out, it's
 145    still there, but, practically speaking, almost nobody actually uses
 146    it.)
 147
 148    If a new type of data is needed for a global interoperable use in the
 149    DNS, the best course is to design a new RR that meets the need
 150    through the IETF standards process.  This draft defines an extremely
 151    general and flexible RR which can be used for other data, such as
 152    proprietary data, where global interoperability is not a
 153    consideration.  It includes representations of OSI ASN.1, MIME, XML,
 154    and, recursively, DNS RRs.
 155
 156
 157
 158 2. Kitchen Sink Resource Record
 159
 160    The symbol for the kitchen sink resource record is SINK.  Its type
 161    number is 40.  This type is defined across all DNS classes.
 162
 163    The RDATA portion of the SINK RR is structured as follows:
 164
 165
 166
 167
 168
 169
 170
 171
 172
 173
 174 D. Eastlake 3rd                                                 [Page 3]
 175 \f
 176
 177 INTERNET-DRAFT                          The Kitchen Sink Resource Record
 178
 179
 180                                           1  1  1  1  1  1
 181             0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
 182           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 183           |        meaning        |        coding         |
 184           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 185           |       subcoding       |                       /
 186           +--+--+--+--+--+--+--+--+                       /
 187           /                             data              /
 188           /                                               /
 189           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 190
 191    The "meaning", "coding", and "subcoding" octets are always present.
 192    The "data" portion is variable length and could be null in some
 193    cases.  The size of the "data" portion can always be determined by
 194    subtracting 3 from the SINK resource record RDLENGTH.  The coding
 195    octet gives the general structure of the data.  The subcoding octet
 196    provides additional information depending on the value of the coding
 197    nibble.
 198
 199    All references to "domain name" in this document mean a domain name
 200    in the DNS CLASS of the SINK RR.
 201
 202
 203
 204 2.1 The Meaning Octet
 205
 206    The meaning octet indicates whether any semantic tagging appears at
 207    the beginning of the data field and the format of such semantic
 208    tagging.  This contrasts with the coding and subcoding octets which
 209    merely indicate format.  The inclusion of such semantic tagging is
 210    encouraged and it is expected to be the primary means by which
 211    applications determine if a SINK RR is of the variety in which they
 212    have interest.
 213
 214    It is noted that multiple popular uses of SINK could develop that are
 215    not distinguished by using different parts of the DNS name space or
 216    different DNS classes.  If this occurs, retrievals may fetch large
 217    sets of SINK RR to be sorted through at the application level.
 218    Should this occur, such popular uses of SINK should obtain and
 219    migrate to their own RR number using normal RR number allocation
 220    procedures.  In addition, it would be possible to define an extended
 221    query operation that selects from among SINK RRs based on the
 222    semantic tag.
 223
 224    The types of tags available are chosen to be globally unique and
 225    under the control of some "owner".  The owner designates the meaning
 226    associated with the tags they control.  Where the tag is a URI, it is
 227    recommended that a retrieval from the URI fetch material that would
 228    be helpful in determining this meaning.  No a priori method is
 229    defined for determining the meaning of other tags beside an out of
 230
 231
 232 D. Eastlake 3rd                                                 [Page 4]
 233 \f
 234
 235 INTERNET-DRAFT                          The Kitchen Sink Resource Record
 236
 237
 238    band question to the owner.
 239
 240         INITIAL ASSIGNED MEANING VALUES
 241
 242      0 - reserved.
 243
 244      1 - none.
 245      2 - OID.
 246      3 - domain name.
 247      4 - URI.
 248
 249      5-254 - available for assignment, see section 6.
 250
 251      255 - reserved.
 252
 253    A meaning octet value of 1 indicates that there is no semantic
 254    tagging at the beginning of the data area.  The information, whatever
 255    it is, starts at the beginning of the data field and is coded
 256    according to the coding and subcoding octets.
 257
 258    Meaning octet values of 2, 3, or 4, indicate, on the other hand, that
 259    a semantic tag is present.  A value of two indicates that a BER
 260    [X.690] encoded OID appears prefixed by a single unsigned octet of
 261    OID length count.  A value of three indicates that a DNS domain name
 262    appears in wire format with name compression prohibited.  And a value
 263    of four indicates that a null (zero) octet terminated URI appears.
 264
 265
 266
 267 2.2 The Coding and Subcoding Octets
 268
 269    The coding octet gives the major method by which the data in the data
 270    field is encoded.  It should always have a meaningful value.  The
 271    subcoding octet is intended to give additional coding details.
 272    Although the subcoding octet is always present, it must be
 273    interpreted in the context of the coding octet.  For any coding octet
 274    value which does not specify subcoding octet value meanings, the
 275    subcoding octet MUST be ignored and SHOULD be zero.
 276
 277    While not explicitly mentioned below, the data field will actually
 278    start with a semantic tag if indicated by the meaning octet.  If such
 279    a semantic tag is present, any data prefix required by the coding or
 280    subcoding octet is placed after the semantic tag and before the data.
 281
 282    CODING OCTET VALUES
 283
 284         0 - reserved.
 285
 286         1 - DNS RRs. The data portion consists of DNS resource records
 287         as they would be transmitted in a DNS response section.  The
 288
 289
 290 D. Eastlake 3rd                                                 [Page 5]
 291 \f
 292
 293 INTERNET-DRAFT                          The Kitchen Sink Resource Record
 294
 295
 296         subcoding octet is the number of RRs in the data area as an
 297         unsigned integer.  Domain names may be compressed via pointers
 298         as in DNS replies.  The origin for the pointers is the beginning
 299         of the RDATA section of the SINK RR.  Thus the SINK RR is safe
 300         to cache since only code that knows how to parse the data
 301         portion of a SINK RR need know of and can expand these
 302         compressions.
 303
 304         2 - MIME structured data [RFC 2045, 2046].  The data portion is
 305         a MIME structured message.  The "MIME-Version:" header line may
 306         be omitted unless the version is other than "1.0".  The top
 307         level Content-Transfer-Encoding may be encoded into the
 308         subcoding octet (see section 2.2.2).  Note that, to some extent,
 309         the size limitations of DNS RRs may be overcome in the MIME case
 310         by using the "Content-Type: message/external-body" mechanism.
 311
 312         3 - Text tagged data.  The data potion consists of text formated
 313         as specified in the TXT RR except that the first and every
 314         subsequent odd numbered text item is considered to be a tag
 315         labeling the immediately following text item.  If there are an
 316         odd number of text items overall, then the last is considered to
 317         label a null text item.  Syntax of the tags is as specified in
 318         RFC 2396 for the "Authority Component" without the two leading
 319         slashes ("//") or trailing slash using the DNS for authority.
 320         Thus any organization with a domain name can assign tags without
 321         fear of conflict.  The subcodings octet specifies the encoding
 322         of the labeled text items as specified in section 2.2.3.
 323
 324         4 - HTML.  The subcoding octet indicates the version of HTML
 325         with the major version number in the upper nibble and the minor
 326         version number in the lower nibble.  Thus, for example, HTML 3.2
 327         would be indicated by a 0x32 octet.
 328
 329         5 - XML.  The subcoding octet is the version of XML, currently
 330         1.
 331
 332         6 - ASN.1 [X.680, etc.].  See section 2.2.1.
 333
 334         7-251 - Available for assignment, see section 6.
 335
 336         252 - Private coding format indicated by an OID.  The format of
 337         the data portion is indicated by an initial BER encoded OID
 338         which is prefixed by a one octet unsigned length count for the
 339         OID.  The subcoding octet is available for whatever use the
 340         private formating wishes to make of it.
 341
 342         253 - Private coding format indicated by a domain name.  The
 343         format of the data portion is indicated by an initial wire
 344         format domain name with compression prohibited.  (Such names are
 345         self delimiting.) The subcoding octet is available for whatever
 346
 347
 348 D. Eastlake 3rd                                                 [Page 6]
 349 \f
 350
 351 INTERNET-DRAFT                          The Kitchen Sink Resource Record
 352
 353
 354         use the private formating wishes to make of it.
 355
 356         254 - Private coding format indicated by a URI.  The format of
 357         the data portion is indicated by an initial URI [RFC 2396] which
 358         is terminated by a zero (null) valued octet followed by the data
 359         with that format.  The subcoding octet is available for whatever
 360         use the private formating wishes to make of it.  The manner in
 361         which the URI specifies the format is not defined but presumably
 362         the retriever will recognize the URI by some pattern match.
 363
 364         255 - reserved.
 365
 366    NOTE: the existence of a DNS RR coding and the infinite possibilities
 367    of ASN.1, XML, and MIME permit one to SINK to even greater depths by
 368    nesting.
 369
 370
 371
 372 2.2.1 ASN.1 Subcodings
 373
 374    For ASN.1 [X.680, etc.] data, a specific concrete encoding must be
 375    chosen as indicated by the subcoding octet.
 376
 377    ASN.* SUBCODINGS
 378
 379    0 - reserved.
 380    1 - BER ( Basic Encoding Rules [X.690] ).
 381    2 - DER ( Distinguished Encoding Rules [X.690] ).
 382    3 - PER ( Packed Encoding Rules ) Aligned [X.691].
 383    4 - PER Unaligned [X.691].
 384    5 - CER ( Canonical Encoding Rules [X.690] ).
 385    6-253 - available for assignment, see section 6.
 386    254 - private.  This subcoding will never be assigned to a standard
 387         set of encoding rules.  An OID preceded by a one octet unsigned
 388         length of OID appears at the beginning of the data area after
 389         the ASN coding OID.
 390    255 - reserved.
 391
 392
 393
 394 2.2.2 MIME Subcodings
 395
 396    If the coding octet indicates the data is MIME structured, the
 397    precise encoding is given by the subcoding octets as listed below.
 398
 399    MIME SUBCODINGS
 400
 401    0 - reserved, see section 6.
 402    1 - 7bit.
 403    2 - 8bit.
 404
 405
 406 D. Eastlake 3rd                                                 [Page 7]
 407 \f
 408
 409 INTERNET-DRAFT                          The Kitchen Sink Resource Record
 410
 411
 412    3 - binary.
 413    4 - quoted-printable.
 414    5 - base64.
 415    6 - 253 - available for assignment, see section 6.
 416    254 - private.  The data portion must start with an "x-" or "X-"
 417         token denoting the private content-transfer-encoding immediately
 418         followed by one null (zero) octet followed by the remainder of
 419         the MIME object.
 420    255 - reserved, see section 6.
 421
 422
 423
 424 2.2.3 Text Subcodings
 425
 426    If the coding octet indicates the data is text, the exact encoding of
 427    the text items is indicated by the subcoding octet as follows:
 428
 429    TEXT SUBCODINGS
 430
 431    0 - reserved, see section 6.
 432    1 - ASCII.
 433    2 - UTF-7 [RFC 1642].
 434    3 - UTF-8 [RFC 2044].
 435    4 - ASCII with MIME header escapes [RFC 2047].
 436    5 - 253 - available for assignment, see section 6.
 437    254 - private.  Each text item must start with a domain name [RFC
 438         1034] in wire format without compression denoting the private
 439         text encoding immediately followed by the remainder of the text
 440         item.
 441    255 - reserved, see section 6.
 442
 443
 444
 445 3. Master File Representation
 446
 447    SINK resource records may appear as lines in zone master files.  The
 448    meaning, coding, and subcoding appear as unsigned decimal integers.
 449    The data portion can be quite long.  It is represented in base 64
 450    [RFC 2045] and may be divided up into any number of white space
 451    separated substrings, down to single base 64 digits, which are
 452    concatenated to obtain the full data.  These substrings can span
 453    lines using the standard parenthesis notation.  (This type of base64
 454    master file data is also required to support the DNS KEY and SIG
 455    security RRs [RFC 2535].)
 456
 457
 458
 459
 460
 461
 462
 463
 464 D. Eastlake 3rd                                                 [Page 8]
 465 \f
 466
 467 INTERNET-DRAFT                          The Kitchen Sink Resource Record
 468
 469
 470 4. Performance Considerations
 471
 472    Currently DNS is optimized for small data transfers, generally not
 473    exceeding 512 octets including overhead.  Larger transfers are less
 474    efficient but do work correctly and efforts are underway to make them
 475    more efficient.
 476
 477    It is easy to create very large RRs or RR sets using SINK.  DNS
 478    administrators should think about this and may wish to discourage
 479    large RRs or RR sets.  Consideration should also be given to putting
 480    zones from which large RRs or RR sets will be commonly retrieved on
 481    separate hosts which can be tuned for the load this will represent.
 482
 483
 484
 485 5. Security Considerations
 486
 487    Since the SINK resource record can be used to store arbitrary data in
 488    the DNS, this data could have security consequences, particularly if
 489    it is control, executable, macro, or interpretable information or
 490    very large and might cause buffer overflow.  Due care should be
 491    taken.
 492
 493    [RFC 2535] covers data original authentication of the data in the
 494    domain name system including SINK RRs.
 495
 496
 497
 498 6. IANA Considerations
 499
 500    Assignment of specific meaning to the values listed herein as
 501    "reserved" requires an IETF standards action.
 502
 503    All other assignments of available meaning, coding, or subcoding
 504    octet values are by IETF consensus.
 505
 506    The many provisions for private indicita specified by separately
 507    allocated OIDs, domain names, or URIs should cover most requirements
 508    for private or proprietary values.
 509
 510
 511
 512 7. Full Copyright Statement
 513
 514    Copyright (C) The Internet Society (1999).  All Rights Reserved.
 515
 516    This document and translations of it may be copied and furnished to
 517    others, and derivative works that comment on or otherwise explain it
 518    or assist in its implementation may be prepared, copied, published
 519    and distributed, in whole or in part, without restriction of any
 520
 521
 522 D. Eastlake 3rd                                                 [Page 9]
 523 \f
 524
 525 INTERNET-DRAFT                          The Kitchen Sink Resource Record
 526
 527
 528    kind, provided that the above copyright notice and this paragraph are
 529    included on all such copies and derivative works.  However, this
 530    document itself may not be modified in any way, such as by removing
 531    the copyright notice or references to the Internet Society or other
 532    Internet organizations, except as needed for the purpose of
 533    developing Internet standards in which case the procedures for
 534    copyrights defined in the Internet Standards process must be
 535    followed, or as required to translate it into languages other than
 536    English.
 537
 538    The limited permissions granted above are perpetual and will not be
 539    revoked by the Internet Society or its successors or assigns.
 540
 541    This document and the information contained herein is provided on an
 542    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 543    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 544    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 545    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 546    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562
 563
 564
 565
 566
 567
 568
 569
 570
 571
 572
 573
 574
 575
 576
 577
 578
 579
 580 D. Eastlake 3rd                                                [Page 10]
 581 \f
 582
 583 INTERNET-DRAFT                          The Kitchen Sink Resource Record
 584
 585
 586 References
 587
 588    [RFC 1034] - P. Mockapetris, "Domain names - concepts and
 589    facilities", 11/01/1987.
 590
 591    [RFC 1035] - P. Mockapetris, "Domain names - implementation and
 592    specification", 11/01/1987.
 593
 594    [RFC 1642] - D. Goldsmith, M. Davis, "UTF-7 - A Mail-Safe
 595    Transformation Format of Unicode", 07/13/1994.
 596
 597    [RFC 2044] - F. Yergeau, "UTF-8, a transformation format of Unicode
 598    and ISO 10646", 10/30/1996.
 599
 600    [RFC 2045] - N. Freed, N. Borenstein, "Multipurpose Internet Mail
 601    Extensions (MIME) Part One:  Format of Internet Message Bodies",
 602    12/02/1996.
 603
 604    [RFC 2046] - N. Freed, N. Borenstein, "Multipurpose Internet Mail
 605    Extensions (MIME) Part Two:  Media Types", 12/02/1996.
 606
 607    [RFC 2047] - K. Moore, "MIME (Multipurpose Internet Mail Extensions)
 608    Part Three: Message Header Extensions for Non-ASCII Text",
 609    12/02/1996.
 610
 611    [RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
 612    Resource Identifiers (URI): Generic Syntax", August 1998.
 613
 614    [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
 615    March 1999.
 616
 617    [X.680] - ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998,
 618    Information Technology - Abstract Syntax Notation One (ASN.1):
 619    Specification of Basic Notation
 620
 621    [X.681] - ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998,
 622    Information Technology - Abstract Syntax Notation One (ASN.1):
 623    Information Object Specification
 624
 625    [X.682] - ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998,
 626    Information Technology - Abstract Syntax Notation One (ASN.1):
 627    Constraint Specification
 628
 629    [X.683] - ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998,
 630    Information Technology - Abstract Syntax Notation One (ASN.1):
 631    Parameterization of ASN.1 Specifications
 632
 633    [X.690] - ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998,
 634    Information Technology - ASN.1 Encoding Rules: Specification of Basic
 635    Encoding Rules (BER), Canonical Encoding Rules (CER) and
 636
 637
 638 D. Eastlake 3rd                                                [Page 11]
 639 \f
 640
 641 INTERNET-DRAFT                          The Kitchen Sink Resource Record
 642
 643
 644    Distinguished Encoding Rules (DER)
 645
 646    [X.691] - ITU-T Recommendation X.691 (1997) | ISO/IEC 8825-2:1998,
 647    Information Technology - ASN.1 Encoding Rules: Specification of
 648    Packed Encoding Rules (PER)
 649
 650
 651
 652 Author's Address
 653
 654    Donald E. Eastlake 3rd
 655    IBM
 656    65 Shindegan Hill Road
 657    Carmel, 10512 USA
 658
 659    Telephone:   +1 914-276-2668 (h)
 660                 +1 914-784-7913 (w)
 661    FAX:         +1 914-784-3833 (w)
 662    EMail:       dee3@us.ibm.com
 663
 664
 665
 666 Expiration and File Name
 667
 668    This draft expires March 2000.
 669
 670    Its file name is draft-ietf-dnsind-kitchen-sink-02.txt.
 671
 672
 673
 674
 675
 676
 677
 678
 679
 680
 681
 682
 683
 684
 685
 686
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696 D. Eastlake 3rd                                                [Page 12]
 697 \f