summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6195.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6195.txt')
-rw-r--r--doc/rfc/rfc6195.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc6195.txt b/doc/rfc/rfc6195.txt
new file mode 100644
index 0000000..53128cc
--- /dev/null
+++ b/doc/rfc/rfc6195.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. Eastlake 3rd
+Request for Comments: 6195 Huawei
+BCP: 42 March 2011
+Obsoletes: 5395
+Updates: 1183, 3597
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+ Domain Name System (DNS) IANA Considerations
+
+Abstract
+
+ This document specifies Internet Assigned Number 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.
+
+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/rfc6195.
+
+Copyright Notice
+
+ Copyright (c) 2011 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 3rd Best Current Practice [Page 1]
+
+RFC 6195 DNS IANA Considerations March 2011
+
+
+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 ........................9
+ 3.1.3. Special Note on the OPT RR ..........................9
+ 3.1.4. The AFSDB RR Subtype Field .........................10
+ 3.2. RR CLASS IANA Considerations ..............................10
+ 3.3. Label Considerations ......................................12
+ 3.3.1. Label Types ........................................12
+ 3.3.2. Label Contents and Use .............................12
+ 4. Security Considerations ........................................13
+ 5. IANA Considerations ............................................13
+ Appendix A. RRTYPE Allocation Template ............................14
+ Appendix B. Changes from RFC 5395 .................................15
+ Normative References ..............................................15
+ Informative References ............................................16
+
+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 [RFC5395]; however, the only
+ significant change is the change to the public review mailing list to
+ dnsext@ietf.org.
+
+ IANA currently maintains a web page of DNS parameters available from
+ http://www.iana.org.
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 2]
+
+RFC 6195 DNS IANA Considerations March 2011
+
+
+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] and [RFC5395]:
+
+ 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,
+ some DNS implementations copy the query header as the initial value
+ 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, given existing
+ implementation. Such meanings 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
+ structure and data type for Update but are instead the counts for the
+ zone (ZOCOUNT), prerequisite (PRCOUNT), update (UPCOUNT), and
+ additional information (ARCOUNT) sections.
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 3]
+
+RFC 6195 DNS IANA Considerations March 2011
+
+
+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 available for assignment
+ 4 Notify [RFC1996]
+ 5 Update [RFC2136]
+ 6-15 available for assignment
+
+ New OpCode assignments require a Standards Action as modified by
+ [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
+ OPT RRs [RFC2671], TSIG RRs [RFC2845], and TKEY RRs [RFC2930].
+ The OPT RR provides an 8-bit extension resulting in a 12-bit RCODE
+ field, and the TSIG and TKEY RRs have a 16-bit RCODE field.
+
+ Error codes appearing in the DNS header and in these three RR
+ types all refer to the same error code space with the single
+ exception of error code 16, which has a different meaning in the
+ OPT RR than in other contexts. This duplicate assignment was
+ accidental. See table below.
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 4]
+
+RFC 6195 DNS IANA Considerations March 2011
+
+
+ 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]
+ 10 NotZone Name not contained in zone [RFC2136]
+ 11 - 15 Available for assignment
+ 16 BADVERS Bad OPT Version [RFC2671]
+ 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 BADTRUC Bad Truncation [RFC4635]
+ 23 - 3,840
+ 0x0017 - 0x0F00 Available for assignment
+
+ 3,841 - 4,095
+ 0x0F01 - 0x0FFF Private Use
+
+ 4,096 - 65,534
+ 0x1000 - 0xFFFE Available for assignment
+
+ 65,535
+ 0xFFFF Reserved, can only be allocated by a
+ Standards Action.
+
+ Since it is important that RCODEs be understood for
+ interoperability, assignment of a new RCODE in the ranges listed
+ above as "Available for assignment" requires an IETF Review.
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 5]
+
+RFC 6195 DNS IANA Considerations March 2011
+
+
+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] [RFC2671].
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 6]
+
+RFC 6195 DNS IANA Considerations March 2011
+
+
+ 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 [RFC2671], TSIG
+ [RFC2845], and TKEY [RFC2930]. There are currently five QTYPEs
+ assigned: * (ALL), MAILA, MAILB, AXFR, and IXFR.
+
+ RRTYPEs have mnemonics that must be completely disjoint from the
+ mnemonics used for CLASSes and that must match the following regular
+ expression:
+
+ [A-Z][A-Z0-9\-]*[A-Z0-9]
+
+ Considerations for the allocation of new RRTYPEs are as follows:
+
+ Decimal
+ Hexadecimal
+
+ 0
+ 0x0000 - RRTYPE zero is used as a special indicator for the SIG (0)
+ RR [RFC2931] [RFC4034] and in other circumstances, and it
+ 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.
+
+
+
+Eastlake 3rd Best Current Practice [Page 7]
+
+RFC 6195 DNS IANA Considerations March 2011
+
+
+ 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 - Private Use.
+
+ 65,535
+ 0xFFFF - Reserved, can only be assigned by a 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 ruled on 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. RRTYPEs
+ that do not meet the requirements below may nonetheless be allocated
+ by a Standards Action as modified by [RFC4020].
+
+ 1. A complete template as specified in Appendix A has been posted
+ for three weeks to the dnsext@ietf.org mailing list before the
+ Expert Review decision.
+
+ Note that partially completed or draft templates may be posted
+ directly by the applicant for comment and discussion, but the
+ formal posting to start the three-week period is made by the
+ Expert.
+
+ 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.
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 8]
+
+RFC 6195 DNS IANA Considerations March 2011
+
+
+ After the applicant posts their formal application with their
+ template as specified in Appendix A, IANA appoints an Expert and the
+ template is posted, with an indication that it is a formal
+ application, to the dnsext@ietf.org mailing list. No less than three
+ weeks and no more than six weeks after this posting to
+ dnsext@ietf.org, the selected Expert shall post a message, explicitly
+ accepting or rejecting the application, to IANA, dnsext@ietf.org, and
+ the email address provided by the applicant. If the Expert does not
+ post such a message, the application shall be considered rejected but
+ may be resubmitted to IANA. IANA should report non-responsive
+ Experts to the IESG.
+
+ IANA shall maintain a public archive of approved templates.
+
+3.1.2. DNS RRTYPE Expert Guidelines
+
+ The selected DNS RRTYPE Expert is required to monitor discussion of
+ the proposed RRTYPE, which may occur on the dnsext@ietf.org mailing
+ list, and may consult with other technical experts as necessary. The
+ Expert should normally reject any RRTYPE allocation request that
+ meets one or more of the following criteria:
+
+ 1. Was documented in a manner that was not sufficiently clear to
+ evaluate or implement.
+
+ 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. The documentation of the proposed RRTYPE or RRTYPEs is
+ incomplete. (Additional documentation can be provided during the
+ public comment period or by the Expert.)
+
+ 4. Application use as documented makes incorrect assumptions about
+ DNS protocol behavior, such as wild cards, CNAME, DNAME, etc.
+
+ 5. An excessive number of RRTYPE values is being requested when the
+ purpose could be met with a smaller number 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 [RFC2671]. 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.
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 9]
+
+RFC 6195 DNS IANA Considerations March 2011
+
+
+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 follows:
+
+ Decimal
+ Hexadecimal
+
+ 0
+ 0x0000 - Reserved; allocation requires a Standards Action.
+
+ 1
+ 0x0001 - Andrews File Service v3.0 Location Service [RFC1183].
+
+ 2
+ 0x0002 - DCE/NCA root cell directory node [RFC1183].
+
+ 3 - 65,279
+ 0x0003 - 0xFEFF - Allocation by IETF Review.
+
+ 65,280 - 65,534
+ 0xFF00 - 0xFFFE - Private Use.
+
+ 65,535
+ 0xFFFF - Reserved; allocation requires a Standards Action.
+
+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 name space 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".
+
+
+
+Eastlake 3rd Best Current Practice [Page 10]
+
+RFC 6195 DNS IANA Considerations March 2011
+
+
+ CLASSes have mnemonics that must be completely disjoint from the
+ mnemonics used for RRTYPEs and that must match the following regular
+ expression:
+
+ [A-Z][A-Z0-9\-]*[A-Z0-9]
+
+ The current CLASS assignments and considerations for future
+ assignments are as follows:
+
+ Decimal
+ Hexadecimal
+
+ 0
+ 0x0000 - Reserved; assignment requires a Standards Action.
+
+ 1
+ 0x0001 - Internet (IN).
+
+ 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 - Assigned by IETF Review.
+
+ 32,768 - 57,343
+ 0x8000 - 0xDFFF - Assigned for data CLASSes only, based on
+ Specification Required as defined in [RFC5226].
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 11]
+
+RFC 6195 DNS IANA Considerations March 2011
+
+
+ 57,344 - 65,279
+ 0xE000 - 0xFEFF - Assigned for QCLASSes and meta-CLASSes only, based
+ on Specification Required as defined in [RFC5226].
+
+ 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
+ [US-ASCII]. For retrieval, Text labels are defined to treat ASCII
+ upper and lower case letter codes as matching [RFC4343]. Binary
+ labels are bit sequences [RFC2673]. The Binary label type is
+ Experimental [RFC3363].
+
+ IANA considerations for label types are given in [RFC2671].
+
+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 3rd Best Current Practice [Page 12]
+
+RFC 6195 DNS IANA Considerations March 2011
+
+
+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 archives and makes available all approved RRTYPE
+ allocation templates. 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 3rd Best Current Practice [Page 13]
+
+RFC 6195 DNS IANA Considerations March 2011
+
+
+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. Submission Type:
+ [ ] New RRTYPE
+ [ ] Modification to existing RRTYPE
+
+ 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: this can be left blank and the mnemonic decided after the
+ template is accepted.
+
+ H. Does the requested RRTYPE make use of any existing IANA registry
+ or require the creation of a new IANA sub-registry in DNS
+ Parameters? If so, please indicate which registry is to be used
+ or created. If a new sub-registry 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 3rd Best Current Practice [Page 14]
+
+RFC 6195 DNS IANA Considerations March 2011
+
+
+Appendix B. Changes From RFC 5395
+
+ Replaced "namedroppers@ops.ietf.org" with "dnsext@ietf.org".
+
+ Dropped description of changes from RFC 2929 to RFC 5395 since those
+ changes have already happened, and we don't need to do them again.
+
+ Updated the boilerplate text.
+
+ Fixed Section 5 to say that it is the duty of the applicant, not the
+ expert, to post the application to dns-rrtype-applications@ietf.org.
+
+ Changed the regular expression for RRTYPE and CLASS names so as to
+ prohibit trailing hyphen ("-") and require a minimum length of 2
+ characters.
+
+ Made a number of minor editorial and typos fixes.
+
+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.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+ 2671, August 1999.
+
+ [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.
+
+
+
+Eastlake 3rd Best Current Practice [Page 15]
+
+RFC 6195 DNS IANA Considerations March 2011
+
+
+ [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.
+
+ [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.
+
+ [US-ASCII] ANSI, "USA Standard Code for Information Interchange",
+ X3.4, American National Standards Institute: New York,
+ 1968.
+
+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.
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 16]
+
+RFC 6195 DNS IANA Considerations March 2011
+
+
+ [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.
+
+ [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+ Hain, "Representing Internet Protocol version 6 (IPv6)
+ Addresses in the Domain Name System (DNS)", RFC 3363,
+ August 2002.
+
+ [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case
+ Insensitivity Clarification", RFC 4343, January 2006.
+
+ [RFC5395] Eastlake 3rd, D., "Domain Name System (DNS) IANA
+ Considerations", BCP 42, RFC 5395, November 2008.
+
+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 3rd Best Current Practice [Page 17]
+