external/bsd/bind/dist/doc/rfc/rfc2929.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                   D. Eastlake, 3rd
   8 Request for Comments: 2929                                      Motorola
   9 BCP: 42                                              E. Brunner-Williams
  10 Category: Best Current Practice                                   Engage
  11                                                               B. Manning
  12                                                                      ISI
  13                                                           September 2000
  14
  15               Domain Name System (DNS) IANA Considerations
  16
  17 Status of this Memo
  18
  19    This document specifies an Internet Best Current Practices for the
  20    Internet Community, and requests discussion and suggestions for
  21    improvements.  Distribution of this memo is unlimited.
  22
  23 Copyright Notice
  24
  25    Copyright (C) The Internet Society (2000).  All Rights Reserved.
  26
  27 Abstract
  28
  29    Internet Assigned Number Authority (IANA) parameter assignment
  30    considerations are given for the allocation of Domain Name System
  31    (DNS) classes, Resource Record (RR) types, operation codes, error
  32    codes, etc.
  33
  34 Table of Contents
  35
  36    1. Introduction.................................................  2
  37    2. DNS Query/Response Headers...................................  2
  38    2.1 One Spare Bit?..............................................  3
  39    2.2 Opcode Assignment...........................................  3
  40    2.3 RCODE Assignment............................................  4
  41    3. DNS Resource Records.........................................  5
  42    3.1 RR TYPE IANA Considerations.................................  6
  43    3.1.1 Special Note on the OPT RR................................  7
  44    3.2 RR CLASS IANA Considerations................................  7
  45    3.3 RR NAME Considerations......................................  8
  46    4. Security Considerations......................................  9
  47    References......................................................  9
  48    Authors' Addresses.............................................. 11
  49    Full Copyright Statement........................................ 12
  50
  51
  52
  53
  54
  55
  56
  57
  58 Eastlake, et al.         Best Current Practice                  [Page 1]
  59 \f
  60 RFC 2929                DNS IANA Considerations           September 2000
  61
  62
  63 1. Introduction
  64
  65    The Domain Name System (DNS) provides replicated distributed secure
  66    hierarchical databases which hierarchically store "resource records"
  67    (RRs) under domain names.
  68
  69    This data is structured into CLASSes and zones which can be
  70    independently maintained.  See [RFC 1034, 1035, 2136, 2181, 2535]
  71    familiarity with which is assumed.
  72
  73    This document covers, either directly or by reference, general IANA
  74    parameter assignment considerations applying across DNS query and
  75    response headers and all RRs.  There may be additional IANA
  76    considerations that apply to only a particular RR type or
  77    query/response opcode.  See the specific RFC defining that RR type or
  78    query/response opcode for such considerations if they have been
  79    defined.
  80
  81    IANA currently maintains a web page of DNS parameters.  See
  82    <http://www.iana.org/numbers.htm>.
  83
  84    "IETF Standards Action", "IETF Consensus", "Specification Required",
  85    and "Private Use" are as defined in [RFC 2434].
  86
  87 2. DNS Query/Response Headers
  88
  89    The header for DNS queries and responses contains field/bits in the
  90    following diagram taken from [RFC 2136, 2535]:
  91
  92                                            1  1  1  1  1  1
  93              0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  94             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  95             |                      ID                       |
  96             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  97             |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
  98             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  99             |                QDCOUNT/ZOCOUNT                |
 100             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 101             |                ANCOUNT/PRCOUNT                |
 102             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 103             |                NSCOUNT/UPCOUNT                |
 104             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 105             |                    ARCOUNT                    |
 106             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 107
 108    The ID field identifies the query and is echoed in the response so
 109    they can be matched.
 110
 111
 112
 113
 114 Eastlake, et al.         Best Current Practice                  [Page 2]
 115 \f
 116 RFC 2929                DNS IANA Considerations           September 2000
 117
 118
 119    The QR bit indicates whether the header is for a query or a response.
 120
 121    The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
 122    only in queries or only in responses, depending on the bit.  However,
 123    many DNS implementations copy the query header as the initial value
 124    of the response header without clearing bits.  Thus any attempt to
 125    use a "query" bit with a different meaning in a response or to define
 126    a query meaning for a "response" bit is dangerous given existing
 127    implementation.  Such meanings may only be assigned by an IETF
 128    Standards Action.
 129
 130    The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
 131    authority count (NSCOUNT), and additional information count (ARCOUNT)
 132    express the number of records in each section for all opcodes except
 133    Update.  These fields have the same structure and data type for
 134    Update but are instead the counts for the zone (ZOCOUNT),
 135    prerequisite (PRCOUNT), update (UPCOUNT), and additional information
 136    (ARCOUNT) sections.
 137
 138 2.1 One Spare Bit?
 139
 140    There have been ancient DNS implementations for which the Z bit being
 141    on in a query meant that only a response from the primary server for
 142    a zone is acceptable.  It is believed that current DNS
 143    implementations ignore this bit.
 144
 145    Assigning a meaning to the Z bit requires an IETF Standards Action.
 146
 147 2.2 Opcode Assignment
 148
 149    New OpCode assignments require an IETF Standards Action.
 150
 151    Currently DNS OpCodes are assigned as follows:
 152
 153        OpCode Name                      Reference
 154
 155         0     Query                     [RFC 1035]
 156         1     IQuery  (Inverse Query)   [RFC 1035]
 157         2     Status                    [RFC 1035]
 158         3     available for assignment
 159         4     Notify                    [RFC 1996]
 160         5     Update                    [RFC 2136]
 161        6-15   available for assignment
 162
 163
 164
 165
 166
 167
 168
 169
 170 Eastlake, et al.         Best Current Practice                  [Page 3]
 171 \f
 172 RFC 2929                DNS IANA Considerations           September 2000
 173
 174
 175 2.3 RCODE Assignment
 176
 177    It would appear from the DNS header above that only four bits of
 178    RCODE, or response/error code are available.  However, RCODEs can
 179    appear not only at the top level of a DNS response but also inside
 180    OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
 181    The OPT RR provides an eight bit extension resulting in a 12 bit
 182    RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
 183
 184    Error codes appearing in the DNS header and in these three RR types
 185    all refer to the same error code space with the single exception of
 186    error code 16 which has a different meaning in the OPT RR from its
 187    meaning in other contexts.  See table below.
 188
 189    RCODE   Name    Description                        Reference
 190    Decimal
 191      Hexadecimal
 192     0    NoError   No Error                           [RFC 1035]
 193     1    FormErr   Format Error                       [RFC 1035]
 194     2    ServFail  Server Failure                     [RFC 1035]
 195     3    NXDomain  Non-Existent Domain                [RFC 1035]
 196     4    NotImp    Not Implemented                    [RFC 1035]
 197     5    Refused   Query Refused                      [RFC 1035]
 198     6    YXDomain  Name Exists when it should not     [RFC 2136]
 199     7    YXRRSet   RR Set Exists when it should not   [RFC 2136]
 200     8    NXRRSet   RR Set that should exist does not  [RFC 2136]
 201     9    NotAuth   Server Not Authoritative for zone  [RFC 2136]
 202    10    NotZone   Name not contained in zone         [RFC 2136]
 203    11-15           available for assignment
 204    16    BADVERS   Bad OPT Version                    [RFC 2671]
 205    16    BADSIG    TSIG Signature Failure             [RFC 2845]
 206    17    BADKEY    Key not recognized                 [RFC 2845]
 207    18    BADTIME   Signature out of time window       [RFC 2845]
 208    19    BADMODE   Bad TKEY Mode                      [RFC 2930]
 209    20    BADNAME   Duplicate key name                 [RFC 2930]
 210    21    BADALG    Algorithm not supported            [RFC 2930]
 211    22-3840         available for assignment
 212      0x0016-0x0F00
 213    3841-4095       Private Use
 214      0x0F01-0x0FFF
 215    4096-65535      available for assignment
 216      0x1000-0xFFFF
 217
 218    Since it is important that RCODEs be understood for interoperability,
 219    assignment of new RCODE listed above as "available for assignment"
 220    requires an IETF Consensus.
 221
 222
 223
 224
 225
 226 Eastlake, et al.         Best Current Practice                  [Page 4]
 227 \f
 228 RFC 2929                DNS IANA Considerations           September 2000
 229
 230
 231 3. DNS Resource Records
 232
 233    All RRs have the same top level format shown in the figure below
 234    taken from [RFC 1035]:
 235
 236                                          1  1  1  1  1  1
 237            0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
 238          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 239          |                                               |
 240          /                                               /
 241          /                      NAME                     /
 242          |                                               |
 243          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 244          |                      TYPE                     |
 245          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 246          |                     CLASS                     |
 247          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 248          |                      TTL                      |
 249          |                                               |
 250          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 251          |                   RDLENGTH                    |
 252          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
 253          /                     RDATA                     /
 254          /                                               /
 255          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 256
 257    NAME is an owner name, i.e., the name of the node to which this
 258    resource record pertains.  NAMEs are specific to a CLASS as described
 259    in section 3.2.  NAMEs consist of an ordered sequence of one or more
 260    labels each of which has a label type [RFC 1035, 2671].
 261
 262    TYPE is a two octet unsigned integer containing one of the RR TYPE
 263    codes.  See section 3.1.
 264
 265    CLASS is a two octet unsigned integer containing one of the RR CLASS
 266    codes.  See section 3.2.
 267
 268    TTL is a four octet (32 bit) bit unsigned integer that specifies the
 269    number of seconds that the resource record may be cached before the
 270    source of the information should again be consulted.  Zero is
 271    interpreted to mean that the RR can only be used for the transaction
 272    in progress.
 273
 274    RDLENGTH is an unsigned 16 bit integer that specifies the length in
 275    octets of the RDATA field.
 276
 277
 278
 279
 280
 281
 282 Eastlake, et al.         Best Current Practice                  [Page 5]
 283 \f
 284 RFC 2929                DNS IANA Considerations           September 2000
 285
 286
 287    RDATA is a variable length string of octets that constitutes the
 288    resource.  The format of this information varies according to the
 289    TYPE and in some cases the CLASS of the resource record.
 290
 291 3.1 RR TYPE IANA Considerations
 292
 293    There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
 294    and MetaTYPEs.
 295
 296    Data TYPEs are the primary means of storing data.  QTYPES can only be
 297    used in queries.  Meta-TYPEs designate transient data associated with
 298    an particular DNS message and in some cases can also be used in
 299    queries.  Thus far, data TYPEs have been assigned from 1 upwards plus
 300    the block from 100 through 103 while Q and Meta Types have been
 301    assigned from 255 downwards (except for the OPT Meta-RR which is
 302    assigned TYPE 41).  There have been DNS implementations which made
 303    caching decisions based on the top bit of the bottom byte of the RR
 304    TYPE.
 305
 306    There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
 307    [RFC 2845], and TKEY [RFC 2930].
 308
 309    There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
 310    AXFR, and IXFR.
 311
 312    Considerations for the allocation of new RR TYPEs are as follows:
 313
 314      Decimal
 315    Hexadecimal
 316
 317      0
 318    0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
 319           2535] and in other circumstances and must never be allocated
 320           for ordinary use.
 321
 322      1 - 127
 323    0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
 324           TYPEs by IETF Consensus.
 325
 326      128 - 255
 327    0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
 328           Meta TYPEs by IETF Consensus.
 329
 330      256 - 32767
 331    0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF
 332           Consensus.
 333
 334
 335
 336
 337
 338 Eastlake, et al.         Best Current Practice                  [Page 6]
 339 \f
 340 RFC 2929                DNS IANA Considerations           September 2000
 341
 342
 343      32768 - 65279
 344    0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
 345
 346      65280 - 65535
 347    0xFF00 - 0xFFFF - Private Use.
 348
 349 3.1.1 Special Note on the OPT RR
 350
 351    The OPT (OPTion) RR, number 41, is specified in [RFC 2671].  Its
 352    primary purpose is to extend the effective field size of various DNS
 353    fields including RCODE, label type, flag bits, and RDATA size.  In
 354    particular, for resolvers and servers that recognize it, it extends
 355    the RCODE field from 4 to 12 bits.
 356
 357 3.2 RR CLASS IANA Considerations
 358
 359    DNS CLASSes have been little used but constitute another dimension of
 360    the DNS distributed database.  In particular, there is no necessary
 361    relationship between the name space or root servers for one CLASS and
 362    those for another CLASS.  The same name can have completely different
 363    meanings in different CLASSes although the label types are the same
 364    and the null label is usable only as root in every CLASS.  However,
 365    as global networking and DNS have evolved, the IN, or Internet, CLASS
 366    has dominated DNS use.
 367
 368    There are two subcategories of DNS CLASSes: normal data containing
 369    classes and QCLASSes that are only meaningful in queries or updates.
 370
 371    The current CLASS assignments and considerations for future
 372    assignments are as follows:
 373
 374      Decimal
 375    Hexadecimal
 376
 377      0
 378    0x0000 - assignment requires an IETF Standards Action.
 379
 380      1
 381    0x0001 - Internet (IN).
 382
 383      2
 384    0x0002 - available for assignment by IETF Consensus as a data CLASS.
 385
 386      3
 387    0x0003 - Chaos (CH) [Moon 1981].
 388
 389      4
 390    0x0004 - Hesiod (HS) [Dyer 1987].
 391
 392
 393
 394 Eastlake, et al.         Best Current Practice                  [Page 7]
 395 \f
 396 RFC 2929                DNS IANA Considerations           September 2000
 397
 398
 399      5 - 127
 400    0x0005 - 0x007F - available for assignment by IETF Consensus as data
 401           CLASSes only.
 402
 403      128 - 253
 404    0x0080 - 0x00FD - available for assignment by IETF Consensus as
 405           QCLASSes only.
 406
 407      254
 408    0x00FE - QCLASS None [RFC 2136].
 409
 410      255
 411    0x00FF - QCLASS Any [RFC 1035].
 412
 413      256 - 32767
 414    0x0100 - 0x7FFF - assigned by IETF Consensus.
 415
 416      32768 - 65280
 417    0x8000 - 0xFEFF - assigned based on Specification Required as defined
 418           in [RFC 2434].
 419
 420      65280 - 65534
 421    0xFF00 - 0xFFFE - Private Use.
 422
 423      65535
 424    0xFFFF - can only be assigned by an IETF Standards Action.
 425
 426 3.3 RR NAME Considerations
 427
 428    DNS NAMEs are sequences of labels [RFC 1035].  The last label in each
 429    NAME is "ROOT" which is the zero length label.  By definition, the
 430    null or ROOT label can not be used for any other NAME purpose.
 431
 432    At the present time, there are two categories of label types, data
 433    labels and compression labels.  Compression labels are pointers to
 434    data labels elsewhere within an RR or DNS message and are intended to
 435    shorten the wire encoding of NAMEs.  The two existing data label
 436    types are sometimes referred to as Text and Binary.  Text labels can,
 437    in fact, include any octet value including zero octets but most
 438    current uses involve only [US-ASCII].  For retrieval, Text labels are
 439    defined to treat ASCII upper and lower case letter codes as matching.
 440    Binary labels are bit sequences [RFC 2673].
 441
 442    IANA considerations for label types are given in [RFC 2671].
 443
 444
 445
 446
 447
 448
 449
 450 Eastlake, et al.         Best Current Practice                  [Page 8]
 451 \f
 452 RFC 2929                DNS IANA Considerations           September 2000
 453
 454
 455    NAMEs are local to a CLASS.  The Hesiod [Dyer 1987] and Chaos [Moon
 456    1981] CLASSes are essentially for local use.  The IN or Internet
 457    CLASS is thus the only DNS CLASS in global use on the Internet at
 458    this time.
 459
 460    A somewhat dated description of name allocation in the IN Class is
 461    given in [RFC 1591].  Some information on reserved top level domain
 462    names is in Best Current Practice 32 [RFC 2606].
 463
 464 4. Security Considerations
 465
 466    This document addresses IANA considerations in the allocation of
 467    general DNS parameters, not security.  See [RFC 2535] for secure DNS
 468    considerations.
 469
 470 References
 471
 472    [Dyer 1987] Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
 473                Plan - Name Service, April 1987,
 474
 475    [Moon 1981] D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
 476                Institute of Technology Artificial Intelligence
 477                Laboratory, June 1981.
 478
 479    [RFC 1034]  Mockapetris, P., "Domain Names - Concepts and
 480                Facilities", STD 13, RFC 1034, November 1987.
 481
 482    [RFC 1035]  Mockapetris, P., "Domain Names - Implementation and
 483                Specifications", STD 13, RFC 1035, November 1987.
 484
 485    [RFC 1591]  Postel, J., "Domain Name System Structure and
 486                Delegation", RFC 1591, March 1994.
 487
 488    [RFC 1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
 489                Changes (DNS NOTIFY)", RFC 1996, August 1996.
 490
 491    [RFC 2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
 492                "Dynamic Updates in the Domain Name System (DNS UPDATE)",
 493                RFC 2136, April 1997.
 494
 495    [RFC 2181]  Elz, R. and R. Bush, "Clarifications to the DNS
 496                Specification", RFC 2181, July 1997.
 497
 498    [RFC 2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
 499                IANA Considerations Section in RFCs", BCP 26, RFC 2434,
 500                October 1998.
 501
 502
 503
 504
 505
 506 Eastlake, et al.         Best Current Practice                  [Page 9]
 507 \f
 508 RFC 2929                DNS IANA Considerations           September 2000
 509
 510
 511    [RFC 2535]  Eastlake, D., "Domain Name System Security Extensions",
 512                RFC 2535, March 1999.
 513
 514    [RFC 2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
 515                Names", RFC 2606, June 1999.
 516
 517    [RFC 2671]  Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
 518                2671, August 1999.
 519
 520    [RFC 2672]  Crawford, M., "Non-Terminal DNS Name Redirection", RFC
 521                2672, August 1999.
 522
 523    [RFC 2673]  Crawford, M., "Binary Labels in the Domain Name System",
 524                RFC 2673, August 1999.
 525
 526    [RFC 2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
 527                Wellington, "Secret Key Transaction Authentication for
 528                DNS (TSIG)", RFC 2845, May 2000.
 529
 530    [RFC 2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
 531                RR)", RFC 2930, September 2000.
 532
 533    [US-ASCII]  ANSI, "USA Standard Code for Information Interchange",
 534                X3.4, American National Standards Institute: New York,
 535                1968.
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Eastlake, et al.         Best Current Practice                 [Page 10]
 563 \f
 564 RFC 2929                DNS IANA Considerations           September 2000
 565
 566
 567 Authors' Addresses
 568
 569    Donald E. Eastlake 3rd
 570    Motorola
 571    140 Forest Avenue
 572    Hudson, MA 01749 USA
 573
 574    Phone: +1-978-562-2827 (h)
 575           +1-508-261-5434 (w)
 576    Fax:   +1-508-261-4447 (w)
 577    EMail: Donald.Eastlake@motorola.com
 578
 579
 580    Eric Brunner-Williams
 581    Engage
 582    100 Brickstone Square, 2nd Floor
 583    Andover, MA 01810
 584
 585    Phone: +1-207-797-0525 (h)
 586           +1-978-684-7796 (w)
 587    Fax:   +1-978-684-3118
 588    EMail: brunner@engage.com
 589
 590
 591    Bill Manning
 592    USC/ISI
 593    4676 Admiralty Way, #1001
 594    Marina del Rey, CA 90292 USA
 595
 596    Phone: +1-310-822-1511
 597    EMail: bmanning@isi.edu
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618 Eastlake, et al.         Best Current Practice                 [Page 11]
 619 \f
 620 RFC 2929                DNS IANA Considerations           September 2000
 621
 622
 623 Full Copyright Statement
 624
 625    Copyright (C) The Internet Society (2000).  All Rights Reserved.
 626
 627    This document and translations of it may be copied and furnished to
 628    others, and derivative works that comment on or otherwise explain it
 629    or assist in its implementation may be prepared, copied, published
 630    and distributed, in whole or in part, without restriction of any
 631    kind, provided that the above copyright notice and this paragraph are
 632    included on all such copies and derivative works.  However, this
 633    document itself may not be modified in any way, such as by removing
 634    the copyright notice or references to the Internet Society or other
 635    Internet organizations, except as needed for the purpose of
 636    developing Internet standards in which case the procedures for
 637    copyrights defined in the Internet Standards process must be
 638    followed, or as required to translate it into languages other than
 639    English.
 640
 641    The limited permissions granted above are perpetual and will not be
 642    revoked by the Internet Society or its successors or assigns.
 643
 644    This document and the information contained herein is provided on an
 645    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 646    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 647    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 648    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 649    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 650
 651 Acknowledgement
 652
 653    Funding for the RFC Editor function is currently provided by the
 654    Internet Society.
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674 Eastlake, et al.         Best Current Practice                 [Page 12]
 675 \f