Skip to main content

Domain Name System (DNS) IANA Considerations
RFC 6895 also known as BCP 42

Document Type RFC - Best Current Practice (April 2013)
Obsoletes RFC 6195
Author Donald E. Eastlake 3rd
Last updated 2015-10-14
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
IESG Responsible AD Ralph Droms
Send notices to (None)
RFC 6895
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]