doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc6895.txt b/doc/rfc/rfc6895.txt
new file mode 100644
index 0000000..91f21c3
--- /dev/null
+++ b/doc/rfc/rfc6895.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
+Request for Comments: 6895                                        Huawei
+BCP: 42                                                       April 2013
+Obsoletes: 6195
+Updates: 1183, 2845, 2930, 3597
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+              Domain Name System (DNS) IANA Considerations
+
+Abstract
+
+   This document specifies Internet Assigned Numbers Authority (IANA)
+   parameter assignment considerations for the allocation of Domain Name
+   System (DNS) resource record types, CLASSes, operation codes, error
+   codes, DNS protocol message header bits, and AFSDB resource record
+   subtypes.  It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930,
+   and 3597.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6895.
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Eastlake                  Best Current Practice                 [Page 1]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Terminology ................................................3
+   2. DNS Query/Response Headers ......................................3
+      2.1. One Spare Bit? .............................................4
+      2.2. OpCode Assignment ..........................................4
+      2.3. RCODE Assignment ...........................................4
+   3. DNS Resource Records ............................................6
+      3.1. RRTYPE IANA Considerations .................................7
+           3.1.1. DNS RRTYPE Allocation Policy ........................8
+           3.1.2. DNS RRTYPE Expert Guidelines .......................10
+           3.1.3. Special Note on the OPT RR .........................10
+           3.1.4. The AFSDB RR Subtype Field .........................10
+      3.2. RR CLASS IANA Considerations ..............................11
+      3.3. Label Considerations ......................................13
+           3.3.1. Label Types ........................................13
+           3.3.2. Label Contents and Use .............................13
+   4. Security Considerations ........................................14
+   5. IANA Considerations ............................................14
+   Appendix A. RRTYPE Allocation Template ............................15
+   Appendix B. Changes from RFC 6195 .................................16
+   Normative References ..............................................17
+   Informative References ............................................18
+   Acknowledgements ..................................................19
+
+1.  Introduction
+
+   The Domain Name System (DNS) provides replicated distributed secure
+   hierarchical databases that store "resource records" (RRs) under
+   domain names.  DNS data is structured into CLASSes and zones that can
+   be independently maintained.  Familiarity with [RFC1034], [RFC1035],
+   [RFC2136], [RFC2181], and [RFC4033] is assumed.
+
+   This document provides, either directly or by reference, the general
+   IANA parameter assignment considerations that apply across DNS query
+   and response headers and all RRs.  There may be additional IANA
+   considerations that apply to only a particular RRTYPE or
+   query/response OpCode.  See the specific RFC defining that RRTYPE or
+   query/response OpCode for such considerations if they have been
+   defined, except for AFSDB RR considerations [RFC1183], which are
+   included herein.  This RFC obsoletes [RFC6195]; however, the only
+   significant changes are those to the RRTYPE IANA allocation process,
+   aimed at streamlining it and clarifying the expected behavior of the
+   parties involved, and the closing of the AFSDB subtype registry.
+
+   IANA currently maintains a web page of DNS parameters available from
+   <http://www.iana.org>.
+
+
+
+Eastlake                  Best Current Practice                 [Page 2]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+1.1.  Terminology
+
+   "Standards Action", "IETF Review", "Specification Required", and
+   "Private Use" are as defined in [RFC5226].
+
+2.  DNS Query/Response Headers
+
+   The header for DNS queries and responses contains field/bits in the
+   following diagram taken from [RFC2136]:
+
+                                            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, and CD bits are each theoretically meaningful
+   only in queries or only in responses, depending on the bit.  The AD
+   bit was only meaningful in responses but is expected to have a
+   separate but related meaning in queries (see Section 5.7 of
+   [RFC6840]).  Only the RD and CD bits are expected to be copied from
+   the query to the response; however, some DNS implementations copy all
+   the query header as the initial value of the response header.  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 may be
+   dangerous, given the existing implementation.  Meanings for these
+   bits may only be assigned by a Standards Action.
+
+   The unsigned integer fields query count (QDCOUNT), answer count
+   (ANCOUNT), authority count (NSCOUNT), and additional information
+   count (ARCOUNT) express the number of records in each section for all
+   OpCodes except Update [RFC2136].  These fields have the same
+
+
+
+
+Eastlake                  Best Current Practice                 [Page 3]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+   structure and data type for Update but are instead the counts for the
+   zone (ZOCOUNT), prerequisite (PRCOUNT), update (UPCOUNT), and
+   additional information (ARCOUNT) sections.
+
+2.1.  One Spare Bit?
+
+   There have been ancient DNS implementations for which the Z bit being
+   on in a query meant that only a response from the primary server for
+   a zone is acceptable.  It is believed that current DNS
+   implementations ignore this bit.
+
+   Assigning a meaning to the Z bit requires a Standards Action.
+
+2.2.  OpCode Assignment
+
+   Currently, DNS OpCodes are assigned as follows:
+
+        OpCode Name                                Reference
+
+         0     Query                               [RFC1035]
+         1     IQuery (Inverse Query, OBSOLETE)    [RFC3425]
+         2     Status                              [RFC1035]
+         3     Unassigned
+         4     Notify                              [RFC1996]
+         5     Update                              [RFC2136]
+        6-15   Unassigned
+
+   Although the Status OpCode is reserved in [RFC1035], its behavior has
+   not been specified.  New OpCode assignments require a Standards
+   Action with early allocation permitted as specified in [RFC4020].
+
+2.3.  RCODE Assignment
+
+   It would appear from the DNS header above that only four bits of
+   RCODE, or response/error code, are available.  However, RCODEs can
+   appear not only at the top level of a DNS response but also inside
+   TSIG RRs [RFC2845], TKEY RRs [RFC2930], and extended by OPT RRs
+   [RFC6891].  The OPT RR provides an 8-bit extension to the 4 header
+   bits, resulting in a 12-bit RCODE field, and the TSIG and TKEY RRs
+   have a 16-bit field designated in their RFCs as the "Error" field.
+
+   Error codes appearing in the DNS header and in these other RR types
+   all refer to the same error code space with the exception of error
+   code 16, which has a different meaning in the OPT RR than in the TSIG
+   RR, and error code 9, whose variations are described after the table
+   below.  The duplicate assignment of 16 was accidental.  To the extent
+   that any prior RFCs imply any sort of different error number space
+   for the OPT, TSIG, or TKEY RRs, they are superseded by this unified
+
+
+
+Eastlake                  Best Current Practice                 [Page 4]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+   DNS error number space.  (This paragraph is the reason this document
+   updates [RFC2845] and [RFC2930].)  With the existing exceptions of
+   error numbers 9 and 16, the same error number must not be assigned
+   for different errors even if they would only occur in different RR
+   types.  See table below.
+
+          RCODE   Name    Description                        Reference
+          Decimal
+            Hexadecimal
+
+           0    NoError   No Error                           [RFC1035]
+           1    FormErr   Format Error                       [RFC1035]
+           2    ServFail  Server Failure                     [RFC1035]
+           3    NXDomain  Non-Existent Domain                [RFC1035]
+           4    NotImp    Not Implemented                    [RFC1035]
+           5    Refused   Query Refused                      [RFC1035]
+           6    YXDomain  Name Exists when it should not     [RFC2136]
+           7    YXRRSet   RR Set Exists when it should not   [RFC2136]
+           8    NXRRSet   RR Set that should exist does not  [RFC2136]
+           9    NotAuth   Server Not Authoritative for zone  [RFC2136]
+           9    NotAuth   Not Authorized                     [RFC2845]
+          10    NotZone   Name not contained in zone         [RFC2136]
+
+          11 - 15
+         0xB - 0xF        Unassigned
+
+          16    BADVERS   Bad OPT Version                    [RFC6891]
+          16    BADSIG    TSIG Signature Failure             [RFC2845]
+          17    BADKEY    Key not recognized                 [RFC2845]
+          18    BADTIME   Signature out of time window       [RFC2845]
+          19    BADMODE   Bad TKEY Mode                      [RFC2930]
+          20    BADNAME   Duplicate key name                 [RFC2930]
+          21    BADALG    Algorithm not supported            [RFC2930]
+          22    BADTRUNC  Bad Truncation                     [RFC4635]
+
+          23 - 3,840
+      0x0017 - 0x0F00     Unassigned
+
+       3,841 - 4,095
+      0x0F01 - 0x0FFF     Reserved for Private Use
+
+       4,096 - 65,534
+      0x1000 - 0xFFFE     Unassigned
+
+      65,535
+      0xFFFF              Reserved; can only be allocated by Standards
+                          Action.
+
+
+
+
+Eastlake                  Best Current Practice                 [Page 5]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+      Note on error number 9 (NotAuth): This error number means either
+      "Not Authoritative" [RFC2136] or "Not Authorized" [RFC2845].  If 9
+      appears as the RCODE in the header of a DNS response without a
+      TSIG RR or with a TSIG RR having a zero error field, then it means
+      "Not Authoritative".  If 9 appears as the RCODE in the header of a
+      DNS response that includes a TSIG RR with a non-zero error field,
+      then it means "Not Authorized".
+
+   Since it is important that RCODEs be understood for interoperability,
+   assignment of a new RCODE in the ranges listed above as "Unassigned"
+   requires an IETF Review.
+
+3.  DNS Resource Records
+
+   All RRs have the same top-level format, shown in the figure below
+   taken from [RFC1035].
+
+                                          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 [RFC1035] [RFC6891].
+
+   TYPE is a 2-octet unsigned integer containing one of the RRTYPE
+   codes.  See Section 3.1.
+
+   CLASS is a 2-octet unsigned integer containing one of the RR CLASS
+   codes.  See Section 3.2.
+
+
+
+Eastlake                  Best Current Practice                 [Page 6]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+   TTL is a 4-octet (32-bit) unsigned integer that specifies, for data
+   TYPEs, the number of seconds 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 constitutes the
+   resource.  The format of this information varies according to the
+   TYPE and, in some cases, the CLASS of the resource record.
+
+3.1.  RRTYPE IANA Considerations
+
+   There are three subcategories of RRTYPE numbers: data TYPEs, QTYPEs,
+   and Meta-TYPEs.
+
+   Data TYPEs are the means of storing data.  QTYPES can only be used in
+   queries.  Meta-TYPEs designate transient data associated with a
+   particular DNS message and, in some cases, can also be used in
+   queries.  Thus far, data TYPEs have been assigned from 1 upward, plus
+   the block from 100 through 103, and from 32,768 upward, while Q and
+   Meta-TYPEs have been assigned from 255 downward except for the OPT
+   Meta-RR, which is assigned TYPE 41.  There have been DNS
+   implementations that made caching decisions based on the top bit of
+   the bottom byte of the RRTYPE.
+
+   There are currently three Meta-TYPEs assigned: OPT [RFC6891], TSIG
+   [RFC2845], and TKEY [RFC2930].  There are currently five QTYPEs
+   assigned: * (ALL/ANY), MAILA, MAILB, AXFR, and IXFR.
+
+   Allocated RRTYPEs have mnemonics that must be completely disjoint
+   from the mnemonics used for CLASSes and that must match the regular
+   expression below.  In addition, the generic CLASS and RRTYPE names
+   specified in Section 5 of [RFC3597] cannot be assigned as new RRTYPE
+   mnemonics.
+
+                         [A-Z][A-Z0-9\-]*[A-Z0-9]
+                                  but not
+                            (TYPE|CLASS)[0-9]*
+
+
+
+
+
+
+
+
+
+
+Eastlake                  Best Current Practice                 [Page 7]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+   Considerations for the allocation of new RRTYPEs are as follows:
+
+      Decimal
+    Hexadecimal       Assignment Policy
+
+         0
+    0x0000            RRTYPE zero is used as a special indicator for the
+                      SIG(0) RR [RFC2931] [RFC4034] and in other
+                      circumstances and must never be allocated for
+                      ordinary use.
+
+         1 - 127
+    0x0001 - 0x007F   Remaining RRTYPEs in this range are assigned for
+                      data TYPEs by the DNS RRTYPE Allocation Policy as
+                      specified in Section 3.1.1.
+
+         128 - 255
+    0x0080 - 0x00FF   Remaining RRTYPEs in this range are assigned for Q
+                      and Meta-TYPEs by the DNS RRTYPE Allocation Policy
+                      as specified in Section 3.1.1.
+
+       256 - 61,439
+    0x0100 - 0xEFFF   Remaining RRTYPEs in this range are assigned for
+                      data RRTYPEs by the DNS RRTYPE Allocation Policy
+                      as specified in Section 3.1.1.  (32,768 and 32,769
+                      (0x8000 and 0x8001) have been assigned.)
+
+    61,440 - 65,279
+    0xF000 - 0xFEFF   Reserved for future use.  IETF Review required to
+                      define use.
+
+    65,280 - 65,534
+    0xFF00 - 0xFFFE   Reserved for Private Use.
+
+    65,535
+    0xFFFF            Reserved (Standards Action)
+
+3.1.1.  DNS RRTYPE Allocation Policy
+
+   Parameter values specified in Section 3.1 above, as assigned based on
+   DNS RRTYPE Allocation Policy, are allocated by Expert Review if they
+   meet the two requirements listed below.  There will be a pool of a
+   small number of Experts appointed by the IESG.  Each application will
+   be judged by an Expert selected by IANA.  In any case where the
+   selected Expert is unavailable or states they have a conflict of
+   interest, IANA may select another Expert from the pool.  Some
+   guidelines for the Experts are given in Section 3.1.2.
+
+
+
+
+Eastlake                  Best Current Practice                 [Page 8]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+   RRTYPEs that do not meet the requirements below may nonetheless be
+   allocated by a Standards Action with early allocation permitted as
+   specified in [RFC4020].
+
+   1. A complete template as specified in Appendix A has been posted to
+      the dns-rrtype-applications@ietf.org mailing list and received by
+      the Expert.
+
+      Note that the posting of partially completed, draft, or formally
+      submitted templates to dnsext@ietf.org by the applicant or Expert
+      for comment and discussion is highly encouraged.  Before formal
+      submission of an RRTYPE template, we recommend submitting it for
+      community review and considering the responses in order to reduce
+      the probability of initial rejection and the need for modification
+      and resubmission.
+
+   2. The RR for which an RRTYPE code is being requested is either (a) a
+      data TYPE that can be handled as an Unknown RR as described in
+      [RFC3597] or (b) a Meta-TYPE whose processing is optional, i.e.,
+      it is safe to simply discard RRs with that Meta-TYPE in queries or
+      responses.
+
+      Note that such RRs may include additional section processing,
+      provided such processing is optional.
+
+   After the applicant submits their formal application to IANA by
+   sending the completed template specified in Appendix A to the
+   dns-rrtype-applications@ietf.org mailing list, IANA appoints an
+   Expert and sends the completed template to the Expert, copying the
+   applicant.  No more than two weeks after receiving the application,
+   the Expert shall explicitly approve or reject the application,
+   informing IANA, the applicant, and the dnsext@ietf.org mailing list.
+   A rejection should include the reason for rejection and may include
+   suggestions for improvement.  The Expert should consult with other
+   technical experts and the dnsext@ietf.org mailing list as necessary.
+   If the Expert does not approve the application within this period, it
+   is considered rejected.  IANA should report non-responsive Experts to
+   the IESG.
+
+   IANA shall maintain a public archive of approved templates.  In
+   addition, if the required description of the RRTYPE applied for is
+   referenced by URL, a copy of the document so referenced should be
+   included in the archive.
+
+
+
+
+
+
+
+
+Eastlake                  Best Current Practice                 [Page 9]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+3.1.2.  DNS RRTYPE Expert Guidelines
+
+   The Designated Expert should normally be lenient, preferring to
+   approve most requests.  However, the Expert should usually reject any
+   RRTYPE allocation request that meets one or more of the following
+   criteria:
+
+   1. The request was documented in a manner that was not sufficiently
+      clear or complete to evaluate or implement.  (Additional
+      documentation can be provided during the Expert Review period.)
+
+   2. The proposed RRTYPE or RRTYPEs affect DNS processing and do not
+      meet the criteria in point 2 of Section 3.1.1 above.
+
+   3. Application use as documented makes incorrect assumptions about
+      DNS protocol behavior, such as wildcards, CNAME, DNAME, etc.
+
+   4. An excessive number of RRTYPE values is being requested when the
+      purpose could be met with a smaller number of values or with
+      Private Use values.
+
+3.1.3.  Special Note on the OPT RR
+
+   The OPT (OPTion) RR (RRTYPE 41) and its IANA considerations are
+   specified in [RFC6891].  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.
+
+3.1.4.  The AFSDB RR Subtype Field
+
+   The AFSDB RR [RFC1183] is a CLASS-insensitive RR that has the same
+   RDATA field structure as the MX RR [RFC1035], but the 16-bit unsigned
+   integer field at the beginning of the RDATA is interpreted as a
+   subtype as shown below.  Use of the AFSDB RR to locate AFS cell
+   database servers was deprecated by [RFC5864].  This subtype registry
+   is hereby closed, and allocation of new subtypes is no longer
+   permitted.
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                  Best Current Practice                [Page 10]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+      Decimal
+    Hexadecimal       Assignment Policy
+
+         0
+    0x0000            Reserved; registry closed
+
+         1
+    0x0001            AFS v3.0 Location Service [RFC1183]
+
+         2
+    0x0002            DCE/NCA root cell directory node [RFC1183]
+
+         3 - 65,279
+    0x0003 - 0xFEFF   Not allocated; registry closed
+
+    65,280 - 65,534
+    0xFF00 - 0xFFFE   Private Use
+
+    65,535
+    0xFFFF            Reserved; registry closed
+
+3.2.  RR CLASS IANA Considerations
+
+   There are currently two subcategories of DNS CLASSes: normal, data-
+   containing classes; and QCLASSes that are only meaningful in queries
+   or updates.
+
+   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 root servers for one data CLASS
+   and those for another data CLASS.  The same DNS NAME can have
+   completely different meanings in different CLASSes.  The label types
+   are the same, and the null label is usable only as root in every
+   CLASS.  As global networking and DNS have evolved, the IN, or
+   Internet, CLASS has dominated DNS use.
+
+   As yet, there has not been a requirement for "Meta-CLASSes".  That
+   would be a CLASS to designate transient data associated with a
+   particular DNS message, which might be usable in queries.  However,
+   it is possible that there might be a future requirement for one or
+   more "Meta-CLASSes".
+
+   Assigned CLASSes have mnemonics that must be completely disjoint from
+   the mnemonics used for RRTYPEs and that must match the regular
+   expression below.  In addition, the generic CLASS and RRTYPE names
+   specified in Section 5 of [RFC3597] cannot be assigned as new CLASS
+   mnemonics.
+
+
+
+
+Eastlake                  Best Current Practice                [Page 11]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+                         [A-Z][A-Z0-9\-]*[A-Z0-9]
+                                  but not
+                           (CLASS|TYPE)[0-9]*
+
+   The current CLASS assignments and considerations for future
+   assignments are as follows:
+
+      Decimal
+    Hexadecimal       Assignment / Policy, Reference
+
+         0
+    0x0000            Reserved; assignment requires a Standards Action.
+
+         1
+    0x0001            Internet (IN) [RFC1035]
+
+         2
+    0x0002            Available for assignment by IETF Review as a data
+                      CLASS.
+
+         3
+    0x0003            Chaos (CH) [Moon1981]
+
+         4
+    0x0004            Hesiod (HS) [Dyer1987]
+
+         5 - 127
+    0x0005 - 0x007F   Available for assignment by IETF Review for data
+                      CLASSes only.
+
+       128 - 253
+    0x0080 - 0x00FD   Available for assignment by IETF Review for
+                      QCLASSes and Meta-CLASSes only.
+
+       254
+    0x00FE            QCLASS NONE [RFC2136]
+
+       255
+    0x00FF            QCLASS * (ANY) [RFC1035]
+
+       256 - 32,767
+    0x0100 - 0x7FFF   Available for assignment by IETF Review.
+
+    32,768 - 57,343
+    0x8000 - 0xDFFF   Available for assignment to data CLASSes only;
+                      Specification Required.
+
+
+
+
+
+Eastlake                  Best Current Practice                [Page 12]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+    57,344 - 65,279
+    0xE000 - 0xFEFF   Available for assignment to QCLASSes and
+                      Meta-CLASSes only; Specification Required.
+
+    65,280 - 65,534
+    0xFF00 - 0xFFFE   Private Use
+
+    65,535
+    0xFFFF            Reserved; can only be assigned by a Standards
+                      Action.
+
+3.3.  Label Considerations
+
+   DNS NAMEs are sequences of labels [RFC1035].
+
+3.3.1.  Label Types
+
+   At the present time, there are two categories of label types: data
+   labels and compression labels.  Compression labels are pointers to
+   data labels elsewhere within an RR or DNS message and are intended to
+   shorten the wire encoding of NAMEs.
+
+   The two existing data label types are sometimes referred to as Text
+   and Binary.  Text labels can, in fact, include any octet value
+   including zero-value octets, but many current uses involve only
+   printing ASCII characters [US-ASCII].  For retrieval, Text labels are
+   defined to treat ASCII uppercase and lowercase letter codes as
+   matching [RFC4343].  Binary labels are bit sequences [RFC2673].  The
+   Binary Label type is Historic [RFC6891].
+
+3.3.2.  Label Contents and Use
+
+   The last label in each NAME is "ROOT", which is the zero-length
+   label.  By definition, the null or ROOT label cannot be used for any
+   other NAME purpose.
+
+   NAMEs are local to a CLASS.  The Hesiod [Dyer1987] and Chaos
+   [Moon1981] CLASSes are for essentially local use.  The IN, or
+   Internet, CLASS is thus the only DNS CLASS in global use on the
+   Internet at this time.
+
+   A somewhat out-of-date description of name allocation in the IN CLASS
+   is given in [RFC1591].  Some information on reserved top-level domain
+   names is in BCP 32 [RFC2606].
+
+
+
+
+
+
+
+Eastlake                  Best Current Practice                [Page 13]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+4.  Security Considerations
+
+   This document addresses IANA considerations in the allocation of
+   general DNS parameters, not security.  See [RFC4033], [RFC4034], and
+   [RFC4035] for secure DNS considerations.
+
+5.  IANA Considerations
+
+   This document consists entirely of DNS IANA considerations.
+
+   IANA has established a process for accepting Appendix A templates and
+   selecting an Expert from those appointed to review such template form
+   applications.  IANA forwards the template to the Expert, copying the
+   applicant.  IANA archives and makes available all approved RRTYPE
+   allocation templates and referred documentation (unless it is readily
+   available at a stable URI).  It is the duty of the applicant to post
+   the formal application template to the
+   dns-rrtype-applications@ietf.org mailing list, which IANA will
+   monitor.  The dnsext@ietf.org mailing list is for community
+   discussion and comment.  See Section 3.1 and Appendix A for more
+   details.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                  Best Current Practice                [Page 14]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+Appendix A.  RRTYPE Allocation Template
+
+                 DNS RRTYPE PARAMETER ALLOCATION TEMPLATE
+
+   When ready for formal consideration, this template is to be submitted
+   to IANA for processing by emailing the template to dns-rrtype-
+   applications@ietf.org.
+
+   A. Submission Date:
+
+   B.1 Submission Type:  [ ] New RRTYPE  [ ] Modification to RRTYPE
+   B.2 Kind of RR:  [ ] Data RR  [ ] Meta-RR
+
+   C. Contact Information for submitter (will be publicly posted):
+      Name:                            Email Address:
+      International telephone number:
+      Other contact handles:
+
+   D. Motivation for the new RRTYPE application.
+      Please keep this part at a high level to inform the Expert and
+      reviewers about uses of the RRTYPE.  Most reviewers will be DNS
+      experts that may have limited knowledge of your application space.
+
+   E. Description of the proposed RR type.
+      This description can be provided in-line in the template, as an
+      attachment, or with a publicly available URL.
+
+   F. What existing RRTYPE or RRTYPEs come closest to filling that need
+      and why are they unsatisfactory?
+
+   G. What mnemonic is requested for the new RRTYPE (optional)?
+
+      Note: If a mnemonic is not supplied, not allowed, or duplicates an
+      existing RRTYPE or CLASS mnemonic, the Expert will assign a
+      mnemonic.
+
+   H. Does the requested RRTYPE make use of any existing IANA registry
+      or require the creation of a new IANA subregistry in DNS
+      Parameters?  If so, please indicate which registry is to be used
+      or created.  If a new subregistry is needed, specify the
+      allocation policy for it and its initial contents.  Also include
+      what the modification procedures will be.
+
+   I. Does the proposal require/expect any changes in DNS
+      servers/resolvers that prevent the new type from being processed
+      as an unknown RRTYPE (see [RFC3597])?
+
+   J. Comments:
+
+
+
+Eastlake                  Best Current Practice                [Page 15]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+Appendix B.  Changes from RFC 6195
+
+   Dropped description of changes from RFC 5395 to [RFC6195], since
+   those changes have already happened and we don't need to do them
+   again.  Added description of changes from [RFC6195] to this document.
+
+   Cut back RRTYPE Expert Review period to two weeks and eliminated the
+   mandatory dnsext@ietf.org comment period.  Changed workflow
+   description for RRTYPE review and allocation to correspond more
+   closely to actual practice.
+
+   Closed the AFSDB subtype registry and added an informative reference
+   to [RFC5864] where the use of the AFSDB RR to locate AFS cell
+   database servers is deprecated.
+
+   Clarified IANA archiving of referenced documentation as well as
+   approved RRTYPE application template.
+
+   In the RRTYPE application template, changed the label of question "B"
+   to "B.1" and added "B.2" to ask about the kind of RR.
+
+   Added text and an exclusory regular expression to Sections 3.1 and
+   3.2 to prohibit the use of a slight generalization of the generic
+   CLASS and RRTYPE names specified in [RFC3597] as the mnemonics for
+   new CLASSes and RRTYPEs.
+
+   Parenthetically listed "ANY" as well as "ALL" as a meaning for the
+   "*" RRTYPE.
+
+   Clarified that there is one DNS error number space for headers, OPT
+   extended headers, TSIG RRs, and TKEY RRs.  Noted that this is
+   considered to update [RFC2845] and [RFC2930].  Noted the overloading
+   of error number 9 as well as 16.
+
+   Updated references for revised versions.
+
+   Incorporated a number of editorial changes and typo fixes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                  Best Current Practice                [Page 16]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+Normative References
+
+   [RFC1034]   Mockapetris, P., "Domain names - concepts and
+               facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC1035]   Mockapetris, P., "Domain names - implementation and
+               specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1996]   Vixie, P., "A Mechanism for Prompt Notification of Zone
+               Changes (DNS NOTIFY)", RFC 1996, August 1996.
+
+   [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
+               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+               RFC 2136, April 1997.
+
+   [RFC2181]   Elz, R. and R. Bush, "Clarifications to the DNS
+               Specification", RFC 2181, July 1997.
+
+   [RFC2845]   Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+               Wellington, "Secret Key Transaction Authentication for
+               DNS (TSIG)", RFC 2845, May 2000.
+
+   [RFC2930]   Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
+               RR)", RFC 2930, September 2000.
+
+   [RFC3425]   Lawrence, D., "Obsoleting IQUERY", RFC 3425,
+               November 2002.
+
+   [RFC3597]   Gustafsson, A., "Handling of Unknown DNS Resource Record
+               (RR) Types", RFC 3597, September 2003.
+
+   [RFC4020]   Kompella, K. and A. Zinin, "Early IANA Allocation of
+               Standards Track Code Points", BCP 100, RFC 4020,
+               February 2005.
+
+   [RFC4033]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
+               Rose, "DNS Security Introduction and Requirements",
+               RFC 4033, March 2005.
+
+   [RFC4034]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
+               Rose, "Resource Records for the DNS Security Extensions",
+               RFC 4034, March 2005.
+
+   [RFC4035]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
+               Rose, "Protocol Modifications for the DNS Security
+               Extensions", RFC 4035, March 2005.
+
+
+
+
+
+Eastlake                  Best Current Practice                [Page 17]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+   [RFC4635]   Eastlake 3rd, D., "HMAC SHA (Hashed Message
+               Authentication Code, Secure Hash Algorithm) TSIG
+               Algorithm Identifiers", RFC 4635, August 2006.
+
+   [RFC5226]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
+               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+               May 2008.
+
+   [RFC6840]   Weiler, S., Ed., and D. Blacka, Ed., "Clarifications and
+               Implementation Notes for DNS Security (DNSSEC)",
+               RFC 6840, February 2013.
+
+   [RFC6891]   Damas, J., Graff, M., and Vixie, P., "Extension
+               Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, April
+               2013.
+
+   [US-ASCII]  American National Standards Institute (formerly United
+               States of America Standards Institute), "USA Code for
+               Information Interchange", ANSI X3.4-1968, 1968.
+
+               ANSI X3.4-1968 has been replaced by newer versions with
+               slight modifications, but the 1968 version remains
+               definitive for the Internet.
+
+Informative References
+
+   [Dyer1987]  Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
+               Plan - Name Service, April 1987.
+
+   [Moon1981]  Moon, D., "Chaosnet", A.I. Memo 628, Massachusetts
+               Institute of Technology Artificial Intelligence
+               Laboratory, June 1981.
+
+   [RFC1183]   Everhart, C., Mamakos, L., Ullmann, R., and P.
+               Mockapetris, "New DNS RR Definitions", RFC 1183,
+               October 1990.
+
+   [RFC1591]   Postel, J., "Domain Name System Structure and
+               Delegation", RFC 1591, March 1994.
+
+   [RFC2606]   Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
+               Names", BCP 32, RFC 2606, June 1999.
+
+   [RFC2673]   Crawford, M., "Binary Labels in the Domain Name System",
+               RFC 2673, August 1999.
+
+   [RFC2931]   Eastlake 3rd, D., "DNS Request and Transaction Signatures
+               ( SIG(0)s )", RFC 2931, September 2000.
+
+
+
+Eastlake                  Best Current Practice                [Page 18]
+
+RFC 6895                 DNS IANA Considerations              April 2013
+
+
+   [RFC4343]   Eastlake 3rd, D., "Domain Name System (DNS) Case
+               Insensitivity Clarification", RFC 4343, January 2006.
+
+   [RFC5864]   Allbery, R., "DNS SRV Resource Records for AFS",
+               RFC 5864, April 2010.
+
+   [RFC6195]   Eastlake 3rd, D., "Domain Name System (DNS) IANA
+               Considerations", RFC 6195, March 2011.
+
+Acknowledgements
+
+   Alfred Hoenes' contributions are gratefully acknowledged as are those
+   by Mark Andrews, Dick Franks, and Michael Sheldon.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   Huawei Technologies
+   155 Beaver Street
+   Milford, MA  01757
+   USA
+
+   Phone: +1-508-333-2270
+   EMail: d3e3e3@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                  Best Current Practice                [Page 19]
+