contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt

   1
   2 INTERNET-DRAFT                                    Donald E. Eastlake 3rd
   3 Obsoletes RFC 2929, Updates RFC 1183               Motorola Laboratories
   4 Expires: February 2006                                       August 2005
   5
   6
   7
   8               Domain Name System (DNS) IANA Considerations
   9               ------ ---- ------ ----- ---- --------------
  10                    <draft-ietf-dnsext-2929bis-01.txt>
  11
  12
  13
  14 Status of This Document
  15
  16    By submitting this Internet-Draft, each author represents that any
  17    applicable patent or other IPR claims of which he or she is aware
  18    have been or will be disclosed, and any of which he or she becomes
  19    aware will be disclosed, in accordance with Section 6 of BCP 79.
  20
  21    Distribution of this draft is unlimited.  It is intended to become
  22    the new BCP 42 obsoleting RFC 2929.  Comments should be sent to the
  23    DNS Working Group mailing list <namedroppers@ops.ietf.org>.
  24
  25    Internet-Drafts are working documents of the Internet Engineering
  26    Task Force (IETF), its areas, and its working groups.  Note that
  27    other groups may also distribute working documents as Internet-
  28    Drafts.
  29
  30    Internet-Drafts are draft documents valid for a maximum of six months
  31    and may be updated, replaced, or obsoleted by other documents at any
  32    time.  It is inappropriate to use Internet-Drafts as reference
  33    material or to cite them other than a "work in progress."
  34
  35    The list of current Internet-Drafts can be accessed at
  36    http://www.ietf.org/1id-abstracts.html
  37
  38    The list of Internet-Draft Shadow Directories can be accessed at
  39    http://www.ietf.org/shadow.html
  40
  41
  42
  43 Abstract
  44
  45    Internet Assigned Number Authority (IANA) parameter assignment
  46    considerations are given for the allocation of Domain Name System
  47    (DNS) classes, RR types, operation codes, error codes, RR header
  48    bits, and AFSDB subtypes.
  49
  50
  51
  52
  53
  54
  55
  56
  57 D. Eastlake 3rd                                                 [Page 1]
  58 \f
  59
  60 INTERNET-DRAFT           DNS IANA Considerations             August 2005
  61
  62
  63 Table of Contents
  64
  65       Status of This Document....................................1
  66       Abstract...................................................1
  67
  68       Table of Contents..........................................2
  69
  70       1. Introduction............................................3
  71       2. DNS Query/Response Headers..............................3
  72       2.1 One Spare Bit?.........................................4
  73       2.2 Opcode Assignment......................................4
  74       2.3 RCODE Assignment.......................................5
  75       3. DNS Resource Records....................................6
  76       3.1 RR TYPE IANA Considerations............................7
  77       3.1.1 DNS TYPE Allocation Policy...........................8
  78       3.1.2 Special Note on the OPT RR...........................9
  79       3.1.3 The AFSDB RR Subtype Field...........................9
  80       3.2 RR CLASS IANA Considerations...........................9
  81       3.3 RR NAME Considerations................................11
  82       4. Security Considerations................................11
  83
  84       Appendix: Changes from RFC 2929...........................12
  85
  86       Copyright and Disclaimer..................................13
  87       Normative References......................................13
  88       Informative References....................................14
  89
  90       Authors Addresses.........................................16
  91       Expiration and File Name..................................16
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115 D. Eastlake 3rd                                                 [Page 2]
 116 \f
 117
 118 INTERNET-DRAFT           DNS IANA Considerations             August 2005
 119
 120
 121 1. Introduction
 122
 123    The Domain Name System (DNS) provides replicated distributed secure
 124    hierarchical databases which hierarchically store "resource records"
 125    (RRs) under domain names.  DNS data is structured into CLASSes and
 126    zones which can be independently maintained.  See [RFC 1034, 1035,
 127    2136, 2181, 4033] familiarity with which is assumed.
 128
 129    This document provides, either directly or by reference, general IANA
 130    parameter assignment considerations applying across DNS query and
 131    response headers and all RRs.  There may be additional IANA
 132    considerations that apply to only a particular RR type or
 133    query/response opcode.  See the specific RFC defining that RR type or
 134    query/response opcode for such considerations if they have been
 135    defined, except for AFSDB RR considerations [RFC 1183] which are
 136    included herein. This RFC obsoletes [RFC 2929].
 137
 138    IANA currently maintains a web page of DNS parameters.  See
 139    <http://www.iana.org/numbers.htm>.
 140
 141    "IETF Standards Action", "IETF Consensus", "Specification Required",
 142    and "Private Use" are as defined in [RFC 2434].
 143
 144
 145
 146 2. DNS Query/Response Headers
 147
 148    The header for DNS queries and responses contains field/bits in the
 149    following diagram taken from [RFC 2136, 2929]:
 150
 151                                               1  1  1  1  1  1
 152                 0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
 153                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 154                |                      ID                       |
 155                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 156                |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
 157                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 158                |                QDCOUNT/ZOCOUNT                |
 159                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 160                |                ANCOUNT/PRCOUNT                |
 161                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 162                |                NSCOUNT/UPCOUNT                |
 163                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 164                |                    ARCOUNT                    |
 165                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 166
 167    The ID field identifies the query and is echoed in the response so
 168    they can be matched.
 169
 170    The QR bit indicates whether the header is for a query or a response.
 171
 172
 173 D. Eastlake 3rd                                                 [Page 3]
 174 \f
 175
 176 INTERNET-DRAFT           DNS IANA Considerations             August 2005
 177
 178
 179    The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
 180    only in queries or only in responses, depending on the bit.  However,
 181    many DNS implementations copy the query header as the initial value
 182    of the response header without clearing bits.  Thus any attempt to
 183    use a "query" bit with a different meaning in a response or to define
 184    a query meaning for a "response" bit is dangerous given existing
 185    implementation.  Such meanings may only be assigned by an IETF
 186    Standards Action.
 187
 188    The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
 189    authority count (NSCOUNT), and additional information count (ARCOUNT)
 190    express the number of records in each section for all opcodes except
 191    Update.  These fields have the same structure and data type for
 192    Update but are instead the counts for the zone (ZOCOUNT),
 193    prerequisite (PRCOUNT), update (UPCOUNT), and additional information
 194    (ARCOUNT) sections.
 195
 196
 197
 198 2.1 One Spare Bit?
 199
 200    There have been ancient DNS implementations for which the Z bit being
 201    on in a query meant that only a response from the primary server for
 202    a zone is acceptable.  It is believed that current DNS
 203    implementations ignore this bit.
 204
 205    Assigning a meaning to the Z bit requires an IETF Standards Action.
 206
 207
 208
 209 2.2 Opcode Assignment
 210
 211    Currently DNS OpCodes are assigned as follows:
 212
 213           OpCode Name                      Reference
 214
 215            0     Query                     [RFC 1035]
 216            1     IQuery  (Inverse Query, Obsolete) [RFC 3425]
 217            2     Status                    [RFC 1035]
 218            3     available for assignment
 219            4     Notify                    [RFC 1996]
 220            5     Update                    [RFC 2136]
 221           6-15   available for assignment
 222
 223    New OpCode assignments require an IETF Standards Action as modified
 224    by [RFC 4020].
 225
 226
 227
 228
 229
 230
 231 D. Eastlake 3rd                                                 [Page 4]
 232 \f
 233
 234 INTERNET-DRAFT           DNS IANA Considerations             August 2005
 235
 236
 237 2.3 RCODE Assignment
 238
 239    It would appear from the DNS header above that only four bits of
 240    RCODE, or response/error code are available.  However, RCODEs can
 241    appear not only at the top level of a DNS response but also inside
 242    OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
 243    The OPT RR provides an eight bit extension resulting in a 12 bit
 244    RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
 245
 246    Error codes appearing in the DNS header and in these three RR types
 247    all refer to the same error code space with the single exception of
 248    error code 16 which has a different meaning in the OPT RR from its
 249    meaning in other contexts.  See table below.
 250
 251         RCODE   Name    Description                        Reference
 252         Decimal
 253           Hexadecimal
 254          0    NoError   No Error                           [RFC 1035]
 255          1    FormErr   Format Error                       [RFC 1035]
 256          2    ServFail  Server Failure                     [RFC 1035]
 257          3    NXDomain  Non-Existent Domain                [RFC 1035]
 258          4    NotImp    Not Implemented                    [RFC 1035]
 259          5    Refused   Query Refused                      [RFC 1035]
 260          6    YXDomain  Name Exists when it should not     [RFC 2136]
 261          7    YXRRSet   RR Set Exists when it should not   [RFC 2136]
 262          8    NXRRSet   RR Set that should exist does not  [RFC 2136]
 263          9    NotAuth   Server Not Authoritative for zone  [RFC 2136]
 264         10    NotZone   Name not contained in zone         [RFC 2136]
 265         11 - 15         Available for assignment
 266         16    BADVERS   Bad OPT Version                    [RFC 2671]
 267         16    BADSIG    TSIG Signature Failure             [RFC 2845]
 268         17    BADKEY    Key not recognized                 [RFC 2845]
 269         18    BADTIME   Signature out of time window       [RFC 2845]
 270         19    BADMODE   Bad TKEY Mode                      [RPC 2930]
 271         20    BADNAME   Duplicate key name                 [RPF 2930]
 272         21    BADALG    Algorithm not supported            [RPF 2930]
 273
 274         22 - 3,840
 275           0x0016 - 0x0F00   Available for assignment
 276
 277         3,841 - 4,095
 278           0x0F01 - 0x0FFF   Private Use
 279
 280         4,096 - 65,534
 281           0x1000 - 0xFFFE   Available for assignment
 282
 283         65,535
 284           0xFFFF            Reserved, can only be allocated by an IETF
 285                             Standards Action.
 286
 287
 288
 289 D. Eastlake 3rd                                                 [Page 5]
 290 \f
 291
 292 INTERNET-DRAFT           DNS IANA Considerations             August 2005
 293
 294
 295    Since it is important that RCODEs be understood for interoperability,
 296    assignment of new RCODE listed above as "available for assignment"
 297    requires an IETF Consensus.
 298
 299
 300
 301 3. DNS Resource Records
 302
 303    All RRs have the same top level format shown in the figure below
 304    taken from [RFC 1035]:
 305
 306                                        1  1  1  1  1  1
 307          0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
 308        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 309        |                                               |
 310        /                                               /
 311        /                      NAME                     /
 312        |                                               |
 313        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 314        |                      TYPE                     |
 315        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 316        |                     CLASS                     |
 317        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 318        |                      TTL                      |
 319        |                                               |
 320        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 321        |                   RDLENGTH                    |
 322        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
 323        /                     RDATA                     /
 324        /                                               /
 325        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 326
 327    NAME is an owner name, i.e., the name of the node to which this
 328    resource record pertains.  NAMEs are specific to a CLASS as described
 329    in section 3.2.  NAMEs consist of an ordered sequence of one or more
 330    labels each of which has a label type [RFC 1035, 2671].
 331
 332    TYPE is a two octet unsigned integer containing one of the RR TYPE
 333    codes.  See section 3.1.
 334
 335    CLASS is a two octet unsigned integer containing one of the RR CLASS
 336    codes.  See section 3.2.
 337
 338    TTL is a four octet (32 bit) bit unsigned integer that specifies the
 339    number of seconds that the resource record may be cached before the
 340    source of the information should again be consulted.  Zero is
 341    interpreted to mean that the RR can only be used for the transaction
 342    in progress.
 343
 344    RDLENGTH is an unsigned 16 bit integer that specifies the length in
 345
 346
 347 D. Eastlake 3rd                                                 [Page 6]
 348 \f
 349
 350 INTERNET-DRAFT           DNS IANA Considerations             August 2005
 351
 352
 353    octets of the RDATA field.
 354
 355    RDATA is a variable length string of octets that constitutes the
 356    resource. The format of this information varies according to the TYPE
 357    and in some cases the CLASS of the resource record.
 358
 359
 360
 361 3.1 RR TYPE IANA Considerations
 362
 363    There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
 364    and MetaTYPEs.
 365
 366    Data TYPEs are the primary means of storing data.  QTYPES can only be
 367    used in queries.  Meta-TYPEs designate transient data associated with
 368    an particular DNS message and in some cases can also be used in
 369    queries.  Thus far, data TYPEs have been assigned from 1 upwards plus
 370    the block from 100 through 103 while Q and Meta Types have been
 371    assigned from 255 downwards except for the OPT Meta-RR which is
 372    assigned TYPE 41.  There have been DNS implementations which made
 373    caching decisions based on the top bit of the bottom byte of the RR
 374    TYPE.
 375
 376    There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
 377    [RFC 2845], and TKEY [RFC 2930].
 378
 379    There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
 380    AXFR, and IXFR.
 381
 382    Considerations for the allocation of new RR TYPEs are as follows:
 383
 384      Decimal
 385    Hexadecimal
 386
 387      0
 388    0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
 389           2535] and in other circumstances and must never be allocated
 390           for ordinary use.
 391
 392      1 - 127
 393    0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
 394           TYPEs by the DNS TYPE Allocation Policy as specified in
 395           section 3.1.1.
 396
 397      128 - 255
 398    0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
 399           Meta TYPEs by the DNS TYPE Allocation Policy as specified in
 400           section 3.1.1.
 401
 402
 403
 404
 405 D. Eastlake 3rd                                                 [Page 7]
 406 \f
 407
 408 INTERNET-DRAFT           DNS IANA Considerations             August 2005
 409
 410
 411      256 - 32,767
 412    0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS
 413           TYPE Allocation Policy as specified in section 3.1.1.
 414
 415      32,768 - 65,279
 416    0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
 417
 418      65,280 - 65534
 419    0xFF00 - 0xFFFE - Private Use.
 420
 421      65,535
 422    0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
 423
 424
 425
 426 3.1.1 DNS TYPE Allocation Policy
 427
 428    Parameter values specified above as assigned based on DNS TYPE
 429    Allocation Policy. That is, Expert Review with the additional
 430    requirement that the review be based on a complete template as
 431    specified below which has been posted for three weeks to the
 432    namedroppers@ops.ietf.org mailing list.
 433
 434    Partial or draft templates may be posted with the intend of
 435    soliciting feedback.
 436
 437
 438                  DNS RR TYPE PARAMETER ALLOCATION TEMPLATE
 439
 440         Date:
 441
 442         Name and email of originator:
 443
 444         Pointer to internet-draft or other document giving a detailed
 445         description of the protocol use of the new RR Type:
 446
 447         What need is the new RR TYPE intended to fix?
 448
 449         What existing RR TYPE(s) come closest to filling that need and why are
 450         they unsatisfactory?
 451
 452         Does the proposed RR TYPR require special handling within the DNS
 453         different from an Unknown RR TYPE?
 454
 455         Comments:
 456
 457
 458
 459
 460
 461
 462
 463 D. Eastlake 3rd                                                 [Page 8]
 464 \f
 465
 466 INTERNET-DRAFT           DNS IANA Considerations             August 2005
 467
 468
 469 3.1.2 Special Note on the OPT RR
 470
 471    The OPT (OPTion) RR, number 41, is specified in [RFC 2671].  Its
 472    primary purpose is to extend the effective field size of various DNS
 473    fields including RCODE, label type, OpCode, flag bits, and RDATA
 474    size.  In particular, for resolvers and servers that recognize it, it
 475    extends the RCODE field from 4 to 12 bits.
 476
 477
 478
 479 3.1.3 The AFSDB RR Subtype Field
 480
 481    The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same
 482    RDATA field structure as the MX RR but the 16 bit unsigned integer
 483    field at the beginning of the RDATA is interpreted as a subtype as
 484    follows:
 485
 486      Decimal
 487    Hexadecimal
 488
 489      0
 490    0x0000 -  Allocation requires IETF Standards Action.
 491
 492      1
 493    0x0001 - Andrews File Service v3.0 Location Service [RFC 1183].
 494
 495      2
 496    0x0002 - DCE/NCA root cell directory node [RFC 1183].
 497
 498      3 - 65,279
 499    0x0003 - 0xFEFF - Allocation by IETF Consensus.
 500
 501      65,280 - 65,534
 502    0xFF00 - 0xFFFE - Private Use.
 503
 504      65,535
 505    0xFFFF - Reserved, allocation requires IETF Standards Action.
 506
 507
 508
 509 3.2 RR CLASS IANA Considerations
 510
 511    DNS CLASSes have been little used but constitute another dimension of
 512    the DNS distributed database.  In particular, there is no necessary
 513    relationship between the name space or root servers for one CLASS and
 514    those for another CLASS.  The same name can have completely different
 515    meanings in different CLASSes; however, the label types are the same
 516    and the null label is usable only as root in every CLASS.  However,
 517    as global networking and DNS have evolved, the IN, or Internet, CLASS
 518    has dominated DNS use.
 519
 520
 521 D. Eastlake 3rd                                                 [Page 9]
 522 \f
 523
 524 INTERNET-DRAFT           DNS IANA Considerations             August 2005
 525
 526
 527    There are two subcategories of DNS CLASSes: normal data containing
 528    classes and QCLASSes that are only meaningful in queries or updates.
 529
 530    The current CLASS assignments and considerations for future
 531    assignments are as follows:
 532
 533      Decimal
 534    Hexadecimal
 535
 536      0
 537    0x0000 - Reserved, assignment requires an IETF Standards Action.
 538
 539      1
 540    0x0001 - Internet (IN).
 541
 542      2
 543    0x0002 - Available for assignment by IETF Consensus as a data CLASS.
 544
 545      3
 546    0x0003 - Chaos (CH) [Moon 1981].
 547
 548      4
 549    0x0004 - Hesiod (HS) [Dyer 1987].
 550
 551      5 - 127
 552    0x0005 - 0x007F - available for assignment by IETF Consensus for data
 553           CLASSes only.
 554
 555      128 - 253
 556    0x0080 - 0x00FD - available for assignment by IETF Consensus for
 557           QCLASSes only.
 558
 559      254
 560    0x00FE - QCLASS None [RFC 2136].
 561
 562      255
 563    0x00FF - QCLASS Any [RFC 1035].
 564
 565      256 - 32,767
 566    0x0100 - 0x7FFF - Assigned by IETF Consensus.
 567
 568      32,768 - 65,279
 569    0x8000 - 0xFEFF - Assigned based on Specification Required as defined
 570           in [RFC 2434].
 571
 572      65,280 - 65,534
 573    0xFF00 - 0xFFFE - Private Use.
 574
 575      65,535
 576    0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
 577
 578
 579 D. Eastlake 3rd                                                [Page 10]
 580 \f
 581
 582 INTERNET-DRAFT           DNS IANA Considerations             August 2005
 583
 584
 585 3.3 RR NAME Considerations
 586
 587    DNS NAMEs are sequences of labels [RFC 1035].  The last label in each
 588    NAME is "ROOT" which is the zero length label.  By definition, the
 589    null or ROOT label can not be used for any other NAME purpose.
 590
 591    At the present time, there are two categories of label types, data
 592    labels and compression labels.  Compression labels are pointers to
 593    data labels elsewhere within an RR or DNS message and are intended to
 594    shorten the wire encoding of NAMEs.  The two existing data label
 595    types are sometimes referred to as Text and Binary.  Text labels can,
 596    in fact, include any octet value including zero value octets but most
 597    current uses involve only [US-ASCII].  For retrieval, Text labels are
 598    defined to treat ASCII upper and lower case letter codes as matching
 599    [insensitive].  Binary labels are bit sequences [RFC 2673]. The
 600    Binary label type is Experimental [RFC 3363].
 601
 602    IANA considerations for label types are given in [RFC 2671].
 603
 604    NAMEs are local to a CLASS.  The Hesiod [Dyer 1987] and Chaos [Moon
 605    1981] CLASSes are essentially for local use.  The IN or Internet
 606    CLASS is thus the only DNS CLASS in global use on the Internet at
 607    this time.
 608
 609    A somewhat out-of-date description of name allocation in the IN Class
 610    is given in [RFC 1591].  Some information on reserved top level
 611    domain names is in BCP 32 [RFC 2606].
 612
 613
 614
 615 4. Security Considerations
 616
 617    This document addresses IANA considerations in the allocation of
 618    general DNS parameters, not security.  See [RFC 4033, 4034, 4035] for
 619    secure DNS considerations.
 620
 621
 622
 623
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637 D. Eastlake 3rd                                                [Page 11]
 638 \f
 639
 640 INTERNET-DRAFT           DNS IANA Considerations             August 2005
 641
 642
 643 Appendix: Changes from RFC 2929
 644
 645    RFC Editor: This Appendix should be deleted for publication.
 646
 647    Changes from RFC 2929 to this draft:
 648
 649    1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE
 650    Allocation Policy" and add the specification of that policy. Change
 651    some remaining "IETF Standards Action" allocation requirements to say
 652    "as modified by [RFC 4020]".
 653
 654    2. Updated various RFC references.
 655
 656    3. Mentioned that the Binary label type is now Experimental and
 657    IQuery is Obsolete.
 658
 659    4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be
 660    IETF Standards Action required.
 661
 662    5. Add an IANA allocation policy for the AFSDB RR Subtype field.
 663
 664    6. Addition of reference to case insensitive draft.
 665
 666
 667
 668
 669
 670
 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 D. Eastlake 3rd                                                [Page 12]
 696 \f
 697
 698 INTERNET-DRAFT           DNS IANA Considerations             August 2005
 699
 700
 701 Copyright and Disclaimer
 702
 703    Copyright (C) The Internet Society (2005).  This document is subject to
 704    the rights, licenses and restrictions contained in BCP 78, and except
 705    as set forth therein, the authors retain all their rights.
 706
 707
 708    This document and the information contained herein are provided on an
 709    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 710    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 711    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 712    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 713    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 714    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 715
 716
 717
 718 Normative References
 719
 720    [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and
 721    Facilities", STD 13, RFC 1034, November 1987.
 722
 723    [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and
 724    Specifications", STD 13, RFC 1035, November 1987.
 725
 726    [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
 727    Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
 728
 729    [RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone
 730    Changes (DNS NOTIFY)", RFC 1996, August 1996.
 731
 732    [RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
 733    "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
 734    April 1997.
 735
 736    [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS
 737    Specification", RFC 2181, July 1997.
 738
 739    [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
 740    IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
 741
 742    [RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
 743    2671, August 1999.
 744
 745    [RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System",
 746    RFC 2673, August 1999.
 747
 748    [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B.
 749    Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
 750    RFC 2845, May 2000.
 751
 752
 753 D. Eastlake 3rd                                                [Page 13]
 754 \f
 755
 756 INTERNET-DRAFT           DNS IANA Considerations             August 2005
 757
 758
 759    [RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY
 760    RR)", September 2000.
 761
 762    [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
 763    Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
 764    the Domain Name System (DNS)", RFC 3363, August 2002.
 765
 766    [RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
 767    2002.
 768
 769    [RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
 770    Standards Track Code Points", BCP 100, RFC 4020, February 2005.
 771
 772    [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
 773    Rose, "DNS Security Introduction and Requirements", RFC 4033, March
 774    2005.
 775
 776    [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
 777    Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
 778    March 2005.
 779
 780    [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
 781    Rose, "Protocol Modifications for the DNS Security Extensions", RFC
 782    4035, March 2005.
 783
 784    [US-ASCII] - ANSI, "USA Standard Code for Information Interchange",
 785    X3.4, American National Standards Institute: New York, 1968.
 786
 787
 788
 789 Informative References
 790
 791    [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena
 792    Technical Plan - Name Service, April 1987,
 793
 794    [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
 795    Institute of Technology Artificial Intelligence Laboratory, June
 796    1981.
 797
 798    [RFC 1591] - Postel, J., "Domain Name System Structure and
 799    Delegation", RFC 1591, March 1994.
 800
 801    [RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
 802    "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
 803    September 2000.
 804
 805    [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS
 806    Names", RFC 2606, June 1999.
 807
 808    [insensitive] - Eastlake, D., "Domain Name System (DNS) Case
 809
 810
 811 D. Eastlake 3rd                                                [Page 14]
 812 \f
 813
 814 INTERNET-DRAFT           DNS IANA Considerations             August 2005
 815
 816
 817    Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt,
 818    work in progress.
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842
 843
 844
 845
 846
 847
 848
 849
 850
 851
 852
 853
 854
 855
 856
 857
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868
 869 D. Eastlake 3rd                                                [Page 15]
 870 \f
 871
 872 INTERNET-DRAFT           DNS IANA Considerations             August 2005
 873
 874
 875 Authors Addresses
 876
 877    Donald E. Eastlake 3rd
 878    Motorola Laboratories
 879    155 Beaver Street
 880    Milford, MA 01757 USA
 881
 882    Telephone:   +1-508-786-7554 (w)
 883    email:       Donald.Eastlake@motorola.com
 884
 885
 886
 887 Expiration and File Name
 888
 889    This draft expires February 2006.
 890
 891    Its file name is draft-ietf-dnsext-2929bis-01.txt.
 892
 893
 894
 895
 896
 897
 898
 899
 900
 901
 902
 903
 904
 905
 906
 907
 908
 909
 910
 911
 912
 913
 914
 915
 916
 917
 918
 919
 920
 921
 922
 923
 924
 925
 926
 927 D. Eastlake 3rd                                                [Page 16]
 928 \f