external/bsd/bind/dist/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt

   1
   2
   3
   4
   5
   6
   7 INTERNET-DRAFT                                             A. Gustafsson
   8                                           Araneus Information Systems Oy
   9                                                       September 23, 2009
  10
  11 Intended status: Draft Standard
  12 Obsoletes: RFC3597
  13
  14            Handling of Unknown DNS Resource Record (RR) Types
  15                   draft-ietf-dnsext-rfc3597-bis-00.txt
  16
  17 Status of this Memo
  18
  19    This Internet-Draft is submitted to IETF in full conformance with the
  20    provisions of BCP 78 and BCP 79.
  21
  22    Internet-Drafts are working documents of the Internet Engineering
  23    Task Force (IETF), its areas, and its working groups. Note that other
  24    groups may also distribute working documents as Internet-Drafts.
  25
  26    Internet-Drafts are draft documents valid for a maximum of six months
  27    and may be updated, replaced, or obsoleted by other documents at any
  28    time. It is inappropriate to use Internet-Drafts as reference
  29    material or to cite them other than as "work in progress."
  30
  31    The list of current Internet-Drafts can be accessed at
  32    http://www.ietf.org/1id-abstracts.html
  33
  34    The list of Internet-Draft Shadow Directories can be accessed at
  35    http://www.ietf.org/shadow.html
  36
  37 Copyright Notice
  38
  39    Copyright (c) 2009 IETF Trust and the persons identified as the
  40    document authors. All rights reserved.
  41
  42    This document is subject to BCP 78 and the IETF Trust's Legal
  43    Provisions Relating to IETF Documents in effect on the date of
  44    publication of this document (http://trustee.ietf.org/license-info).
  45    Please review these documents carefully, as they describe your rights
  46    and restrictions with respect to this document.
  47
  48 Abstract
  49
  50    Extending the Domain Name System (DNS) with new Resource Record (RR)
  51    types should not requires changes to name server software.  This
  52    document specifies how new RR types are transparently handled by DNS
  53    software.
  54
  55
  56
  57
  58 Expires March 2010           Standards Track                    [Page 1]
  59 \f
  60 draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
  61
  62
  63 1.  Introduction
  64
  65    The DNS [RFC1034] is designed to be extensible to support new
  66    services through the introduction of new resource record (RR) types.
  67    Nevertheless, DNS implementations have historically required software
  68    changes to support new RR types, not only at the authoritative DNS
  69    server providing the new information and the client making use of it,
  70    but also at all slave servers for the zone containing it, and in some
  71    cases also at caching name servers and forwarders used by the client.
  72    Because the deployment of new DNS software is slow and expensive,
  73    this has been a significant impediment to supporting new services in
  74    the DNS.
  75
  76    [RFC3597] defined DNS implementation behavior and procedures for
  77    defining new RR types aimed at simplifying the deployment of new RR
  78    types by allowing them to be treated transparently by existing
  79    implementations.  Thanks to the widespread adoption of that
  80    specification, much of the DNS is now capable of handling new record
  81    types without software changes.
  82
  83    This document is a self-contained revised specification supplanting
  84    and obsoleting [RFC3597].
  85
  86 2.  Definitions
  87
  88    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  89    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  90    document are to be interpreted as described in [RFC2119].
  91
  92    An "RR of unknown type" is an RR whose RDATA format is not known to
  93    the DNS implementation at hand, and whose type is not an assigned
  94    QTYPE or Meta-TYPE as specified in [RFC5395] (section 3.1) nor within
  95    the range reserved in that section for assignment only to QTYPEs and
  96    Meta-TYPEs.  Such an RR cannot be converted to a type-specific text
  97    format, compressed, or otherwise handled in a type-specific way.
  98
  99    In the case of a type whose RDATA format is class specific, an RR is
 100    considered to be of unknown type when the RDATA format for that
 101    combination of type and class is not known.
 102
 103 3.  Transparency
 104
 105    To enable new RR types to be deployed without server changes, name
 106    servers and resolvers MUST handle RRs of unknown type transparently.
 107    That is, they must treat the RDATA section of such RRs as
 108    unstructured binary data, storing and transmitting it without change
 109    [RFC1123].
 110
 111
 112
 113
 114 Expires March 2010           Standards Track                    [Page 2]
 115 \f
 116 draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
 117
 118
 119    To ensure the correct operation of equality comparison (section 6)
 120    and of the DNSSEC canonical form (section 7) when an RR type is known
 121    to some but not all of the servers involved, servers MUST also
 122    exactly preserve the RDATA of RRs of known type, except for changes
 123    due to compression or decompression where allowed by section 4 of
 124    this document.  In particular, the character case of domain names
 125    that are not subject to compression MUST be preserved.
 126
 127 4.  Domain Name Compression
 128
 129    RRs containing compression pointers in the RDATA part cannot be
 130    treated transparently, as the compression pointers are only
 131    meaningful within the context of a DNS message.  Transparently
 132    copying the RDATA into a new DNS message would cause the compression
 133    pointers to point at the corresponding location in the new message,
 134    which now contains unrelated data.  This would cause the compressed
 135    name to be corrupted.
 136
 137    To avoid such corruption, servers MUST NOT compress domain names
 138    embedded in the RDATA of types that are class-specific or not well-
 139    known.  This requirement was stated in [RFC1123] without defining the
 140    term "well-known"; it is hereby specified that only the RR types
 141    defined in [RFC1035] are to be considered "well-known".
 142
 143    Receiving servers MUST decompress domain names in RRs of well-known
 144    type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
 145    NXT, NAPTR, and SRV to ensure interoperability with implementations
 146    predating [RFC3597].
 147
 148    Specifications for new RR types that contain domain names within
 149    their RDATA MUST NOT allow the use of name compression for those
 150    names, and SHOULD explicitly state that the embedded domain names
 151    MUST NOT be compressed.
 152
 153    As noted in [RFC1123], the owner name of an RR is always eligible for
 154    compression.
 155
 156 5.  Text Representation
 157
 158    In the "type" field of a master file line, an unknown RR type is
 159    represented by the word "TYPE" immediately followed by the decimal RR
 160    type number, with no intervening whitespace.  In the "class" field,
 161    an unknown class is similarly represented as the word "CLASS"
 162    immediately followed by the decimal class number.
 163
 164    This convention allows types and classes to be distinguished from
 165    each other and from TTL values, allowing the "[<TTL>] [<class>]
 166    <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
 167
 168
 169
 170 Expires March 2010           Standards Track                    [Page 3]
 171 \f
 172 draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
 173
 174
 175    [RFC1035] to both be unambiguously parsed.
 176
 177    The RDATA section of an RR of unknown type is represented as a
 178    sequence of white space separated words as follows:
 179
 180       The special token \# (a backslash immediately followed by a hash
 181       sign), which identifies the RDATA as having the generic encoding
 182       defined herein rather than a traditional type-specific encoding.
 183
 184       An unsigned decimal integer specifying the RDATA length in octets.
 185
 186       Zero or more words of hexadecimal data encoding the actual RDATA
 187       field, each containing an even number of hexadecimal digits.
 188
 189    If the RDATA is of zero length, the text representation contains only
 190    the \# token and the single zero representing the length.
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Expires March 2010           Standards Track                    [Page 4]
 227 \f
 228 draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
 229
 230
 231    An implementation MAY also choose to represent some RRs of known type
 232    using the above generic representations for the type, class and/or
 233    RDATA, which carries the benefit of making the resulting master file
 234    portable to servers where these types are unknown.  Using the generic
 235    representation for the RDATA of an RR of known type can also be
 236    useful in the case of an RR type where the text format varies
 237    depending on a version, protocol, or similar field (or several)
 238    embedded in the RDATA when such a field has a value for which no text
 239    format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
 240    0.
 241
 242    Even though an RR of known type represented in the \# format is
 243    effectively treated as an unknown type for the purpose of parsing the
 244    RDATA text representation, all further processing by the server MUST
 245    treat it as a known type and take into account any applicable type-
 246    specific rules regarding compression, canonicalization, etc.
 247
 248    The following are examples of RRs represented in this manner,
 249    illustrating various combinations of generic and type-specific
 250    encodings for the different fields of the master file format:
 251
 252       a.example.   CLASS32     TYPE731         \# 6 abcd (
 253                                                ef 01 23 45 )
 254       b.example.   HS          TYPE62347       \# 0
 255       e.example.   IN          A               \# 4 C0000201
 256       e.example.   CLASS1      TYPE1           192.0.2.1
 257
 258 6.  Equality Comparison
 259
 260    Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
 261    to be compared for equality.  Two RRs of the same unknown type are
 262    considered equal when their RDATA is bitwise equal.  To ensure that
 263    the outcome of the comparison is identical whether the RR is known to
 264    the server or not, specifications for new RR types MUST NOT specify
 265    type-specific comparison rules.
 266
 267    This implies that embedded domain names, being included in the
 268    overall bitwise comparison, are compared in a case-sensitive manner.
 269
 270    As a result, when a new RR type contains one or more embedded domain
 271    names, it is possible to have multiple RRs owned by the same name
 272    that differ only in the character case of the embedded domain
 273    name(s).  This is similar to the existing possibility of multiple TXT
 274    records differing only in character case, and not expected to cause
 275    any problems in practice.
 276
 277
 278
 279
 280
 281
 282 Expires March 2010           Standards Track                    [Page 5]
 283 \f
 284 draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
 285
 286
 287 7.  DNSSEC Considerations
 288
 289    The rules for the DNSSEC canonical form and ordering were updated to
 290    support transparent treatment of unknown types in [RFC3597].  Those
 291    updates have subsequently been integrated into the base DNSSEC
 292    specification, such that the DNSSEC canonical form and ordering are
 293    now specified in [RFC4034] or its successors rather than in this
 294    document.
 295
 296 8.  Additional Section Processing
 297
 298    Unknown RR types cause no additional section processing.  Future RR
 299    type specifications MAY specify type-specific additional section
 300    processing rules, but any such processing MUST be optional as it can
 301    only be performed by servers for which the RR type in case is known.
 302
 303 9.  IANA Considerations
 304
 305    This document does not require any IANA actions.
 306
 307 10.  Security Considerations
 308
 309    This specification is not believed to cause any new security
 310    problems, nor to solve any existing ones.
 311
 312 11.  Normative References
 313
 314    [RFC1034]   Mockapetris, P., "Domain Names - Concepts and
 315                Facilities", STD 13, RFC 1034, November 1987.
 316
 317    [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
 318                Specifications", STD 13, RFC 1035, November 1987.
 319
 320    [RFC1123]   Braden, R., Ed., "Requirements for Internet Hosts --
 321                Application and Support", STD 3, RFC 1123, October 1989.
 322
 323    [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
 324                Requirement Levels", BCP 14, RFC 2119, March 1997.
 325
 326    [RFC5395]   Eastlake, D., "Domain Name System (DNS) IANA
 327                Considerations", BCP 42, RFC 5395, November 2008.
 328
 329 12.  Informative References
 330
 331    [RFC1876]   Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A
 332                Means for Expressing Location Information in the Domain
 333                Name System", RFC 1876, January 1996.
 334
 335
 336
 337
 338 Expires March 2010           Standards Track                    [Page 6]
 339 \f
 340 draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
 341
 342
 343    [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
 344                "Dynamic Updates in the Domain Name System (DNS UPDATE)",
 345                RFC 2136, April 1997.
 346
 347    [RFC3597]   Gustafsson, A., "Handling of Unknown DNS Resource Record
 348                (RR) Types", RFC 3597, September 2003.
 349
 350    [RFC4034]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
 351                Rose, "Resource Records for the DNS Security Extensions",
 352                RFC 4034, March 2005.
 353
 354 14.  Author's Address
 355
 356    Andreas Gustafsson
 357    Araneus Information Systems Oy
 358    PL 110
 359    02321 Espoo
 360    Finland
 361
 362    Phone: +358 40 547 2099
 363    EMail: gson@araneus.fi
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Expires March 2010           Standards Track                    [Page 7]
 395 \f