summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5395.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5395.txt')
-rw-r--r--doc/rfc/rfc5395.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc5395.txt b/doc/rfc/rfc5395.txt
new file mode 100644
index 0000000..6898634
--- /dev/null
+++ b/doc/rfc/rfc5395.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group D. Eastlake 3rd
+Request for Comments: 5395 Stellar Switches
+BCP: 42 November 2008
+Obsoletes: 2929
+Updates: 1183, 3597
+Category: Best Current Practice
+
+
+ Domain Name System (DNS) IANA Considerations
+
+Status of This Memo
+
+ This document specifies an Internet Best Current Practices for the
+ Internet Community, and requests discussion and suggestions for
+ improvements. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (c) 2008 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.
+
+Abstract
+
+ Internet Assigned Number Authority (IANA) parameter assignment
+ considerations are specified 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake Best Current Practice [Page 1]
+
+RFC 5395 DNS IANA Considerations November 2008
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Terminology ................................................2
+ 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
+ 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. See [RFC1034], [RFC1035], [RFC2136],
+ [RFC2181], and [RFC4033], familiarity with which 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 [RFC2929].
+
+ IANA currently maintains a web page of DNS parameters available from
+ http://www.iana.org.
+
+1.1. Terminology
+
+ "IETF Standards Action", "IETF Review", "Specification Required", and
+ "Private Use" are as defined in [RFC5226].
+
+
+
+Eastlake Best Current Practice [Page 2]
+
+RFC 5395 DNS IANA Considerations November 2008
+
+
+2. DNS Query/Response Headers
+
+ The header for DNS queries and responses contains field/bits in the
+ following diagram taken from [RFC2136] and [RFC2929]:
+
+ 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 an IETF
+ 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 Best Current Practice [Page 3]
+
+RFC 5395 DNS IANA Considerations November 2008
+
+
+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 an IETF 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 an IETF 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake Best Current Practice [Page 4]
+
+RFC 5395 DNS IANA Considerations November 2008
+
+
+ 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 from its
+ meaning in other contexts. 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]
+ 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 an IETF
+ Standards Action.
+
+ Since it is important that RCODEs be understood for interoperability,
+ assignment of new RCODE listed above as "available for assignment"
+ requires an IETF Review.
+
+
+
+
+
+
+
+Eastlake Best Current Practice [Page 5]
+
+RFC 5395 DNS IANA Considerations November 2008
+
+
+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 Best Current Practice [Page 6]
+
+RFC 5395 DNS IANA Considerations November 2008
+
+
+ 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-]*
+
+ 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] 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 Best Current Practice [Page 7]
+
+RFC 5395 DNS IANA Considerations November 2008
+
+
+ 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 an IETF 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 IETF Standards Action as modified by [RFC4020].
+
+ 1. A complete template as specified in Appendix A has been posted for
+ three weeks to the namedroppers@ops.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 Best Current Practice [Page 8]
+
+RFC 5395 DNS IANA Considerations November 2008
+
+
+ No less than three weeks and no more than six weeks after a completed
+ template has been formally posted to namedroppers@ops.ietf.org, the
+ selected Expert shall post a message, explicitly accepting or
+ rejecting the application, to IANA, namedroppers@ops.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 re-submitted to IANA.
+
+ 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 namedroppers@ops.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 criterion:
+
+ 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 Best Current Practice [Page 9]
+
+RFC 5395 DNS IANA Considerations November 2008
+
+
+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, 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 IETF 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 IETF 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 be 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 Best Current Practice [Page 10]
+
+RFC 5395 DNS IANA Considerations November 2008
+
+
+ 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-]*
+
+ The current CLASS assignments and considerations for future
+ assignments are as follows:
+
+ Decimal
+ Hexadecimal
+
+ 0
+ 0x0000 - Reserved; assignment requires an IETF 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 Best Current Practice [Page 11]
+
+RFC 5395 DNS IANA Considerations November 2008
+
+
+ 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 an IETF 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 Best Current Practice [Page 12]
+
+RFC 5395 DNS IANA Considerations November 2008
+
+
+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 and
+ includes the following changes from its predecessor [RFC2929]. It
+ affects the DNS Parameters registry and its subregistries, which are
+ available from http://www.iana.org.
+
+ 1. In the Domain Name System "Resource record (RR) TYPES and QTYPEs"
+ registry, it changes most "IETF Consensus" and all "Specification
+ Required" allocation policies for RRTYPEs to be "DNS TYPE
+ Allocation Policy" and changes the policy for RRTYPE 0xFFFF to be
+ "IETF Standards Action". Remaining instances of "IETF Consensus"
+ are changed to "IETF Review", per [RFC5226]. It also specifies
+ the "DNS TYPE Allocation Policy", which is based on Expert Review
+ with additional provisions and restrictions, including the
+ submittal of a completed copy of the template in Appendix A to
+ dns-rrtype-applications@ietf.org, in most cases, and requires
+ "IETF Standards Action" as modified by [RFC4020] in other cases.
+
+ IANA shall establish a process for accepting such templates,
+ selecting an Expert from those appointed to review such template
+ form applications, archiving, and making available all approved
+ RRTYPE allocation templates. It is the duty of the selected
+ Expert to post the formal application template to the
+ namedroppers@ops.ietf.org mailing list. See Section 3.1 and
+ Appendix A for more details.
+
+ 2. For OpCodes (see Section 2.2), it changes "IETF Standards Action"
+ allocation requirements to add "as modified by [RFC4020]".
+
+ 3. It changes the allocation status of RCODE 0xFFFF to be "IETF
+ Standards Action required". See Section 2.3.
+
+ 4. It adds an IANA allocation policy for the AFSDB RR Subtype field,
+ which requires the creation of a new registry. See Section 3.1.4.
+
+ 5. It splits Specification Required CLASSes into data CLASSes and
+ query or meta CLASSes. See Section 3.2.
+
+
+
+
+
+
+
+Eastlake Best Current Practice [Page 13]
+
+RFC 5395 DNS IANA Considerations November 2008
+
+
+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:
+ Name:
+ Email Address:
+ International telephone number:
+ Other contact handles:
+
+ (Note: This information will be publicly posted.)
+
+ 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. Remember 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.
+
+
+
+
+
+Eastlake Best Current Practice [Page 14]
+
+RFC 5395 DNS IANA Considerations November 2008
+
+
+ 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:
+
+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.
+
+ [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.
+
+
+
+
+Eastlake Best Current Practice [Page 15]
+
+RFC 5395 DNS IANA Considerations November 2008
+
+
+ [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.
+
+ [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.
+
+ [RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
+ "Domain Name System (DNS) IANA Considerations", BCP 42,
+ RFC 2929, September 2000.
+
+ [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
+ ( SIG(0)s )", RFC 2931, September 2000.
+
+
+
+Eastlake Best Current Practice [Page 16]
+
+RFC 5395 DNS IANA Considerations November 2008
+
+
+ [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.
+
+Author's Address
+
+ Donald E. Eastlake 3rd
+ Stellar Switches
+ 155 Beaver Street
+ Milford, MA 01757 USA
+
+ Phone: +1-508-634-2066 (h)
+ EMail: d3e3e3@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake Best Current Practice [Page 17]
+