draft-ietf-dnsext-rfc6195bis-01.txt | draft-ietf-dnsext-rfc6195bis-02.txt | |||
---|---|---|---|---|
INTERNET-DRAFT Donald Eastlake | INTERNET-DRAFT Donald Eastlake | |||
Obsoletes: 6195 Huawei | Obsoletes: 6195 Huawei | |||
Updates: 1183, 3597 | Updates: 1183, 3597 | |||
Intended status: Best Current Practice | Intended status: Best Current Practice | |||
Expires: November 1, 2012 May 2, 2012 | Expires: December 9, 2012 June 10, 2012 | |||
Domain Name System (DNS) IANA Considerations | Domain Name System (DNS) IANA Considerations | |||
<draft-ietf-dnsext-rfc6195bis-01.txt> | <draft-ietf-dnsext-rfc6195bis-02.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. | subtypes. It obsoletes RFC 6195 and updates RFCs 1183 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 1, line 40 | skipping to change at page 1, line 40 | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/1id-abstracts.html | http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft | |||
Shadow Directories can be accessed at | ||||
The list of Internet-Draft 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 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?.........................................4 | |||
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....................................7 | |||
3.1. RRTYPE IANA Considerations............................8 | 3.1 RRTYPE IANA Considerations.............................8 | |||
3.1.1. DNS RRTYPE Allocation Policy........................9 | 3.1.1 DNS RRTYPE Allocation Policy.........................9 | |||
3.1.2. DNS RRTYPE Expert Guidelines.......................10 | 3.1.2 DNS RRTYPE Expert Guidelines........................10 | |||
3.1.3. Special Note on the OPT RR.........................10 | 3.1.3 Special Note on the OPT RR..........................10 | |||
3.1.4. The AFSDB RR Subtype Field.........................11 | 3.1.4 The AFSDB RR Subtype Field..........................11 | |||
3.2. RR CLASS IANA Considerations.........................11 | 3.2 RR CLASS IANA Considerations..........................11 | |||
3.3. Label Considerations.................................13 | 3.3. Label Considerations.................................13 | |||
3.3.1. Label Types........................................13 | 3.3.1 Label Types.........................................13 | |||
3.3.2. Label Contents and Use.............................13 | 3.3.2 Label Contents and Use..............................13 | |||
4. Security Considerations................................14 | 4. Security Considerations................................15 | |||
5. IANA Considerations....................................14 | 5. IANA Considerations....................................15 | |||
Appendix A: RRTYPE Allocation Template....................15 | Appendix A: RRTYPE Allocation Template....................16 | |||
Appendix B: Changes From RFC 6195.........................16 | Appendix B: Changes From RFC 6195.........................17 | |||
Normative References......................................17 | Normative References......................................18 | |||
Informative References....................................18 | Informative References....................................19 | |||
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 30 | skipping to change at page 3, line 30 | |||
query/response OpCode for such considerations if they have been | query/response OpCode for such considerations if they have been | |||
defined, except for AFSDB RR considerations [RFC1183], which are | defined, except for AFSDB RR considerations [RFC1183], which are | |||
included herein. This RFC obsoletes [RFC6195]; however, the only | included herein. This RFC obsoletes [RFC6195]; however, the only | |||
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]. | |||
1.2 Acknowledgement | 1.2 Acknowledgement | |||
Alfred Hoenes contributions are gratefully acknowledged. | Alfred Hoenes contributions are gratefully acknowledged. | |||
INTERNET-DRAFT DNS IANA Considerations | INTERNET-DRAFT DNS IANA Considerations | |||
skipping to change at page 4, line 50 | skipping to change at page 4, line 50 | |||
Action. | 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. | |||
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 | 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 | New OpCode assignments require a Standards Action as modified by | |||
[RFC4020]. | [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 | OPT RRs [RFC2671bis], TSIG RRs [RFC2845], and TKEY RRs [RFC2930]. The | |||
OPT RR provides an 8-bit extension resulting in a 12-bit RCODE field, | 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. | and the TSIG and TKEY RRs have a 16-bit RCODE field. | |||
Error codes appearing in the DNS header and in these three RR types | 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 | all refer to the same error code space with the single exception of | |||
skipping to change at page 8, line 7 | skipping to change at page 8, line 7 | |||
RDLENGTH is an unsigned 16-bit integer that specifies the length in | RDLENGTH is an unsigned 16-bit integer that specifies the length in | |||
octets of the RDATA field. | octets of the RDATA field. | |||
RDATA is a variable-length string of octets that constitutes the | RDATA is a variable-length string of octets that constitutes the | |||
resource. The format of this information varies according to the TYPE | resource. The format of this information varies according to the TYPE | |||
and, in some cases, the CLASS of the resource record. | and, in some cases, the CLASS of the resource record. | |||
INTERNET-DRAFT DNS IANA Considerations | INTERNET-DRAFT DNS IANA Considerations | |||
3.1. RRTYPE IANA Considerations | 3.1 RRTYPE IANA Considerations | |||
There are three subcategories of RRTYPE numbers: data TYPEs, QTYPEs, | There are three subcategories of RRTYPE numbers: data TYPEs, QTYPEs, | |||
and Meta-TYPEs. | and Meta-TYPEs. | |||
Data TYPEs are the means of storing data. QTYPES can only be used in | Data TYPEs are the means of storing data. QTYPES can only be used in | |||
queries. Meta-TYPEs designate transient data associated with a | queries. Meta-TYPEs designate transient data associated with a | |||
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), MAILA, MAILB, AXFR, and IXFR. | |||
RRTYPEs have mnemonics that must be completely disjoint from the | Allocated RRTYPEs have mnemonics that must be completely disjoint | |||
mnemonics used for CLASSes and that must match the following regular | from the mnemonics used for CLASSes and that must match the regular | |||
expression: | expression below. In addition, the generic CLASS and RRTYPE names | |||
specified in Section 5 of [RFC3597] cannot be assigned as new RRTYPE | ||||
mnemonics. | ||||
[A-Z][A-Z0-9\-]*[A-Z0-9] | [A-Z][A-Z0-9\-]*[A-Z0-9] | |||
but not | ||||
(TYPE|CLASS)(0|[1-9][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 | |||
ordinary use. | ordinary use. | |||
1 - 127 | 1 - 127 | |||
0x0001 - 0x007F Remaining RRTYPEs in this range are assigned for | 0x0001 - 0x007F Remaining RRTYPEs in this range are assigned for | |||
data TYPEs by the DNS RRTYPE Allocation Policy as | data TYPEs by the DNS RRTYPE Allocation Policy as | |||
skipping to change at page 9, line 24 | skipping to change at page 9, line 24 | |||
0xF000 - 0xFEFF Reserved for future use. IETF Review required to | 0xF000 - 0xFEFF Reserved for future use. IETF Review required to | |||
define use. | define use. | |||
65,280 - 65,534 | 65,280 - 65,534 | |||
0xFF00 - 0xFFFE Private Use. | 0xFF00 - 0xFFFE Private Use. | |||
65,535 | 65,535 | |||
0xFFFF Reserved, can only be assigned by a Standards | 0xFFFF Reserved, can only be assigned by a Standards | |||
Action. | Action. | |||
3.1.1. DNS RRTYPE Allocation Policy | 3.1.1 DNS RRTYPE Allocation Policy | |||
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. | interest, IANA may select another Expert from the pool. Some | |||
guidelines for the Experts are given in Section 3.1.2. | ||||
Some guidelines for the Experts are given in Section 3.1.2. RRTYPEs | RRTYPEs that do not meet the requirements below may nonetheless be | |||
that do not meet the requirements below may nonetheless be allocated | allocated by a Standards Action as modified by [RFC4020]. | |||
by a Standards Action as modified by [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@iana.org mailing list and received by | the dns-rrtype-applications@iana.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 | |||
skipping to change at page 10, line 26 | skipping to change at page 10, line 26 | |||
should consult with other technical experts and the dnsext@ietf.org | should consult with other technical experts and the dnsext@ietf.org | |||
mailing list as necessary. If the Expert does not approve the | mailing list as necessary. If the Expert does not approve the | |||
application within this period, it is considered rejected. IANA | application within this period, it is considered rejected. IANA | |||
should report non-responsive Experts to the IESG. | 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 Expert should normally reject any RRTYPE allocation request that | |||
meets one or more of the following criteria: | 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. | |||
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 | 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 show below. This subtype registry is closed and allocation | subtype as shown below. This subtype registry is closed and | |||
of new subtypes is no longer permitted. | 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 36 | skipping to change at page 11, line 36 | |||
3 - 65,279 | 3 - 65,279 | |||
0x0003 - 0xFEFF Not allocated, registry closed | 0x0003 - 0xFEFF Not allocated, registry closed | |||
65,280 - 65,534 | 65,280 - 65,534 | |||
0xFF00 - 0xFFFE Private Use | 0xFF00 - 0xFFFE Private Use | |||
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. | |||
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 | |||
skipping to change at page 12, line 9 | skipping to change at page 12, line 9 | |||
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 | 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 | |||
INTERNET-DRAFT DNS IANA Considerations | INTERNET-DRAFT DNS IANA Considerations | |||
"meta-CLASSes". | "meta-CLASSes". | |||
CLASSes have mnemonics that must be completely disjoint from the | Assigned CLASSes have mnemonics that must be completely disjoint from | |||
mnemonics used for RRTYPEs and that must match the following regular | the mnemonics used for RRTYPEs and that must match the regular | |||
expression: | expression below. In addition, the generic CLASS and RRTYPE names | |||
specified in Section 5 of [RFC3597] cannot be assigned as new CLASS | ||||
mnemonics. | ||||
[A-Z][A-Z0-9\-]*[A-Z0-9] | [A-Z][A-Z0-9\-]*[A-Z0-9] | |||
but not | ||||
(CLASS|RRTYPE)(0|[1-9][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 54 | skipping to change at page 13, line 5 | |||
254 | 254 | |||
0x00FE QCLASS NONE [RFC2136] | 0x00FE QCLASS NONE [RFC2136] | |||
255 | 255 | |||
0x00FF QCLASS * (ANY) [RFC1035] | 0x00FF QCLASS * (ANY) [RFC1035] | |||
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 | ||||
0x8000 - 0xDFFF Assigned for data CLASSes only; Specification | ||||
Required for new assignments | ||||
INTERNET-DRAFT DNS IANA Considerations | INTERNET-DRAFT DNS IANA Considerations | |||
32,768 - 57,343 | ||||
0x8000 - 0xDFFF Available for assignment to data CLASSes only; | ||||
Specification Required | ||||
57,344 - 65,279 | 57,344 - 65,279 | |||
0xE000 - 0xFEFF Assigned for QCLASSes and meta-CLASSes only; | 0xE000 - 0xFEFF Available for assignment to QCLASSes and meta- | |||
Specification Required for new assignments | CLASSes only; Specification Required | |||
65,280 - 65,534 | 65,280 - 65,534 | |||
0xFF00 - 0xFFFE Private Use | 0xFF00 - 0xFFFE Private Use | |||
65,535 | 65,535 | |||
0xFFFF Reserved; can only be assigned by a Standards | 0xFFFF Reserved; can only be assigned by a Standards | |||
Action | Action | |||
3.3. Label Considerations | 3.3. Label Considerations | |||
DNS NAMEs are sequences of labels [RFC1035]. | DNS NAMEs are sequences of labels [RFC1035]. | |||
3.3.1. Label Types | 3.3.1 Label Types | |||
At the present time, there are two categories of label types: data | At the present time, there are two categories of label types: data | |||
labels and compression labels. Compression labels are pointers to | labels and compression labels. Compression labels are pointers to | |||
data labels elsewhere within an RR or DNS message and are intended to | data labels elsewhere within an RR or DNS message and are intended to | |||
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 [RFC20]. 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]. | |||
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 | |||
[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 16, line 9 | skipping to change at page 17, line 9 | |||
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 | |||
as an unknown RRTYPE (see [RFC3597])? | as an unknown RRTYPE (see [RFC3597])? | |||
J. Comments: | J. Comments: | |||
INTERNET-DRAFT DNS IANA Considerations | INTERNET-DRAFT DNS IANA Considerations | |||
Appendix B: Changes From RFC 6195 | Appendix B: Changes From RFC 6195 | |||
Drop description of changes from RFC 5395 to RFC 6195 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 RFC 6195. | 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 AFSDB sub-type registry. | Close the AFSDB sub-type registry. | |||
Update references for revised versions and change ASCII reference to | Update references for revised versions. | |||
[RFC20]. | ||||
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 | ||||
and 3.2 to prohibit the use of the generic CLASS and RRTYPE names | ||||
specified in [RFC3597] as the mnemonics for new CLASSes and RRTYPEes. | ||||
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 | |||
[RFC20] - Cerf, V., "ASCII format for network interchange", RFC 20, | ||||
October 1969. | ||||
[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. | |||
[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)", RFC 2136, | "Dynamic Updates in the Domain Name System (DNS UPDATE)", | |||
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 DNS (TSIG)", | Wellington, "Secret Key Transaction Authentication for | |||
RFC 2845, May 2000. | DNS (TSIG)", RFC 2845, May 2000. | |||
[RFC2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY | [RFC2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY | |||
RR)", RFC 2930, September 2000. | RR)", RFC 2930, September 2000. | |||
[RFC3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November | [RFC3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November | |||
2002. | 2002. | |||
[RFC3597] - Gustafsson, A., "Handling of Unknown DNS Resource Record | [RFC3597] - Gustafsson, A., "Handling of Unknown DNS Resource Record | |||
(RR) Types", RFC 3597, September 2003. | (RR) Types", RFC 3597, September 2003. | |||
[RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of | [RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of | |||
Standards Track Code Points", BCP 100, RFC 4020, February 2005. | Standards Track Code Points", BCP 100, RFC 4020, February | |||
2005. | ||||
[RFC4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "DNS Security Introduction and Requirements", RFC 4033, March | Rose, "DNS Security Introduction and Requirements", RFC | |||
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", RFC 4034, | Rose, "Resource Records for the DNS Security Extensions", | |||
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 Extensions", RFC | Rose, "Protocol Modifications for the DNS Security | |||
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 Algorithm | Authentication Code, Secure Hash Algorithm) TSIG | |||
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, May 2008. | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
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-rfc2671bis-edns0, work | Mechanisms for DNS (EDNS0)", draft-ietf-dnsext- | |||
in progress. | rfc2671bis-edns0, work in progress. | |||
[US-ASCII] - ANSI, "USA Standard Code for Information Interchange", | ||||
X3.4, American National Standards Institute: New York, | ||||
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 | |||
Institute of Technology Artificial Intelligence Laboratory, June | Institute of Technology Artificial Intelligence | |||
1981. | Laboratory, June 1981. | |||
[RFC1183] - Everhart, C., Mamakos, L., Ullmann, R., and P. | [RFC1183] - Everhart, C., Mamakos, L., Ullmann, R., and P. | |||
Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990. | Mockapetris, "New DNS RR Definitions", RFC 1183, October | |||
1990. | ||||
[RFC1591] - Postel, J., "Domain Name System Structure and | [RFC1591] - Postel, J., "Domain Name System Structure and | |||
Delegation", RFC 1591, March 1994. | Delegation", RFC 1591, March 1994. | |||
[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. | |||
[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. | |||
[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 | |||
Milford, MA 01757 USA | Milford, MA 01757 USA | |||
End of changes. 68 change blocks. | ||||
103 lines changed or deleted | 119 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/ |