draft-ietf-dnsext-rfc6195bis-04.txt | draft-ietf-dnsext-rfc6195bis-05.txt | |||
---|---|---|---|---|
INTERNET-DRAFT Donald Eastlake | INTERNET-DRAFT Donald Eastlake | |||
Obsoletes: 6195 Huawei | Obsoletes: 6195 Huawei | |||
Updates: 1183, 2845, 2930, 3597 | Updates: 1183, 2845, 2930, 3597 | |||
Intended status: Best Current Practice | Intended status: Best Current Practice | |||
Expires: January 14, 2013 July 15, 2012 | Expires: April 12, 2013 October 13, 2012 | |||
Domain Name System (DNS) IANA Considerations | Domain Name System (DNS) IANA Considerations | |||
<draft-ietf-dnsext-rfc6195bis-04.txt> | <draft-ietf-dnsext-rfc6195bis-05.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, 2845, 2930, | subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, | |||
and 3597. | and 3597. | |||
skipping to change at page 2, line 11 | skipping to change at page 2, line 11 | |||
http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft | http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft | |||
Shadow Directories can be accessed at | Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
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 Acknowledgements.......................................3 | |||
2. DNS Query/Response Headers..............................4 | 2. DNS Query/Response Headers..............................4 | |||
2.1 One Spare Bit?.........................................5 | 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....................................8 | 3. DNS Resource Records....................................8 | |||
3.1 RRTYPE IANA Considerations.............................9 | 3.1 RRTYPE IANA Considerations.............................9 | |||
3.1.1 DNS RRTYPE Allocation Policy........................10 | 3.1.1 DNS RRTYPE Allocation Policy........................10 | |||
3.1.2 DNS RRTYPE Expert Guidelines........................11 | 3.1.2 DNS RRTYPE Expert Guidelines........................11 | |||
3.1.3 Special Note on the OPT RR..........................11 | 3.1.3 Special Note on the OPT RR..........................12 | |||
3.1.4 The AFSDB RR Subtype Field..........................12 | 3.1.4 The AFSDB RR Subtype Field..........................12 | |||
3.2 RR CLASS IANA Considerations..........................12 | 3.2 RR CLASS IANA Considerations..........................12 | |||
3.3. Label Considerations.................................14 | 3.3. Label Considerations.................................14 | |||
3.3.1 Label Types.........................................14 | 3.3.1 Label Types.........................................14 | |||
3.3.2 Label Contents and Use..............................14 | 3.3.2 Label Contents and Use..............................15 | |||
4. Security Considerations................................16 | 4. Security Considerations................................16 | |||
5. IANA Considerations....................................16 | 5. IANA Considerations....................................16 | |||
Appendix A: RRTYPE Allocation Template....................17 | Appendix A: RRTYPE Allocation Template....................17 | |||
Appendix B: Changes From RFC 6195.........................18 | Appendix B: Changes From RFC 6195.........................18 | |||
Normative References......................................19 | Normative References......................................19 | |||
Informative References....................................20 | Informative References....................................20 | |||
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]. The key words "MUST", | "Private Use" are as defined in [RFC5226]. | |||
"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 Acknowledgements | |||
Alfred Hoenes contributions are gratefully acknowledged as are those | Alfred Hoenes' contributions are gratefully acknowledged as are those | |||
by Mark Andrews, Dick Franks, and Michael Sheldon. | 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]: | |||
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 | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
| ID | | | ID | | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
|QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE | | |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE | | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
| QDCOUNT/ZOCOUNT | | | QDCOUNT/ZOCOUNT | | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
skipping to change at page 5, line 32 | skipping to change at page 5, line 32 | |||
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 | |||
Although the Status OpCode is reserved in [RFC1035], its behavior has | Although the Status OpCode is reserved in [RFC1035], its behavior has | |||
not been specified. New OpCode assignments require a Standards Action | not been specified. New OpCode assignments require a Standards Action | |||
as modified by [RFC4020]. | with early allocation permitted as specified in [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 | |||
TSIG RRs [RFC2845], TKEY RRs [RFC2930], and extended by OPT RRs | TSIG RRs [RFC2845], TKEY RRs [RFC2930], and extended by OPT RRs | |||
[RFC2671bis]. The OPT RR provides an 8-bit extension to the 4 header | [RFC2671bis]. The OPT RR provides an 8-bit extension to the 4 header | |||
bits resulting in a 12-bit RCODE field, and the TSIG and TKEY RRs | 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. | have a 16-bit field designated in their RFCs as the "Error" field. | |||
skipping to change at page 6, line 7 | skipping to change at page 6, line 7 | |||
code 16, which has a different meaning in the OPT RR than in the TSIG | code 16, which has a different meaning in the OPT RR than in the TSIG | |||
RR, and error code 9 whose variations are described after the table | RR, and error code 9 whose variations are described after the table | |||
below. The duplicate assignment of 16 was accidental. To the extent | below. The duplicate assignment of 16 was accidental. To the extent | |||
that any prior RFCs imply any sort of different error number space | 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 | for the OPT, TSIG, or TKEY RRs, they are superseded by this unified | |||
DNS error number space. (This paragraph is the reason this document | DNS error number space. (This paragraph is the reason this document | |||
updates [RFC2845] and [RFC2930].) With the existing exceptions of | 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 | 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 | for different errors even if they would only occur in different RR | |||
types. See table below. | 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 See note below after table | 9 NotAuth Server Not Authoritative for zone [RFC2136] | |||
9 NotAuth Not Authorized [RFC2845] | ||||
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 52 | skipping to change at page 6, line 53 | |||
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 | Note on error number 9 (NotAuth): This error number means either "Not | |||
Authoritative" [RFC2136] or "Not Authorized" [RFC2845]. If 9 | Authoritative" [RFC2136] or "Not Authorized" [RFC2845]. If 9 | |||
appears as the RCODE in the header of a DNS response without a | 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 | 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 | INTERNET-DRAFT DNS IANA Considerations | |||
"Not Authoritative". If 9 appears as the RCODE in the header of a | ||||
DNS response that includes a TSIG RR with a non-zero error field, | DNS response that includes a TSIG RR with a non-zero error field, | |||
then it means "Not Authorized". | 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 | |||
skipping to change at page 10, line 36 | skipping to change at page 10, line 36 | |||
Parameter values specified in Section 3.1 above as assigned based on | Parameter values specified in Section 3.1 above as assigned based on | |||
DNS RRTYPE Allocation Policy, are allocated by Expert Review if they | DNS RRTYPE Allocation Policy, are allocated by Expert Review if they | |||
meet the two requirements listed below. There will be a pool of a | meet the two requirements listed below. There will be a pool of a | |||
small number of Experts appointed by the IESG. Each application will | small number of Experts appointed by the IESG. Each application will | |||
be judged by an Expert selected by IANA. In any case where the | be judged by an Expert selected by IANA. In any case where the | |||
selected Expert is unavailable or states they have a conflict of | selected Expert is unavailable or states they have a conflict of | |||
interest, IANA may select another Expert from the pool. Some | interest, IANA may select another Expert from the pool. Some | |||
guidelines for the Experts are given in Section 3.1.2. | guidelines for the Experts are given in Section 3.1.2. | |||
RRTYPEs that do not meet the requirements below may nonetheless be | RRTYPEs that do not meet the requirements below may nonetheless be | |||
allocated by a Standards Action as modified by [RFC4020]. | allocated by a Standards Action with early allocation permitted as | |||
specified in [RFC4020]. | ||||
1. A complete template as specified in Appendix A has been posted to | 1. A complete template as specified in Appendix A has been posted to | |||
the dns-rrtype-applications@ietf.org mailing list and received by | the dns-rrtype-applications@ietf.org mailing list and received by | |||
the Expert. | the Expert. | |||
Note that the posting of partially completed, draft, or | Note that the posting of partially completed, draft, or | |||
formally submitted templates to dnsext@ietf.org by the applicant | formally submitted templates to dnsext@ietf.org by the applicant | |||
or Expert for comment and discussion is highly encouraged. Formal | or Expert for comment and discussion is highly encouraged. Formal | |||
submission of an RRTYPE template without consideration of some | submission of an RRTYPE template without consideration of some | |||
community review can be expected to increase the probability of | community review can be expected to increase the probability of | |||
initial rejection leading to a need to re-submit after | initial rejection leading to a need to re-submit after | |||
modification. | modification. | |||
2. The RR for which an RRTYPE code is being requested is either (a) a | 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 | 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., | [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 | it is safe to simply discard RRs with that Meta-TYPE in queries or | |||
responses. | responses. | |||
Note that such RRs may include additional section processing, | ||||
INTERNET-DRAFT DNS IANA Considerations | INTERNET-DRAFT DNS IANA Considerations | |||
Note that such RRs may include additional section processing, | ||||
provided such processing is optional. | provided such processing is optional. | |||
After the applicant submits their formal application to IANA by | After the applicant submits their formal application to IANA by | |||
sending the completed template specified in Appendix A to the dns- | sending the completed template specified in Appendix A to the dns- | |||
rrtype-applications@ietf.org mailing list, IANA appoints an Expert | rrtype-applications@ietf.org mailing list, IANA appoints an Expert | |||
and sends the completed template to the Expert copying the applicant. | and sends the completed template to the Expert copying the applicant. | |||
No more than two weeks after receiving the application the Expert | No more than two weeks after receiving the application the Expert | |||
shall explicitly approve or reject the application, informing IANA, | shall explicitly approve or reject the application, informing IANA, | |||
the applicant, and the dnsext@ietf.org mailing list. The Expert | the applicant, and the dnsext@ietf.org mailing list. A rejection | |||
should consult with other technical experts and the dnsext@ietf.org | should include the reason for rejection and may include suggestions | |||
mailing list as necessary. If the Expert does not approve the | for improvement. The Expert should consult with other technical | |||
application within this period, it is considered rejected. IANA | experts and the dnsext@ietf.org mailing list as necessary. If the | |||
should report non-responsive Experts to the IESG. | Expert does not approve the application within this period, it is | |||
considered rejected. IANA should report non-responsive Experts to the | ||||
IESG. | ||||
IANA shall maintain a public archive of approved templates. In | IANA shall maintain a public archive of approved templates. In | |||
addition, if the required description of the RRTYPE applied for is | addition, if the required description of the RRTYPE applied for is | |||
referenced by URL, a copy of the document so referenced should be | referenced by URL, a copy of the document so referenced should be | |||
included in the archive. | included in the archive. | |||
3.1.2 DNS RRTYPE Expert Guidelines | 3.1.2 DNS RRTYPE Expert Guidelines | |||
The Expert should normally reject any RRTYPE allocation request that | The Designated Expert should normally be lenient, preferring to | |||
meets one or more of the following criteria: | approve most requests. However, the Expert should usually 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 or | 1. Was documented in a manner that was not sufficiently clear or | |||
complete to evaluate or implement. (Additional documentation can | complete to evaluate or implement. (Additional documentation can | |||
be provided during the Expert review period.) | be provided during the Expert review period.) | |||
2. The proposed RRTYPE or RRTYPEs affect DNS processing and do not | 2. The proposed RRTYPE or RRTYPEs affect DNS processing and do not | |||
meet the criteria in point 2 of Section 3.1.1 above. | meet the criteria in point 2 of Section 3.1.1 above. | |||
3. Application use as documented makes incorrect assumptions about | 3. Application use as documented makes incorrect assumptions about | |||
DNS protocol behavior, such as wild cards, CNAME, DNAME, etc. | DNS protocol behavior, such as wild cards, CNAME, DNAME, etc. | |||
4. An excessive number of RRTYPE values is being requested when the | 4. An excessive number of RRTYPE values is being requested when the | |||
purpose could be met with a smaller number or with Private Use | purpose could be met with a smaller number or with Private Use | |||
values. | values. | |||
INTERNET-DRAFT DNS IANA Considerations | ||||
3.1.3 Special Note on the OPT RR | 3.1.3 Special Note on the OPT RR | |||
The OPT (OPTion) RR (RRTYPE 41) and its IANA considerations are | The OPT (OPTion) RR (RRTYPE 41) and its IANA considerations are | |||
specified in [RFC2671bis]. Its primary purpose is to extend the | specified in [RFC2671bis]. Its primary purpose is to extend the | |||
effective field size of various DNS fields including RCODE, label | effective field size of various DNS fields including RCODE, label | |||
type, OpCode, flag bits, and RDATA size. In particular, for resolvers | type, OpCode, flag bits, and RDATA size. In particular, for resolvers | |||
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 | ||||
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. Use of the AFSDB RR to locate AFS cell | subtype as shown below. Use of the AFSDB RR to locate AFS cell | |||
database servers was deprecated by [RFC5864]. This subtype registry | database servers was deprecated by [RFC5864]. This subtype registry | |||
is hereby closed and allocation of new subtypes is no longer | is hereby closed and allocation of new subtypes is no longer | |||
permitted. | permitted. | |||
skipping to change at page 12, line 44 | skipping to change at page 13, line 5 | |||
65,535 | 65,535 | |||
0xFFFF Reserved, registry closed | 0xFFFF Reserved, registry closed | |||
3.2 RR CLASS IANA Considerations | 3.2 RR CLASS IANA Considerations | |||
There are currently two subcategories of DNS CLASSes: normal, data- | There are currently two subcategories of DNS CLASSes: normal, data- | |||
containing classes and QCLASSes that are only meaningful in queries | containing classes and QCLASSes that are only meaningful in queries | |||
or updates. | or updates. | |||
INTERNET-DRAFT DNS IANA Considerations | ||||
DNS CLASSes have been little used but constitute another dimension of | DNS CLASSes have been little used but constitute another dimension of | |||
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 | |||
INTERNET-DRAFT DNS IANA Considerations | ||||
particular DNS message, which might be usable in queries. However, it | particular DNS message, which might be usable in queries. However, it | |||
is possible that there might be a future requirement for one or more | 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. | |||
skipping to change at page 13, line 47 | skipping to change at page 14, line 5 | |||
3 | 3 | |||
0x0003 Chaos (CH) [Moon1981] | 0x0003 Chaos (CH) [Moon1981] | |||
4 | 4 | |||
0x0004 Hesiod (HS) [Dyer1987] | 0x0004 Hesiod (HS) [Dyer1987] | |||
5 - 127 | 5 - 127 | |||
0x0005 - 0x007F Available for assignment by IETF Review for data | 0x0005 - 0x007F Available for assignment by IETF Review for data | |||
CLASSes only | CLASSes only | |||
INTERNET-DRAFT DNS IANA Considerations | ||||
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 | |||
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 | |||
skipping to change at page 14, line 44 | skipping to change at page 15, line 5 | |||
shorten the wire encoding of NAMEs. | shorten the wire encoding of NAMEs. | |||
The two existing data label types are sometimes referred to as Text | The two existing data label types are sometimes referred to as Text | |||
and Binary. Text labels can, in fact, include any octet value | and Binary. Text labels can, in fact, include any octet value | |||
including zero-value octets, but many current uses involve only | including zero-value octets, but many current uses involve only | |||
printing ASCII characters [US-ASCII]. For retrieval, Text labels are | printing ASCII characters [US-ASCII]. For retrieval, Text labels are | |||
defined to treat ASCII upper and lower case letter codes as matching | defined to treat ASCII upper and lower case letter codes as matching | |||
[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]. | |||
INTERNET-DRAFT DNS IANA Considerations | ||||
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. | |||
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 | |||
skipping to change at page 17, line 39 | skipping to change at page 17, line 39 | |||
experts that may have limited knowledge of your application space. | experts that may have limited knowledge of your application space. | |||
E. Description of the proposed RR type. | E. Description of the proposed RR type. | |||
This description can be provided in-line in the template, as an | This description can be provided in-line in the template, as an | |||
attachment, or with a publicly available URL. | attachment, or with a publicly available URL. | |||
F. What existing RRTYPE or RRTYPEs come closest to filling that need | F. What existing RRTYPE or RRTYPEs come closest to filling that need | |||
and why are they unsatisfactory? | and why are they unsatisfactory? | |||
G. What mnemonic is requested for the new RRTYPE (optional)? | G. What mnemonic is requested for the new RRTYPE (optional)? | |||
Note: this can be left blank and the mnemonic decided after the | Note: If a mnemonic is not supplied, not allowed, or duplicates an | |||
template is accepted. | existing RRTYPE or CLASS mnemonic, the Expert will assign a | |||
mnemonic. | ||||
H. Does the requested RRTYPE make use of any existing IANA registry | H. Does the requested RRTYPE make use of any existing IANA registry | |||
or require the creation of a new IANA sub-registry in DNS | or require the creation of a new IANA sub-registry in DNS | |||
Parameters? If so, please indicate which registry is to be used | Parameters? If so, please indicate which registry is to be used | |||
or created. If a new sub-registry is needed, specify the | or created. If a new sub-registry is needed, specify the | |||
allocation policy for it and its initial contents. Also include | allocation policy for it and its initial contents. Also include | |||
what the modification procedures will be. | what the modification procedures will be. | |||
I. Does the proposal require/expect any changes in DNS | I. Does the proposal require/expect any changes in DNS | |||
servers/resolvers that prevent the new type from being processed | servers/resolvers that prevent the new type from being processed | |||
skipping to change at page 18, line 37 | skipping to change at page 18, line 37 | |||
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 a slight generalization of the generic | and 3.2 to prohibit the use of a slight generalization of the generic | |||
CLASS and RRTYPE names specified in [RFC3597] as the mnemonics for | CLASS and RRTYPE names specified in [RFC3597] as the mnemonics for | |||
new CLASSes and RRTYPEes. | new CLASSes and RRTYPEes. | |||
Parenthetically list "ANY" and well as "ALL" as a meaning for the "*" | Parenthetically list "ANY" and well as "ALL" as a meaning for the "*" | |||
RRTYPE. | RRTYPE. | |||
Clarify that there is one DNS error number space for headers, OPT | Clarify that there is one DNS error number space for headers, OPT | |||
extended headers, TSIG RRs, and TKEY RRs. Note that this can be | extended headers, TSIG RRs, and TKEY RRs. Note that this is | |||
considered to update [RFC2845] and [RFC2930]. Note the overloading of | considered to update [RFC2845] and [RFC2930]. Note the overloading of | |||
error number 9 as well as 16. | error number 9 as well as 16. | |||
Update references for revised versions. | 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 20, line 5 | skipping to change at page 19, line 54 | |||
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 | [RFCdnssecbisup] - Weiler, A. and D. Blacka, "Clarifications and | |||
Implementation Notes for DNSSECbis", draft-ietf-dnsext- | Implementation Notes for DNSSECbis", draft-ietf-dnsext- | |||
skipping to change at page 21, line 5 | skipping to change at page 20, line 51 | |||
[RFC2606] - Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS | [RFC2606] - Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS | |||
Names", BCP 32, RFC 2606, June 1999. | Names", BCP 32, RFC 2606, June 1999. | |||
[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. | |||
INTERNET-DRAFT DNS IANA Considerations | ||||
[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 | [RFC5864] - Allbery, R., "DNS SRV Resource Records for AFS", RFC | |||
5864, April 2010. | 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 | |||
End of changes. 35 change blocks. | ||||
46 lines changed or deleted | 45 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/ |