draft-ietf-dnsext-rfc6195bis-02.txt | draft-ietf-dnsext-rfc6195bis-03.txt | |||
---|---|---|---|---|
INTERNET-DRAFT Donald Eastlake | INTERNET-DRAFT Donald Eastlake | |||
Obsoletes: 6195 Huawei | Obsoletes: 6195 Huawei | |||
Updates: 1183, 3597 | Updates: 1183, 2845, 2930, 3597 | |||
Intended status: Best Current Practice | Intended status: Best Current Practice | |||
Expires: December 9, 2012 June 10, 2012 | Expires: January 1, 2013 July 2, 2012 | |||
Domain Name System (DNS) IANA Considerations | Domain Name System (DNS) IANA Considerations | |||
<draft-ietf-dnsext-rfc6195bis-02.txt> | <draft-ietf-dnsext-rfc6195bis-03.txt> | |||
Abstract | Abstract | |||
This document specifies Internet Assigned Number Authority (IANA) | This document specifies Internet Assigned Number Authority (IANA) | |||
parameter assignment considerations for the allocation of Domain Name | parameter assignment considerations for the allocation of Domain Name | |||
System (DNS) resource record types, CLASSes, operation codes, error | System (DNS) resource record types, CLASSes, operation codes, error | |||
codes, DNS protocol message header bits, and AFSDB resource record | codes, DNS protocol message header bits, and AFSDB resource record | |||
subtypes. It obsoletes RFC 6195 and updates RFCs 1183 and 3597. | subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, | |||
and 3597. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Distribution of this draft is unlimited. It is intended to become the | Distribution of this draft is unlimited. It is intended to become the | |||
new BCP 42 obsoleting RFC 6195. Comments should be sent to the DNS | new BCP 42 obsoleting RFC 6195. Comments should be sent to the DNS | |||
Extensions Working Group mailing list <dnsext@ietf.org>. | Extensions Working Group mailing list <dnsext@ietf.org>. | |||
skipping to change at page 2, line 14 | skipping to change at page 2, line 14 | |||
INTERNET-DRAFT DNS IANA Considerations | INTERNET-DRAFT DNS IANA Considerations | |||
Table of Contents | Table of Contents | |||
1. Introduction............................................3 | 1. Introduction............................................3 | |||
1.1 Terminology............................................3 | 1.1 Terminology............................................3 | |||
1.2 Acknowledgement........................................3 | 1.2 Acknowledgement........................................3 | |||
2. DNS Query/Response Headers..............................4 | 2. DNS Query/Response Headers..............................4 | |||
2.1 One Spare Bit?.........................................4 | 2.1 One Spare Bit?.........................................5 | |||
2.2 OpCode Assignment......................................5 | 2.2 OpCode Assignment......................................5 | |||
2.3 RCODE Assignment.......................................5 | 2.3 RCODE Assignment.......................................5 | |||
3. DNS Resource Records....................................7 | 3. DNS Resource Records....................................8 | |||
3.1 RRTYPE IANA Considerations.............................8 | 3.1 RRTYPE IANA Considerations.............................9 | |||
3.1.1 DNS RRTYPE Allocation Policy.........................9 | 3.1.1 DNS RRTYPE Allocation Policy........................10 | |||
3.1.2 DNS RRTYPE Expert Guidelines........................10 | 3.1.2 DNS RRTYPE Expert Guidelines........................11 | |||
3.1.3 Special Note on the OPT RR..........................10 | 3.1.3 Special Note on the OPT RR..........................11 | |||
3.1.4 The AFSDB RR Subtype Field..........................11 | 3.1.4 The AFSDB RR Subtype Field..........................12 | |||
3.2 RR CLASS IANA Considerations..........................11 | 3.2 RR CLASS IANA Considerations..........................12 | |||
3.3. Label Considerations.................................13 | 3.3. Label Considerations.................................14 | |||
3.3.1 Label Types.........................................13 | 3.3.1 Label Types.........................................14 | |||
3.3.2 Label Contents and Use..............................13 | 3.3.2 Label Contents and Use..............................14 | |||
4. Security Considerations................................15 | 4. Security Considerations................................16 | |||
5. IANA Considerations....................................15 | 5. IANA Considerations....................................16 | |||
Appendix A: RRTYPE Allocation Template....................16 | Appendix A: RRTYPE Allocation Template....................17 | |||
Appendix B: Changes From RFC 6195.........................17 | Appendix B: Changes From RFC 6195.........................18 | |||
Normative References......................................18 | Normative References......................................19 | |||
Informative References....................................19 | Informative References....................................20 | |||
INTERNET-DRAFT DNS IANA Considerations | INTERNET-DRAFT DNS IANA Considerations | |||
1. Introduction | 1. Introduction | |||
The Domain Name System (DNS) provides replicated distributed secure | The Domain Name System (DNS) provides replicated distributed secure | |||
hierarchical databases that store "resource records" (RRs) under | hierarchical databases that store "resource records" (RRs) under | |||
domain names. DNS data is structured into CLASSes and zones that can | domain names. DNS data is structured into CLASSes and zones that can | |||
be independently maintained. Familiarity with [RFC1034], [RFC1035], | be independently maintained. Familiarity with [RFC1034], [RFC1035], | |||
[RFC2136], [RFC2181], and [RFC4033] is assumed. | [RFC2136], [RFC2181], and [RFC4033] is assumed. | |||
skipping to change at page 3, line 33 | skipping to change at page 3, line 33 | |||
significant changes are those to the RRTYPE IANA allocation process, | significant changes are those to the RRTYPE IANA allocation process, | |||
aimed at streamlining it and clarifying the expected behavior of the | aimed at streamlining it and clarifying the expected behavior of the | |||
parties involved, and the closing of the AFSDB sub-type registry. | parties involved, and the closing of the AFSDB sub-type registry. | |||
IANA currently maintains a web page of DNS parameters available from | IANA currently maintains a web page of DNS parameters available from | |||
http://www.iana.org. | http://www.iana.org. | |||
1.1 Terminology | 1.1 Terminology | |||
"Standards Action", "IETF Review", "Specification Required", and | "Standards Action", "IETF Review", "Specification Required", and | |||
"Private Use" are as defined in [RFC5226]. | "Private Use" are as defined in [RFC5226]. The key words "MUST", | |||
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", | ||||
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be | ||||
interpreted as described in [RFC2119]. | ||||
1.2 Acknowledgement | 1.2 Acknowledgement | |||
Alfred Hoenes contributions are gratefully acknowledged. | Alfred Hoenes contributions are gratefully acknowledged as are those | |||
by Mark Andrews, Dick Franks, and Michael Sheldon. | ||||
INTERNET-DRAFT DNS IANA Considerations | INTERNET-DRAFT DNS IANA Considerations | |||
2. DNS Query/Response Headers | 2. DNS Query/Response Headers | |||
The header for DNS queries and responses contains field/bits in the | The header for DNS queries and responses contains field/bits in the | |||
following diagram taken from [RFC2136] and [RFC6195]: | following diagram taken from [RFC2136] and [RFC6195]: | |||
1 1 1 1 1 1 | 1 1 1 1 1 1 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | |||
skipping to change at page 4, line 33 | skipping to change at page 4, line 33 | |||
| NSCOUNT/UPCOUNT | | | NSCOUNT/UPCOUNT | | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
| ARCOUNT | | | ARCOUNT | | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
The ID field identifies the query and is echoed in the response so | The ID field identifies the query and is echoed in the response so | |||
they can be matched. | they can be matched. | |||
The QR bit indicates whether the header is for a query or a response. | 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 | The AA, TC, RD, RA, and CD bits are each theoretically meaningful | |||
only in queries or only in responses, depending on the bit. However, | only in queries or only in responses, depending on the bit. The AD | |||
some DNS implementations copy the query header as the initial value | bit was only meaningful in responses but is expected to have a | |||
of the response header without clearing bits. Thus, any attempt to | separate but related meaning in queries (see Section 5.7 of | |||
use a "query" bit with a different meaning in a response or to define | [RFCdnssecbisup]). Only the RD and CD bits are expected to be copied | |||
a query meaning for a "response" bit is dangerous, given existing | from the query to the response; however, some DNS implementations | |||
implementation. Such meanings may only be assigned by a Standards | copy all the query header as the initial value of the response | |||
Action. | 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 existing implementation. Meanings for | ||||
these bits may only be assigned by a Standards Action. | ||||
The unsigned integer fields query count (QDCOUNT), answer count | The unsigned integer fields query count (QDCOUNT), answer count | |||
(ANCOUNT), authority count (NSCOUNT), and additional information | (ANCOUNT), authority count (NSCOUNT), and additional information | |||
count (ARCOUNT) express the number of records in each section for all | count (ARCOUNT) express the number of records in each section for all | |||
OpCodes except Update [RFC2136]. These fields have the same structure | OpCodes except Update [RFC2136]. These fields have the same structure | |||
and data type for Update but are instead the counts for the zone | and data type for Update but are instead the counts for the zone | |||
(ZOCOUNT), prerequisite (PRCOUNT), update (UPCOUNT), and additional | (ZOCOUNT), prerequisite (PRCOUNT), update (UPCOUNT), and additional | |||
information (ARCOUNT) sections. | information (ARCOUNT) sections. | |||
INTERNET-DRAFT DNS IANA Considerations | ||||
2.1 One Spare Bit? | 2.1 One Spare Bit? | |||
There have been ancient DNS implementations for which the Z bit being | 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 | 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 | a zone is acceptable. It is believed that current DNS implementations | |||
INTERNET-DRAFT DNS IANA Considerations | ||||
ignore this bit. | ignore this bit. | |||
Assigning a meaning to the Z bit requires a Standards Action. | Assigning a meaning to the Z bit requires a Standards Action. | |||
2.2 OpCode Assignment | 2.2 OpCode Assignment | |||
Currently, DNS OpCodes are assigned as follows: | Currently, DNS OpCodes are assigned as follows: | |||
OpCode Name Reference | OpCode Name Reference | |||
0 Query [RFC1035] | 0 Query [RFC1035] | |||
1 IQuery (Inverse Query, Obsolete) [RFC3425] | 1 IQuery (Inverse Query, Obsolete) [RFC3425] | |||
2 Status [RFC1035] | 2 Status [RFC1035] | |||
3 available for assignment | 3 available for assignment | |||
4 Notify [RFC1996] | 4 Notify [RFC1996] | |||
5 Update [RFC2136] | 5 Update [RFC2136] | |||
6-15 available for assignment | 6-15 available for assignment | |||
New OpCode assignments require a Standards Action as modified by | Although the Status OpCode is reserved in [RFC1035], its behavior has | |||
[RFC4020]. | not been specified. New OpCode assignments require a Standards Action | |||
as modified by [RFC4020]. | ||||
2.3 RCODE Assignment | 2.3 RCODE Assignment | |||
It would appear from the DNS header above that only four bits of | It would appear from the DNS header above that only four bits of | |||
RCODE, or response/error code, are available. However, RCODEs can | RCODE, or response/error code, are available. However, RCODEs can | |||
appear not only at the top level of a DNS response but also inside | appear not only at the top level of a DNS response but also inside | |||
OPT RRs [RFC2671bis], TSIG RRs [RFC2845], and TKEY RRs [RFC2930]. The | TSIG RRs [RFC2845], TKEY RRs [RFC2930], and extended by OPT RRs | |||
OPT RR provides an 8-bit extension resulting in a 12-bit RCODE field, | [RFC2671bis]. The OPT RR provides an 8-bit extension to the 4 header | |||
and the TSIG and TKEY RRs have a 16-bit RCODE field. | 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 three RR types | Error codes appearing in the DNS header and in these other RR types | |||
all refer to the same error code space with the single exception of | all refer to the same error code space with the exception of error | |||
error code 16, which has a different meaning in the OPT RR than in | code 16, which has a different meaning in the OPT RR than in the TSIG | |||
other contexts. This duplicate assignment was accidental. See table | RR, and error code 9 whose variations are described after the table | |||
below. | 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 | ||||
DNS error number space. (This paragraph is the reason this document | ||||
updates [RFC2845] and [RFC2930].) With the existing exceptions of | ||||
INTERNET-DRAFT DNS IANA Considerations | INTERNET-DRAFT DNS IANA Considerations | |||
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 | RCODE Name Description Reference | |||
Decimal | Decimal | |||
Hexadecimal | Hexadecimal | |||
0 NoError No Error [RFC1035] | 0 NoError No Error [RFC1035] | |||
1 FormErr Format Error [RFC1035] | 1 FormErr Format Error [RFC1035] | |||
2 ServFail Server Failure [RFC1035] | 2 ServFail Server Failure [RFC1035] | |||
3 NXDomain Non-Existent Domain [RFC1035] | 3 NXDomain Non-Existent Domain [RFC1035] | |||
4 NotImp Not Implemented [RFC1035] | 4 NotImp Not Implemented [RFC1035] | |||
5 Refused Query Refused [RFC1035] | 5 Refused Query Refused [RFC1035] | |||
6 YXDomain Name Exists when it should not [RFC2136] | 6 YXDomain Name Exists when it should not [RFC2136] | |||
7 YXRRSet RR Set 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] | 8 NXRRSet RR Set that should exist does not [RFC2136] | |||
9 NotAuth Server Not Authoritative for zone [RFC2136] | 9 NotAuth See note below after table | |||
10 NotZone Name not contained in zone [RFC2136] | 10 NotZone Name not contained in zone [RFC2136] | |||
11 - 15 | 11 - 15 | |||
0xB - 0xF Available for assignment | 0xB - 0xF Available for assignment | |||
16 BADVERS Bad OPT Version [RFC2671bis] | 16 BADVERS Bad OPT Version [RFC2671bis] | |||
16 BADSIG TSIG Signature Failure [RFC2845] | 16 BADSIG TSIG Signature Failure [RFC2845] | |||
17 BADKEY Key not recognized [RFC2845] | 17 BADKEY Key not recognized [RFC2845] | |||
18 BADTIME Signature out of time window [RFC2845] | 18 BADTIME Signature out of time window [RFC2845] | |||
19 BADMODE Bad TKEY Mode [RFC2930] | 19 BADMODE Bad TKEY Mode [RFC2930] | |||
skipping to change at page 6, line 48 | skipping to change at page 6, line 52 | |||
3,841 - 4,095 | 3,841 - 4,095 | |||
0x0F01 - 0x0FFF Private Use | 0x0F01 - 0x0FFF Private Use | |||
4,096 - 65,534 | 4,096 - 65,534 | |||
0x1000 - 0xFFFE Available for assignment | 0x1000 - 0xFFFE Available for assignment | |||
65,535 | 65,535 | |||
0xFFFF Reserved, can only be allocated by a Standards | 0xFFFF Reserved, can only be allocated by a Standards | |||
Action. | Action. | |||
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 | ||||
INTERNET-DRAFT DNS IANA Considerations | ||||
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, | Since it is important that RCODEs be understood for interoperability, | |||
assignment of a new RCODE in the ranges listed above as "Available | assignment of a new RCODE in the ranges listed above as "Available | |||
for assignment" requires an IETF Review. | for assignment" requires an IETF Review. | |||
INTERNET-DRAFT DNS IANA Considerations | INTERNET-DRAFT DNS IANA Considerations | |||
3. DNS Resource Records | 3. DNS Resource Records | |||
All RRs have the same top-level format, shown in the figure below | All RRs have the same top-level format, shown in the figure below | |||
taken from [RFC1035]. | taken from [RFC1035]. | |||
skipping to change at page 8, line 24 | skipping to change at page 9, line 24 | |||
particular DNS message and, in some cases, can also be used in | particular DNS message and, in some cases, can also be used in | |||
queries. Thus far, data TYPEs have been assigned from 1 upward, plus | 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 | 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-TYPEs have been assigned from 255 downward except for the OPT | |||
Meta-RR, which is assigned TYPE 41. There have been DNS | Meta-RR, which is assigned TYPE 41. There have been DNS | |||
implementations that made caching decisions based on the top bit of | implementations that made caching decisions based on the top bit of | |||
the bottom byte of the RRTYPE. | the bottom byte of the RRTYPE. | |||
There are currently three Meta-TYPEs assigned: OPT [RFC2671bis], TSIG | There are currently three Meta-TYPEs assigned: OPT [RFC2671bis], TSIG | |||
[RFC2845], and TKEY [RFC2930]. There are currently five QTYPEs | [RFC2845], and TKEY [RFC2930]. There are currently five QTYPEs | |||
assigned: * (ALL), MAILA, MAILB, AXFR, and IXFR. | assigned: * (ALL/ANY), MAILA, MAILB, AXFR, and IXFR. | |||
Allocated RRTYPEs have mnemonics that must be completely disjoint | Allocated RRTYPEs have mnemonics that must be completely disjoint | |||
from the mnemonics used for CLASSes and that must match the regular | from the mnemonics used for CLASSes and that must match the regular | |||
expression below. In addition, the generic CLASS and RRTYPE names | expression below. In addition, the generic CLASS and RRTYPE names | |||
specified in Section 5 of [RFC3597] cannot be assigned as new RRTYPE | specified in Section 5 of [RFC3597] cannot be assigned as new RRTYPE | |||
mnemonics. | mnemonics. | |||
[A-Z][A-Z0-9\-]*[A-Z0-9] | [A-Z][A-Z0-9\-]*[A-Z0-9] | |||
but not | but not | |||
(TYPE|CLASS)(0|[1-9][0-9]*) | (TYPE|CLASS)[0-9]* | |||
Considerations for the allocation of new RRTYPEs are as follows: | Considerations for the allocation of new RRTYPEs are as follows: | |||
Decimal | Decimal | |||
Hexadecimal Assignment Policy | Hexadecimal Assignment Policy | |||
0 | 0 | |||
0x0000 RRTYPE zero is used as a special indicator for the | 0x0000 RRTYPE zero is used as a special indicator for the | |||
SIG (0) RR [RFC2931] [RFC4034] and in other | SIG (0) RR [RFC2931] [RFC4034] and in other | |||
circumstances, and it must never be allocated for | circumstances, and it must never be allocated for | |||
skipping to change at page 11, line 12 | skipping to change at page 12, line 12 | |||
and servers that recognize it, it extends the RCODE field from 4 to | and servers that recognize it, it extends the RCODE field from 4 to | |||
12 bits. | 12 bits. | |||
INTERNET-DRAFT DNS IANA Considerations | INTERNET-DRAFT DNS IANA Considerations | |||
3.1.4 The AFSDB RR Subtype Field | 3.1.4 The AFSDB RR Subtype Field | |||
The AFSDB RR [RFC1183] is a CLASS-insensitive RR that has the same | 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 | 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 | integer field at the beginning of the RDATA is interpreted as a | |||
subtype as shown below. This subtype registry is closed and | subtype as shown below. Use of the AFSDB RR to locate AFS cell | |||
allocation of new subtypes is no longer permitted. | database servers was deprecated by [RFC5864]. This subtype registry | |||
is hereby closed and allocation of new subtypes is no longer | ||||
permitted. | ||||
Decimal | Decimal | |||
Hexadecimal Assignment Policy | Hexadecimal Assignment Policy | |||
0 | 0 | |||
0x0000 Reserved, registry closed | 0x0000 Reserved, registry closed | |||
1 | 1 | |||
0x0001 AFS v3.0 Location Service [RFC1183] | 0x0001 AFS v3.0 Location Service [RFC1183] | |||
skipping to change at page 11, line 53 | skipping to change at page 13, line 4 | |||
the DNS distributed database. In particular, there is no necessary | the DNS distributed database. In particular, there is no necessary | |||
relationship between the name space or root servers for one data | relationship between the name space or root servers for one data | |||
CLASS and those for another data CLASS. The same DNS NAME can have | CLASS and those for another data CLASS. The same DNS NAME can have | |||
completely different meanings in different CLASSes. The label types | completely different meanings in different CLASSes. The label types | |||
are the same, and the null label is usable only as root in every | 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 | CLASS. As global networking and DNS have evolved, the IN, or | |||
Internet, CLASS has dominated DNS use. | Internet, CLASS has dominated DNS use. | |||
As yet, there has not been a requirement for "meta-CLASSes". That | As yet, there has not been a requirement for "meta-CLASSes". That | |||
would be a CLASS to designate transient data associated with a | 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 | ||||
INTERNET-DRAFT DNS IANA Considerations | INTERNET-DRAFT DNS IANA Considerations | |||
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". | "meta-CLASSes". | |||
Assigned CLASSes have mnemonics that must be completely disjoint from | Assigned CLASSes have mnemonics that must be completely disjoint from | |||
the mnemonics used for RRTYPEs and that must match the regular | the mnemonics used for RRTYPEs and that must match the regular | |||
expression below. In addition, the generic CLASS and RRTYPE names | expression below. In addition, the generic CLASS and RRTYPE names | |||
specified in Section 5 of [RFC3597] cannot be assigned as new CLASS | specified in Section 5 of [RFC3597] cannot be assigned as new CLASS | |||
mnemonics. | mnemonics. | |||
[A-Z][A-Z0-9\-]*[A-Z0-9] | [A-Z][A-Z0-9\-]*[A-Z0-9] | |||
but not | but not | |||
(CLASS|RRTYPE)(0|[1-9][0-9]*) | (CLASS|RRTYPE)[0-9]* | |||
The current CLASS assignments and considerations for future | The current CLASS assignments and considerations for future | |||
assignments are as follows: | assignments are as follows: | |||
Decimal | Decimal | |||
Hexadecimal Assignment / Policy, Reference | Hexadecimal Assignment / Policy, Reference | |||
0 | 0 | |||
0x0000 Reserved; assignment requires a Standards Action | 0x0000 Reserved; assignment requires a Standards Action | |||
skipping to change at page 12, line 55 | skipping to change at page 14, line 5 | |||
128 - 253 | 128 - 253 | |||
0x0080 - 0x00FD Available for assignment by IETF Review for | 0x0080 - 0x00FD Available for assignment by IETF Review for | |||
QCLASSes and meta-CLASSes only | QCLASSes and meta-CLASSes only | |||
254 | 254 | |||
0x00FE QCLASS NONE [RFC2136] | 0x00FE QCLASS NONE [RFC2136] | |||
255 | 255 | |||
0x00FF QCLASS * (ANY) [RFC1035] | 0x00FF QCLASS * (ANY) [RFC1035] | |||
INTERNET-DRAFT DNS IANA Considerations | ||||
256 - 32,767 | 256 - 32,767 | |||
0x0100 - 0x7FFF Available for assignment by IETF Review | 0x0100 - 0x7FFF Available for assignment by IETF Review | |||
INTERNET-DRAFT DNS IANA Considerations | ||||
32,768 - 57,343 | 32,768 - 57,343 | |||
0x8000 - 0xDFFF Available for assignment to data CLASSes only; | 0x8000 - 0xDFFF Available for assignment to data CLASSes only; | |||
Specification Required | Specification Required | |||
57,344 - 65,279 | 57,344 - 65,279 | |||
0xE000 - 0xFEFF Available for assignment to QCLASSes and meta- | 0xE000 - 0xFEFF Available for assignment to QCLASSes and meta- | |||
CLASSes only; Specification Required | CLASSes only; Specification Required | |||
65,280 - 65,534 | 65,280 - 65,534 | |||
0xFF00 - 0xFFFE Private Use | 0xFF00 - 0xFFFE Private Use | |||
skipping to change at page 13, line 48 | skipping to change at page 15, line 4 | |||
[RFC4343]. Binary labels are bit sequences [RFC2673]. The Binary | [RFC4343]. Binary labels are bit sequences [RFC2673]. The Binary | |||
label type is Historic [RFC2671bis]. | label type is Historic [RFC2671bis]. | |||
3.3.2 Label Contents and Use | 3.3.2 Label Contents and Use | |||
The last label in each NAME is "ROOT", which is the zero-length | 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 | label. By definition, the null or ROOT label cannot be used for any | |||
other NAME purpose. | other NAME purpose. | |||
NAMEs are local to a CLASS. The Hesiod [Dyer1987] and Chaos | NAMEs are local to a CLASS. The Hesiod [Dyer1987] and Chaos | |||
INTERNET-DRAFT DNS IANA Considerations | ||||
[Moon1981] CLASSes are for essentially local use. The IN, or | [Moon1981] CLASSes are for essentially local use. The IN, or | |||
Internet, CLASS is thus the only DNS CLASS in global use on the | Internet, CLASS is thus the only DNS CLASS in global use on the | |||
Internet at this time. | Internet at this time. | |||
INTERNET-DRAFT DNS IANA Considerations | ||||
A somewhat out-of-date description of name allocation in the IN Class | A somewhat out-of-date description of name allocation in the IN Class | |||
is given in [RFC1591]. Some information on reserved top-level domain | is given in [RFC1591]. Some information on reserved top-level domain | |||
names is in BCP 32 [RFC2606]. | names is in BCP 32 [RFC2606]. | |||
INTERNET-DRAFT DNS IANA Considerations | INTERNET-DRAFT DNS IANA Considerations | |||
4. Security Considerations | 4. Security Considerations | |||
This document addresses IANA considerations in the allocation of | This document addresses IANA considerations in the allocation of | |||
general DNS parameters, not security. See [RFC4033], [RFC4034], and | general DNS parameters, not security. See [RFC4033], [RFC4034], and | |||
skipping to change at page 17, line 18 | skipping to change at page 18, line 18 | |||
Drop description of changes from RFC 5395 to [RFC6195] since those | Drop description of changes from RFC 5395 to [RFC6195] since those | |||
changes have already happened and we don't need to do them again. Add | changes have already happened and we don't need to do them again. Add | |||
description of changes from [RFC6195] to this document. | description of changes from [RFC6195] to this document. | |||
Cut back RRTYPE Expert review period to two weeks and eliminate the | Cut back RRTYPE Expert review period to two weeks and eliminate the | |||
mandatory dnsext@ietf.org comment period. Change workflow description | mandatory dnsext@ietf.org comment period. Change workflow description | |||
for RRTYPE review and allocation to correspond more closely to actual | for RRTYPE review and allocation to correspond more closely to actual | |||
practice. | practice. | |||
Close the AFSDB sub-type registry. | Close the AFSDB sub-type registry and add an informative reference to | |||
[RFC5864] where the use of the AFSDB RR to locate AFS cell database | ||||
Update references for revised versions. | servers is deprecated. | |||
Clarify IANA archiving of referenced documentation as well as | Clarify IANA archiving of referenced documentation as well as | |||
approved RRTYPE application template. | approved RRTYPE application template. | |||
In the RRTYPE application template, change the label of question "B" | In the RRTYPE application template, change the label of question "B" | |||
to "B.1" and add "B.2" to ask about the kind of RR. | to "B.1" and add "B.2" to ask about the kind of RR. | |||
Addition of text and an exclusory regular expression to Sections 3.1 | Addition of text and an exclusory regular expression to Sections 3.1 | |||
and 3.2 to prohibit the use of the generic CLASS and RRTYPE names | and 3.2 to prohibit the use of a slight generalization of the generic | |||
specified in [RFC3597] as the mnemonics for new CLASSes and RRTYPEes. | CLASS and RRTYPE names specified in [RFC3597] as the mnemonics for | |||
new CLASSes and RRTYPEes. | ||||
Parenthetically list "ANY" and well as "ALL" as a meaning for the "*" | ||||
RRTYPE. | ||||
Clarify that there is one DNS error number space for headers, OPT | ||||
extended headers, TSIG RRs, and TKEY RRs. Note the overloading of | ||||
error number 9 as well as 16. Note that this can be considered to | ||||
update [RFC2845] and [RFC2930]. | ||||
Update references for revised versions. | ||||
A number of editorial changes and typo fixes. | A number of editorial changes and typo fixes. | |||
INTERNET-DRAFT DNS IANA Considerations | INTERNET-DRAFT DNS IANA Considerations | |||
Normative References | Normative References | |||
[RFC1034] - Mockapetris, P., "Domain names - concepts and | [RFC1034] - Mockapetris, P., "Domain names - concepts and | |||
facilities", STD 13, RFC 1034, November 1987. | facilities", STD 13, RFC 1034, November 1987. | |||
[RFC1035] - Mockapetris, P., "Domain names - implementation and | [RFC1035] - Mockapetris, P., "Domain names - implementation and | |||
specification", STD 13, RFC 1035, November 1987. | specification", STD 13, RFC 1035, November 1987. | |||
[RFC1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone | [RFC1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone | |||
Changes (DNS NOTIFY)", RFC 1996, August 1996. | Changes (DNS NOTIFY)", RFC 1996, August 1996. | |||
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate | ||||
Requirement Levels", BCP 14, RFC 2119, March 1997 | ||||
[RFC2136] - Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, | [RFC2136] - Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, | |||
"Dynamic Updates in the Domain Name System (DNS UPDATE)", | "Dynamic Updates in the Domain Name System (DNS UPDATE)", | |||
RFC 2136, April 1997. | RFC 2136, April 1997. | |||
[RFC2181] - Elz, R. and R. Bush, "Clarifications to the DNS | [RFC2181] - Elz, R. and R. Bush, "Clarifications to the DNS | |||
Specification", RFC 2181, July 1997. | Specification", RFC 2181, July 1997. | |||
[RFC2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. | [RFC2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. | |||
Wellington, "Secret Key Transaction Authentication for | Wellington, "Secret Key Transaction Authentication for | |||
DNS (TSIG)", RFC 2845, May 2000. | DNS (TSIG)", RFC 2845, May 2000. | |||
skipping to change at page 18, line 54 | skipping to change at page 20, line 5 | |||
4033, March 2005. | 4033, March 2005. | |||
[RFC4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "Resource Records for the DNS Security Extensions", | Rose, "Resource Records for the DNS Security Extensions", | |||
RFC 4034, March 2005. | RFC 4034, March 2005. | |||
[RFC4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "Protocol Modifications for the DNS Security | Rose, "Protocol Modifications for the DNS Security | |||
Extensions", RFC 4035, March 2005. | Extensions", RFC 4035, March 2005. | |||
INTERNET-DRAFT DNS IANA Considerations | ||||
[RFC4635] - Eastlake 3rd, D., "HMAC SHA (Hashed Message | [RFC4635] - Eastlake 3rd, D., "HMAC SHA (Hashed Message | |||
Authentication Code, Secure Hash Algorithm) TSIG | Authentication Code, Secure Hash Algorithm) TSIG | |||
Algorithm Identifiers", RFC 4635, August 2006. | Algorithm Identifiers", RFC 4635, August 2006. | |||
INTERNET-DRAFT DNS IANA Considerations | ||||
[RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
May 2008. | May 2008. | |||
[RFC2671bis] - Damas, J., Graff, M., and Vixie, P., "Extension | [RFC2671bis] - Damas, J., Graff, M., and Vixie, P., "Extension | |||
Mechanisms for DNS (EDNS0)", draft-ietf-dnsext- | Mechanisms for DNS (EDNS0)", draft-ietf-dnsext- | |||
rfc2671bis-edns0, work in progress. | rfc2671bis-edns0, work in progress. | |||
[RFCdnssecbisup] - Weiler, A. and D. Blacka, "Clarifications and | ||||
Implementation Notes for DNSSECbis", draft-ietf-dnsext- | ||||
dnssec-bis-updates, work in progress. | ||||
[US-ASCII] - ANSI, "USA Standard Code for Information Interchange", | [US-ASCII] - ANSI, "USA Standard Code for Information Interchange", | |||
X3.4, American National Standards Institute: New York, | X3.4, American National Standards Institute: New York, | |||
1968 | 1968 | |||
Informative References | Informative References | |||
[Dyer1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical | [Dyer1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical | |||
Plan - Name Service, April 1987. | Plan - Name Service, April 1987. | |||
[Moon1981] - Moon, D., "Chaosnet", A.I. Memo 628, Massachusetts | [Moon1981] - Moon, D., "Chaosnet", A.I. Memo 628, Massachusetts | |||
skipping to change at page 19, line 47 | skipping to change at page 21, line 5 | |||
[RFC2673] - Crawford, M., "Binary Labels in the Domain Name System", | [RFC2673] - Crawford, M., "Binary Labels in the Domain Name System", | |||
RFC 2673, August 1999. | RFC 2673, August 1999. | |||
[RFC2931] - Eastlake 3rd, D., "DNS Request and Transaction Signatures | [RFC2931] - Eastlake 3rd, D., "DNS Request and Transaction Signatures | |||
( SIG(0)s )", RFC 2931, September 2000. | ( SIG(0)s )", RFC 2931, September 2000. | |||
[RFC4343] - Eastlake 3rd, D., "Domain Name System (DNS) Case | [RFC4343] - Eastlake 3rd, D., "Domain Name System (DNS) Case | |||
Insensitivity Clarification", RFC 4343, January 2006. | Insensitivity Clarification", RFC 4343, January 2006. | |||
INTERNET-DRAFT DNS IANA Considerations | ||||
[RFC5864] - Allbery, R., "DNS SRV Resource Records for AFS", RFC | ||||
5864, April 2010. | ||||
[RFC6195] - Eastlake 3rd, D., "Domain Name System (DNS) IANA | [RFC6195] - Eastlake 3rd, D., "Domain Name System (DNS) IANA | |||
Considerations", RFC 6195, March 2011. | Considerations", RFC 6195, March 2011. | |||
INTERNET-DRAFT DNS IANA Considerations | INTERNET-DRAFT DNS IANA Considerations | |||
Author's Address | Author's Address | |||
Donald E. Eastlake 3rd | Donald E. Eastlake 3rd | |||
Huawei R&D USA | Huawei R&D USA | |||
155 Beaver Street | 155 Beaver Street | |||
End of changes. 37 change blocks. | ||||
63 lines changed or deleted | 117 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |