INTERNET-DRAFT                              Donald E. Eastlake 3rd (IBM)
                                                    Eric Brunner (Nokia)
                                                      Bill Manning (ISI)
Expires: February 2000                                       August 1999

draft-ietf-dnsind-iana-dns-00.txt



              Domain Name System (DNS) IANA Considerations
              ------ ---- ------ ----- ---- --------------




Status of This Document

   This draft, file name draft-ietf-dnsind-iana-dns-00.txt, is intended
   to become a Best Current Practice RFC.  Distribution of this document
   is unlimited. Comments should be sent to the DNS Working Group
   mailing list <namedroppers@internic.com> or to the authors.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months.  Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories as listed at <http://www.ietf.org/shadow.html>.




















D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 1]


INTERNET-DRAFT          DNS IANA Considerations              August 1999


Abstract

   Internet Assigned Number Authority (IANA) considerations are given
   for the allocation of Domain Name System (DNS) classes, RR types,
   operation codes, error codes, etc.



Table of Contents

      Status of This Document....................................1

      Abstract...................................................2
      Table of Contents..........................................2

      1. Introduction............................................3
      2. DNS Query/Response Header Structure.....................3
      2.1 One Spare Bit?.........................................4
      2.2 Opcode Assignment......................................4
      2.3 RCODE Assignment.......................................4
      3. DNS Resource Record Structure...........................5
      3.1 RR TYPE IANA Considerations............................7
      3.1.1 Special Note on the OPT RR...........................7
      3.1.2 Special Note on the SINK RR..........................8
      3.2 RR CLASS IANA Considerations...........................8
      3.3 IANA DNS Name Considerations...........................9
      3.3.1 Becoming Root........................................9
      3.3.1 Reserved TLDs in the IN CLASS........................9
      3.3.2 'Country Code' TLDs in the IN CLASS.................10
      3.3.3 Other TLDs in the IN CLASS..........................10
      4. Security Considerations................................11

      References................................................12

      Authors Addresses.........................................13
      Expiration and File Name..................................13
















D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 2]


INTERNET-DRAFT          DNS IANA Considerations              August 1999


1. Introduction

   The Domain Name System (DNS) provides a replicated distributed secure
   hierarchical database which stores "resource records" (RRs) by CLASS
   under hierarchical domain names.  This data is structured into
   CLASSes and zones which can be independently maintained.  See [RFC
   1034, 1035, 2136, 2181, 2535, etc.] familiarity with which is
   assumed.

   This document covers general IANA considerations applying across DNS
   query and response headers and all RRs.  There may be additional IANA
   considerations that apply to only a particular RR type or
   query/response opcode.  See the specific RFC defining that RR type or
   query/response opcode for such considerations if they have been
   defined.

   The terms of art used herein with respect to IANA Considerations are
   as defined in [RFC 2434].



2. DNS Query/Response Header Structure

   The header for DNS queries and responses contains field/bits in the
   following diagram taken from [RFC 2136/2535]:

                                              1  1  1  1  1  1
                0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
               |                      ID                       |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
               |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
               |                QDCOUNT/ZOCOUNT                |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
               |                ANCOUNT/PRCOUNT                |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
               |                NSCOUNT/UPCOUNT                 |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
               |                    ARCOUNT                    |
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   The ID field identifies the query and is echoed in the response so
   they can be matched.

   The QR bit indicates whether the header is for a query or a response.

   The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
   only in queries or only in responses, depending on the bit.  However,
   many DNS implementations copy the query header as the initial value


D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 3]


INTERNET-DRAFT          DNS IANA Considerations              August 1999


   of the response header without clearing bits.  Thus any attempt to
   use a "query" bit with a different meaning in a response or to define
   a query meaning for a "response" bit is dangerous and such meanings
   may only be assigned by an IETF standards action.

   The QDCOUNT, ANCOUNT, NSCOUNT, and ARCOUNT fields give the number of
   queries in the Query section, answer RRs in the Answer section, RRs
   in the Authority section, and informational RRs in the Additional
   Information section, respectively, for all opcodes except Update.
   These fields have the same structure and data type for update but are
   instead the counts for the Zone, Prerequisite, Update, and Additional
   Information sections.



2.1 One Spare Bit?

   While it would appear that the "Z" bit is spare, there have been DNS
   implementations for which that bit being on in a query meant that
   only a response from the primary server for a zone is acceptable.  It
   is believed that modern DNS implementations ignore this bit.
   Assigning a meaning to this bit requires an IETF standards action.



2.2 Opcode Assignment

   IANA DNS OpCode assignments are shown at <ftp://ftp.isi.edu/in-
   notes/iana/assignments/dns-parameters>.

   Currently the following OpCodes are assigned.

        OpCode Name                      Reference

         0     Query                     [RFC 1035]
         1     IQuery  (Inverse Query)   [RFC 1035]
         2     Status                    [RFC 1035]
         3     available for assignment
         4     Notify                    [RFC 1996]
         5     Update                    [RFC 2136]
        6-15  available for assignment

   New OpCode assignments require an IETF consensus.



2.3 RCODE Assignment

   Current IANA DNS RCODE assignments are shown at
   <ftp://ftp.isi.edu/in-notes/iana/assignments/dns-parameters>...


D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 4]


INTERNET-DRAFT          DNS IANA Considerations              August 1999


   The range of RCODEs is extended beyond four bits to twelve bits for
   implementations of DNS supporting the OPT RR (see Section 3.1.1).
   RCODEs can appear both at the top level of a DNS response in the
   header or inside TSIG RRs [RFC XXX3].  The TSIG RR has a 16 bit RCODE
   error field.

        RCODE  Name                                         Reference

         0     NoError   No Error                           [RFC 1035]
         1     FormErr   Format Error                       [RFC 1035]
         2     ServFail  Server Failure                     [RFC 1035]
         3     NXDomain  Non-Existent Domain                [RFC 1035]
         4     NotImp    Not Implemented                    [RFC 1035]
         5     Refused   Query Refused                      [RFC 1035]
         6     YXDomain  Name Exists when it should not     [RFC 2136]
         7     YXRRSet   RR Set Exists when it should not   [RFC 2136]
         8     NXRRSet   RR Set that should exist does not  [RFC 2136]
         9     NotAuth   Server Not Authoritative for zone  [RFC 2136]
        10     NotZone   Name not contained in zone         [RFC 2136]
        11-15            available for assignment
        16     BADSIG    Signature Failure                  [RFC XXX3]
        17     BADKEY    Key not recognized                 [RFC XXX3]
        18     BADTIME   Signature out of time window       [RFC XXX3]
        19-0xFFFF        available for assignment


   Since it is important that RCODEs be understood for interoperability,
   new RCODE assignment requires an IETF consensus.



3. DNS Resource Record Structure

   All RRs have the same top level format shown in the figure below
   taken from RFC 1035:

















D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 5]


INTERNET-DRAFT          DNS IANA Considerations              August 1999


                                       1  1  1  1  1  1
         0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |                                               |
       /                                               /
       /                      NAME                     /
       |                                               |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |                      TYPE                     |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |                     CLASS                     |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |                      TTL                      |
       |                                               |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |                   RDLENGTH                    |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
       /                     RDATA                     /
       /                                               /
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   NAME is an owner name, i.e., the name of the node to which this
   resource record pertains.  Names are specific to a CLASS as described
   in section 3.2.  Names consist of an ordered sequence of one or more
   labels each of which has a label type [RFC 1035].  The last label in
   each name is "root" which is wire encoded as a single zero octet.
   New label types are assigned as provided in [RFC XXX1].

   TYPE is two octets containing one of the RR TYPE codes. See section
   3.1.

   CLASS is two octets containing one of the RR CLASS codes.  See
   section 3.2.

   TTL is a 32 bit unsigned integer that specifies the time interval
   that the resource record may be cached before the source of the
   information should again be consulted.  Zero is interpreted to mean
   that the RR can only be used for the transaction in progress.

   RDLENGTH is an unsigned 16 bit integer that specifies the length in
   octets of the RDATA field.

   RDATA is a variable length string of octets that describes the
   resource.  The format of this information varies according to the
   TYPE and in some cases the CLASS of the resource record.







D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 6]


INTERNET-DRAFT          DNS IANA Considerations              August 1999


3.1 RR TYPE IANA Considerations

   There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
   and Meta-TYPEs.  QTYPES can only be used in queries.  Meta-TYPEs
   designate transient data associate with an particular DNS message and
   in some cases can also be used in queries.  Thus far, data types have
   been assigned from 1 upwards plus the block from 100 through 103
   while Q and Meta Types have been assigned from 255 downwards.  IANA
   RR TYPE assignments are documented at <ftp://ftp.isi.edu/in-
   notes/iana/assignments/dns-parameters>.

   There are currently three Meta-types: TSIG [RFC XXX3], TKEY, and OPT
   [RFC XXX1].

   There are currently five Qtypes: * (all), MAILA, MAILB, AXFR, and
   IXFR.

   RR TYPE zero is used as a special indicator for the SIG RR [RFC 2535]
   and in other circumstances and must never be allocated for ordinary
   use.

   Remaining types in the range 0x0001 to 0x7FFF are assigned by
   authority of IETF consensus.  The current pattern of assigning
   regular data types from 1 upwards and Q and Meta types from 255
   downward should continue until that range is exhausted.

   Types from 0x8000 through 0xFEFF are assigned based on RFC
   publication.

   Types from 0xFF00 through 0xFFFF are for private experimental use.
   Because their use is not coordinated, it may conflict between
   different experiments.



3.1.1 Special Note on the OPT RR

   The OPT (OPTion) RR, number (TBD), is specified in [RFC XXX1].  Its
   primary purpose is to extend the effective field size of various DNS
   fields including RCODE, label type, OpCode, flag bits, and RDATA
   size.  In particular, for resolvers and servers that recognize it, it
   extends the RCODE field from 4 to 12 bits.

   IANA considerations for label types are given in [RFC XXX1].








D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 7]


INTERNET-DRAFT          DNS IANA Considerations              August 1999


3.1.2 Special Note on the SINK RR

   The (Kitchen) SINK RR, number 40, is specified in RFC [XXX2].  It is
   designed to accommodate demands for proprietary RRs and provides
   flexible encoding and semantic labeling of the RDATA potion.  This
   should virtually eliminate the need to allocate RR types codes for
   private or proprietary purposes.



3.2 RR CLASS IANA Considerations

   DNS CLASSes have been little used but constitute another dimension of
   the DNS distributed database.  In particular, there is no necessary
   relationship between the namespace or roots servers for one CLASS and
   those for another CLASS.  A name can have completely different
   meanings in different CLASSes.  However, as global networking and DNS
   have evolved, the IN, or Internet, CLASS has dominated DNS use.

   IANA DNS CLASS assignments are shown at <ftp://ftp.isi.edu/in-
   notes/iana/assignments/dns-parameters>.  There are two subcategories
   of DNS CLASSes: normal data containing classes and QCLASSes that are
   only meaningful in queries or updates.  The current data class
   assignments are as follows: 1 - Internet (IN), 3 - Chaos (CH), and 4
   - Hesiod (HS).  The currently assigned Q classes are as follows: 255
   - Any and 254 - None.

   Allocation of CLASS 0x0000 requires an IETF standards action.

   Allocation of remaining CLASSes in the range of 0x0001-0x00FF are by
   IETF consensus with data classes given the lowest available value and
   QCLASSes the highest available value in that range until that range
   is exhausted.

   Allocation of CLASSes in the range 0x0100 through 0x7FFF is by IETF
   consensus.

   Allocation of CLASSes in the range 0x8000 through 0xFEFF is by RFC
   publication.

   CLASSes in the range 0xF000 through 0xFFFE are for private
   experimental use.  Because their use is not coordinated, it may
   conflict between different experiments.

   CLASS 0xFFFF can only be assigned by an IETF standards action.







D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 8]


INTERNET-DRAFT          DNS IANA Considerations              August 1999


3.3 IANA DNS Name Considerations

   TheHesiod [Dyer 87] and Chaos CLASSes are essentially for local use.
   (Chaos was a network system implemented at MIT.)  The IN CLASS is the
   only DNS CLASS in global use on the Internet at this time.



3.3.1 Becoming Root

   In practice, it is quite easy to put up a set of root servers.  DNS
   resolvers which use those root servers will see the namespace they
   support.  DNS has only downward pointers from zone to subzone and no
   upward pointers going from zone to superzone.  Thus, in creating a
   root zone, it works technically to pick whatever top level domains
   (TLDs) you want including, if you wish, TLDs that are not generally
   recognized.

   Setting up your own root zone like this is commonly done within local
   enclaves to hide some local names, for security and efficiency.  In
   some cases, local TLDs are added.  But for the global Internet, the
   use of variant root zones would lead to non-interoperability at the
   application level.  Users would find that email addresses didn't work
   or addressed different accounts for those using different root zone
   contents.  Links in web pages wouldn't work or would address
   different web resources for those using different root zone contents.
   As a result, despite strenuous attempts to promote alternatives, no
   significant portion of the global Internet has ever used other than
   the IETF recommended root zone contents except, in some cases, for
   strictly local names.



3.3.1 Reserved TLDs in the IN CLASS

   All single octet length top level domain (TLD) names in the IN class
   are reserved as are all TLDs containing any octets that are not ASCII
   letters or digits.  One reason for reserving single octet TLDs is
   that, should the root zone ever get very large, there are technical
   solutions which would be eased by having the single byte TLDs
   available.

   [For like reasons, it is recommended that within TLDs or indeed
   within any zone that is or might become very large, all single octet
   names be reserved.  However, this decision is up to the authority for
   each non-root zone.]

   Binary label TLDs [RFC XXX4] and other new TLD label data types are
   reserved.



D. Eastlake 3rd, E. Brunner, B. Manning                         [Page 9]


INTERNET-DRAFT          DNS IANA Considerations              August 1999


   The above reservations also provides a means of escape should other
   name allocation paint the IN CLASS namespace into a corner.

   Assignment of the above reserved names requires an IETF consensus.

   Finally, the four TLDs "example", "invalid", "localhost", and "test"
   are reserved as described in [RFC 2606].



3.3.2 'Country Code' TLDs in the IN CLASS

   All two octet length TLDs in the IN class consisting of letters are
   reserved for assignment to territories.  Those (1) allocated by [ISO
   3166] and (2) allocated by the Universal Postal Union [UPU] and
   reserved in [ISO 3166] even though not formally assigned by [ISO
   3166] (e.g., a few British Channel Islands), are assigned as so
   allocated by the generally recognized acting government of the area
   associated with the "country code" or on a first come first served
   basis to a designated registry if there is no such government or the
   government has not exercised control.  In addition, due to historical
   factors and consistent with the normal diplomatic usage of special
   consideration for founders, the United States of America, as founder
   of the Internet, is also assigned the three letter TLDs "gov" and
   "mil".  A country code for a territory with a generally recognized
   acting government should be considered part of the territory of that
   government.  Decisions by said government as to who should control
   the DNS for that TLD are final and unappealable.

   Country codes consisting of a letter and a digit or two digits are
   not currently used by [ISO 3166] or the [UPU].  However, to permit
   possible expansion of the two octet country codes, they are reserved
   for future allocation as described in the previous paragraph.



3.3.3 Other TLDs in the IN CLASS

   IANA manages the "arpa" and "int" TLDs.  The "arpa" TLD is assigned
   for use in the IPv4 inverse mapping and IANA delegates /8 subzones to
   holders of a /8 chunk of address space, including the regional
   address registries.  "int" includes the IPv6 inverse address mapping
   which is at "ip6.int", international registrations at "reg.int", and
   also provides for recognized international organizations.  IANA
   considerations for IP address assignment are given elsewhere.

   Control and assignment of various other existing or prospective IN
   CLASS TLDs is currently in a state of flux being transfered to the
   ICANN (www.icann.org) DNSO (Domain Name Support Organization,
   www.dnso.org).  Traditionally "edu" was used for educational


D. Eastlake 3rd, E. Brunner, B. Manning                        [Page 10]


INTERNET-DRAFT          DNS IANA Considerations              August 1999


   institutions, "net" for network infrastructure organizations, "com"
   for commercial organizations, and "org" for other non-profit
   organizations.

   New registrations in "edu" are currently restricted to four year or
   longer institutions of higher learning.



4. Security Considerations

   This document addresses IANA considerations in the allocation of
   general DNS parameters, not security.  See [RFC 2535] for secure DNS
   considerations.






































D. Eastlake 3rd, E. Brunner, B. Manning                        [Page 11]


INTERNET-DRAFT          DNS IANA Considerations              August 1999


References

   [Dyer 87] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
   Plan - Name Service, April 1987,

   [ISO 3166] - Codes for the representation of names of countries.

   [RFC 1034] - P. Mockapetris, "Domain Names - Concepts and
   Facilities", STD 13, November 1987.

   [RFC 1035] - P. Mockapetris, "Domain Names - Implementation and
   Specifications", STD 13, November 1987.

   [RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone
   Changes (DNS NOTIFY)", August 1996.

   [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
   Requirement Levels", March 1997.

   [RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
   Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.

   [RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS
   Specification", July 1997.

   [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
   in RFCs", T.  Narten, H. Alvestrand, October 1998.

   [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
   March 1999.

   [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
   June 1999.

   [RFC XXX1] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", xxx
   1999 (draft-ietf-dnsind-edns0-*.txt).

   [RFC XXX2] - D. Eastlake, "The Kitchen Sink DNS Resource Record", xxx
   1999 (draft-ietf-dnsind-kitchen-sink-*.txt).

   [RFC XXX3] - P. Vixie, O. Gundmundsson, D. Eastlake, B. Wellington,
   "Secret Key Transaction Signatures for DNS (TSIG)" xxx 1999 (draft-
   ietf-dnsind-tsig-*.txt).

   [RFC XXX4] - M. Crawford, "Binary Labels in the Domain Name System",
   xxx 1999 (draft-ietf-dnsind-binary-labels-*.txt).

   [UPU] - <http://www.upu/int>




D. Eastlake 3rd, E. Brunner, B. Manning                        [Page 12]


INTERNET-DRAFT          DNS IANA Considerations              August 1999


Authors Addresses

   Donald E. Eastlake 3rd
   IBM
   65 Shindegan Hill Road
   Carmel, NY 10512 USA

   Telephone:   +1-914-784-7913 (w)
                +1-914-276-2668 (h)
   fax:         +1-914-784-3833 (w)
   email:       dee3@us.ibm.com


   Eric Brunner
   Mokia Research Center
   3 Burlington Woods Drive, Suite 250
   Burlington, MA 01803 USA

   Telephone:   +1 781-359-5159
   fax:         +1 781-359-5196
   email:       brunner@maine.rr.com


   Bill Manning
   USC/ISI
   4676 Admiralty Way, #1001
   Marina del Rey, CA 90292 USA

   Telephone:   +1 310 822 1511
   email:       bmanning@isi.edu



Expiration and File Name

   This draft expires February 2000.

   Its file name is draft-ietf-dnsind-iana-dns-00.txt.














D. Eastlake 3rd, E. Brunner, B. Manning                        [Page 13]