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]