929 lines
27 KiB
Plaintext
929 lines
27 KiB
Plaintext
|
||
INTERNET-DRAFT Donald E. Eastlake 3rd
|
||
Obsoletes RFC 2929, Updates RFC 1183 Motorola Laboratories
|
||
Expires: February 2006 August 2005
|
||
|
||
|
||
|
||
Domain Name System (DNS) IANA Considerations
|
||
------ ---- ------ ----- ---- --------------
|
||
<draft-ietf-dnsext-2929bis-01.txt>
|
||
|
||
|
||
|
||
Status of This Document
|
||
|
||
By submitting this Internet-Draft, each author represents that any
|
||
applicable patent or other IPR claims of which he or she is aware
|
||
have been or will be disclosed, and any of which he or she becomes
|
||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||
|
||
Distribution of this draft is unlimited. It is intended to become
|
||
the new BCP 42 obsoleting RFC 2929. Comments should be sent to the
|
||
DNS Working Group mailing list <namedroppers@ops.ietf.org>.
|
||
|
||
Internet-Drafts are working documents of the Internet Engineering
|
||
Task Force (IETF), its areas, and its working groups. Note that
|
||
other groups may also distribute working documents as Internet-
|
||
Drafts.
|
||
|
||
Internet-Drafts are draft documents valid for a maximum of six months
|
||
and may be updated, replaced, or obsoleted by other documents at any
|
||
time. It is inappropriate to use Internet-Drafts as reference
|
||
material or to cite them other than a "work in progress."
|
||
|
||
The list of current Internet-Drafts can be accessed at
|
||
http://www.ietf.org/1id-abstracts.html
|
||
|
||
The list of Internet-Draft Shadow Directories can be accessed at
|
||
http://www.ietf.org/shadow.html
|
||
|
||
|
||
|
||
Abstract
|
||
|
||
Internet Assigned Number Authority (IANA) parameter assignment
|
||
considerations are given for the allocation of Domain Name System
|
||
(DNS) classes, RR types, operation codes, error codes, RR header
|
||
bits, and AFSDB subtypes.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
D. Eastlake 3rd [Page 1]
|
||
|
||
|
||
INTERNET-DRAFT DNS IANA Considerations August 2005
|
||
|
||
|
||
Table of Contents
|
||
|
||
Status of This Document....................................1
|
||
Abstract...................................................1
|
||
|
||
Table of Contents..........................................2
|
||
|
||
1. Introduction............................................3
|
||
2. DNS Query/Response Headers..............................3
|
||
2.1 One Spare Bit?.........................................4
|
||
2.2 Opcode Assignment......................................4
|
||
2.3 RCODE Assignment.......................................5
|
||
3. DNS Resource Records....................................6
|
||
3.1 RR TYPE IANA Considerations............................7
|
||
3.1.1 DNS TYPE Allocation Policy...........................8
|
||
3.1.2 Special Note on the OPT RR...........................9
|
||
3.1.3 The AFSDB RR Subtype Field...........................9
|
||
3.2 RR CLASS IANA Considerations...........................9
|
||
3.3 RR NAME Considerations................................11
|
||
4. Security Considerations................................11
|
||
|
||
Appendix: Changes from RFC 2929...........................12
|
||
|
||
Copyright and Disclaimer..................................13
|
||
Normative References......................................13
|
||
Informative References....................................14
|
||
|
||
Authors Addresses.........................................16
|
||
Expiration and File Name..................................16
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
D. Eastlake 3rd [Page 2]
|
||
|
||
|
||
INTERNET-DRAFT DNS IANA Considerations August 2005
|
||
|
||
|
||
1. Introduction
|
||
|
||
The Domain Name System (DNS) provides replicated distributed secure
|
||
hierarchical databases which hierarchically store "resource records"
|
||
(RRs) under domain names. DNS data is structured into CLASSes and
|
||
zones which can be independently maintained. See [RFC 1034, 1035,
|
||
2136, 2181, 4033] familiarity with which is assumed.
|
||
|
||
This document provides, either directly or by reference, general IANA
|
||
parameter assignment considerations applying across DNS query and
|
||
response headers and all RRs. There may be additional IANA
|
||
considerations that apply to only a particular RR type or
|
||
query/response opcode. See the specific RFC defining that RR type or
|
||
query/response opcode for such considerations if they have been
|
||
defined, except for AFSDB RR considerations [RFC 1183] which are
|
||
included herein. This RFC obsoletes [RFC 2929].
|
||
|
||
IANA currently maintains a web page of DNS parameters. See
|
||
<http://www.iana.org/numbers.htm>.
|
||
|
||
"IETF Standards Action", "IETF Consensus", "Specification Required",
|
||
and "Private Use" are as defined in [RFC 2434].
|
||
|
||
|
||
|
||
2. DNS Query/Response Headers
|
||
|
||
The header for DNS queries and responses contains field/bits in the
|
||
following diagram taken from [RFC 2136, 2929]:
|
||
|
||
1 1 1 1 1 1
|
||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||
| ID |
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||
| QDCOUNT/ZOCOUNT |
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||
| ANCOUNT/PRCOUNT |
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||
| NSCOUNT/UPCOUNT |
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||
| ARCOUNT |
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||
|
||
The ID field identifies the query and is echoed in the response so
|
||
they can be matched.
|
||
|
||
The QR bit indicates whether the header is for a query or a response.
|
||
|
||
|
||
D. Eastlake 3rd [Page 3]
|
||
|
||
|
||
INTERNET-DRAFT DNS IANA Considerations August 2005
|
||
|
||
|
||
The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
|
||
only in queries or only in responses, depending on the bit. However,
|
||
many DNS implementations copy the query header as the initial value
|
||
of the response header without clearing bits. Thus any attempt to
|
||
use a "query" bit with a different meaning in a response or to define
|
||
a query meaning for a "response" bit is dangerous given existing
|
||
implementation. Such meanings may only be assigned by an IETF
|
||
Standards Action.
|
||
|
||
The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
|
||
authority count (NSCOUNT), and additional information count (ARCOUNT)
|
||
express the number of records in each section for all opcodes except
|
||
Update. These fields have the same structure and data type for
|
||
Update but are instead the counts for the zone (ZOCOUNT),
|
||
prerequisite (PRCOUNT), update (UPCOUNT), and additional information
|
||
(ARCOUNT) sections.
|
||
|
||
|
||
|
||
2.1 One Spare Bit?
|
||
|
||
There have been ancient DNS implementations for which the Z bit being
|
||
on in a query meant that only a response from the primary server for
|
||
a zone is acceptable. It is believed that current DNS
|
||
implementations ignore this bit.
|
||
|
||
Assigning a meaning to the Z bit requires an IETF Standards Action.
|
||
|
||
|
||
|
||
2.2 Opcode Assignment
|
||
|
||
Currently DNS OpCodes are assigned as follows:
|
||
|
||
OpCode Name Reference
|
||
|
||
0 Query [RFC 1035]
|
||
1 IQuery (Inverse Query, Obsolete) [RFC 3425]
|
||
2 Status [RFC 1035]
|
||
3 available for assignment
|
||
4 Notify [RFC 1996]
|
||
5 Update [RFC 2136]
|
||
6-15 available for assignment
|
||
|
||
New OpCode assignments require an IETF Standards Action as modified
|
||
by [RFC 4020].
|
||
|
||
|
||
|
||
|
||
|
||
|
||
D. Eastlake 3rd [Page 4]
|
||
|
||
|
||
INTERNET-DRAFT DNS IANA Considerations August 2005
|
||
|
||
|
||
2.3 RCODE Assignment
|
||
|
||
It would appear from the DNS header above that only four bits of
|
||
RCODE, or response/error code are available. However, RCODEs can
|
||
appear not only at the top level of a DNS response but also inside
|
||
OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
|
||
The OPT RR provides an eight bit extension resulting in a 12 bit
|
||
RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
|
||
|
||
Error codes appearing in the DNS header and in these three RR types
|
||
all refer to the same error code space with the single exception of
|
||
error code 16 which has a different meaning in the OPT RR from its
|
||
meaning in other contexts. See table below.
|
||
|
||
RCODE Name Description Reference
|
||
Decimal
|
||
Hexadecimal
|
||
0 NoError No Error [RFC 1035]
|
||
1 FormErr Format Error [RFC 1035]
|
||
2 ServFail Server Failure [RFC 1035]
|
||
3 NXDomain Non-Existent Domain [RFC 1035]
|
||
4 NotImp Not Implemented [RFC 1035]
|
||
5 Refused Query Refused [RFC 1035]
|
||
6 YXDomain Name Exists when it should not [RFC 2136]
|
||
7 YXRRSet RR Set Exists when it should not [RFC 2136]
|
||
8 NXRRSet RR Set that should exist does not [RFC 2136]
|
||
9 NotAuth Server Not Authoritative for zone [RFC 2136]
|
||
10 NotZone Name not contained in zone [RFC 2136]
|
||
11 - 15 Available for assignment
|
||
16 BADVERS Bad OPT Version [RFC 2671]
|
||
16 BADSIG TSIG Signature Failure [RFC 2845]
|
||
17 BADKEY Key not recognized [RFC 2845]
|
||
18 BADTIME Signature out of time window [RFC 2845]
|
||
19 BADMODE Bad TKEY Mode [RPC 2930]
|
||
20 BADNAME Duplicate key name [RPF 2930]
|
||
21 BADALG Algorithm not supported [RPF 2930]
|
||
|
||
22 - 3,840
|
||
0x0016 - 0x0F00 Available for assignment
|
||
|
||
3,841 - 4,095
|
||
0x0F01 - 0x0FFF Private Use
|
||
|
||
4,096 - 65,534
|
||
0x1000 - 0xFFFE Available for assignment
|
||
|
||
65,535
|
||
0xFFFF Reserved, can only be allocated by an IETF
|
||
Standards Action.
|
||
|
||
|
||
|
||
D. Eastlake 3rd [Page 5]
|
||
|
||
|
||
INTERNET-DRAFT DNS IANA Considerations August 2005
|
||
|
||
|
||
Since it is important that RCODEs be understood for interoperability,
|
||
assignment of new RCODE listed above as "available for assignment"
|
||
requires an IETF Consensus.
|
||
|
||
|
||
|
||
3. DNS Resource Records
|
||
|
||
All RRs have the same top level format shown in the figure below
|
||
taken from [RFC 1035]:
|
||
|
||
1 1 1 1 1 1
|
||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||
| |
|
||
/ /
|
||
/ NAME /
|
||
| |
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||
| TYPE |
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||
| CLASS |
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||
| TTL |
|
||
| |
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||
| RDLENGTH |
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
|
||
/ RDATA /
|
||
/ /
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||
|
||
NAME is an owner name, i.e., the name of the node to which this
|
||
resource record pertains. NAMEs are specific to a CLASS as described
|
||
in section 3.2. NAMEs consist of an ordered sequence of one or more
|
||
labels each of which has a label type [RFC 1035, 2671].
|
||
|
||
TYPE is a two octet unsigned integer containing one of the RR TYPE
|
||
codes. See section 3.1.
|
||
|
||
CLASS is a two octet unsigned integer containing one of the RR CLASS
|
||
codes. See section 3.2.
|
||
|
||
TTL is a four octet (32 bit) bit unsigned integer that specifies the
|
||
number of seconds that the resource record may be cached before the
|
||
source of the information should again be consulted. Zero is
|
||
interpreted to mean that the RR can only be used for the transaction
|
||
in progress.
|
||
|
||
RDLENGTH is an unsigned 16 bit integer that specifies the length in
|
||
|
||
|
||
D. Eastlake 3rd [Page 6]
|
||
|
||
|
||
INTERNET-DRAFT DNS IANA Considerations August 2005
|
||
|
||
|
||
octets of the RDATA field.
|
||
|
||
RDATA is a variable length string of octets that constitutes the
|
||
resource. The format of this information varies according to the TYPE
|
||
and in some cases the CLASS of the resource record.
|
||
|
||
|
||
|
||
3.1 RR TYPE IANA Considerations
|
||
|
||
There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
|
||
and MetaTYPEs.
|
||
|
||
Data TYPEs are the primary means of storing data. QTYPES can only be
|
||
used in queries. Meta-TYPEs designate transient data associated with
|
||
an particular DNS message and in some cases can also be used in
|
||
queries. Thus far, data TYPEs have been assigned from 1 upwards plus
|
||
the block from 100 through 103 while Q and Meta Types have been
|
||
assigned from 255 downwards except for the OPT Meta-RR which is
|
||
assigned TYPE 41. There have been DNS implementations which made
|
||
caching decisions based on the top bit of the bottom byte of the RR
|
||
TYPE.
|
||
|
||
There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
|
||
[RFC 2845], and TKEY [RFC 2930].
|
||
|
||
There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
|
||
AXFR, and IXFR.
|
||
|
||
Considerations for the allocation of new RR TYPEs are as follows:
|
||
|
||
Decimal
|
||
Hexadecimal
|
||
|
||
0
|
||
0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
|
||
2535] and in other circumstances and must never be allocated
|
||
for ordinary use.
|
||
|
||
1 - 127
|
||
0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
|
||
TYPEs by the DNS TYPE Allocation Policy as specified in
|
||
section 3.1.1.
|
||
|
||
128 - 255
|
||
0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
|
||
Meta TYPEs by the DNS TYPE Allocation Policy as specified in
|
||
section 3.1.1.
|
||
|
||
|
||
|
||
|
||
D. Eastlake 3rd [Page 7]
|
||
|
||
|
||
INTERNET-DRAFT DNS IANA Considerations August 2005
|
||
|
||
|
||
256 - 32,767
|
||
0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS
|
||
TYPE Allocation Policy as specified in section 3.1.1.
|
||
|
||
32,768 - 65,279
|
||
0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
|
||
|
||
65,280 - 65534
|
||
0xFF00 - 0xFFFE - Private Use.
|
||
|
||
65,535
|
||
0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
|
||
|
||
|
||
|
||
3.1.1 DNS TYPE Allocation Policy
|
||
|
||
Parameter values specified above as assigned based on DNS TYPE
|
||
Allocation Policy. That is, Expert Review with the additional
|
||
requirement that the review be based on a complete template as
|
||
specified below which has been posted for three weeks to the
|
||
namedroppers@ops.ietf.org mailing list.
|
||
|
||
Partial or draft templates may be posted with the intend of
|
||
soliciting feedback.
|
||
|
||
|
||
DNS RR TYPE PARAMETER ALLOCATION TEMPLATE
|
||
|
||
Date:
|
||
|
||
Name and email of originator:
|
||
|
||
Pointer to internet-draft or other document giving a detailed
|
||
description of the protocol use of the new RR Type:
|
||
|
||
What need is the new RR TYPE intended to fix?
|
||
|
||
What existing RR TYPE(s) come closest to filling that need and why are
|
||
they unsatisfactory?
|
||
|
||
Does the proposed RR TYPR require special handling within the DNS
|
||
different from an Unknown RR TYPE?
|
||
|
||
Comments:
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
D. Eastlake 3rd [Page 8]
|
||
|
||
|
||
INTERNET-DRAFT DNS IANA Considerations August 2005
|
||
|
||
|
||
3.1.2 Special Note on the OPT RR
|
||
|
||
The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its
|
||
primary purpose is to extend the effective field size of various DNS
|
||
fields including RCODE, label type, OpCode, flag bits, and RDATA
|
||
size. In particular, for resolvers and servers that recognize it, it
|
||
extends the RCODE field from 4 to 12 bits.
|
||
|
||
|
||
|
||
3.1.3 The AFSDB RR Subtype Field
|
||
|
||
The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same
|
||
RDATA field structure as the MX RR but the 16 bit unsigned integer
|
||
field at the beginning of the RDATA is interpreted as a subtype as
|
||
follows:
|
||
|
||
Decimal
|
||
Hexadecimal
|
||
|
||
0
|
||
0x0000 - Allocation requires IETF Standards Action.
|
||
|
||
1
|
||
0x0001 - Andrews File Service v3.0 Location Service [RFC 1183].
|
||
|
||
2
|
||
0x0002 - DCE/NCA root cell directory node [RFC 1183].
|
||
|
||
3 - 65,279
|
||
0x0003 - 0xFEFF - Allocation by IETF Consensus.
|
||
|
||
65,280 - 65,534
|
||
0xFF00 - 0xFFFE - Private Use.
|
||
|
||
65,535
|
||
0xFFFF - Reserved, allocation requires IETF Standards Action.
|
||
|
||
|
||
|
||
3.2 RR CLASS IANA Considerations
|
||
|
||
DNS CLASSes have been little used but constitute another dimension of
|
||
the DNS distributed database. In particular, there is no necessary
|
||
relationship between the name space or root servers for one CLASS and
|
||
those for another CLASS. The same name can have completely different
|
||
meanings in different CLASSes; however, the label types are the same
|
||
and the null label is usable only as root in every CLASS. However,
|
||
as global networking and DNS have evolved, the IN, or Internet, CLASS
|
||
has dominated DNS use.
|
||
|
||
|
||
D. Eastlake 3rd [Page 9]
|
||
|
||
|
||
INTERNET-DRAFT DNS IANA Considerations August 2005
|
||
|
||
|
||
There are two subcategories of DNS CLASSes: normal data containing
|
||
classes and QCLASSes that are only meaningful in queries or updates.
|
||
|
||
The current CLASS assignments and considerations for future
|
||
assignments are as follows:
|
||
|
||
Decimal
|
||
Hexadecimal
|
||
|
||
0
|
||
0x0000 - Reserved, assignment requires an IETF Standards Action.
|
||
|
||
1
|
||
0x0001 - Internet (IN).
|
||
|
||
2
|
||
0x0002 - Available for assignment by IETF Consensus as a data CLASS.
|
||
|
||
3
|
||
0x0003 - Chaos (CH) [Moon 1981].
|
||
|
||
4
|
||
0x0004 - Hesiod (HS) [Dyer 1987].
|
||
|
||
5 - 127
|
||
0x0005 - 0x007F - available for assignment by IETF Consensus for data
|
||
CLASSes only.
|
||
|
||
128 - 253
|
||
0x0080 - 0x00FD - available for assignment by IETF Consensus for
|
||
QCLASSes only.
|
||
|
||
254
|
||
0x00FE - QCLASS None [RFC 2136].
|
||
|
||
255
|
||
0x00FF - QCLASS Any [RFC 1035].
|
||
|
||
256 - 32,767
|
||
0x0100 - 0x7FFF - Assigned by IETF Consensus.
|
||
|
||
32,768 - 65,279
|
||
0x8000 - 0xFEFF - Assigned based on Specification Required as defined
|
||
in [RFC 2434].
|
||
|
||
65,280 - 65,534
|
||
0xFF00 - 0xFFFE - Private Use.
|
||
|
||
65,535
|
||
0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
|
||
|
||
|
||
D. Eastlake 3rd [Page 10]
|
||
|
||
|
||
INTERNET-DRAFT DNS IANA Considerations August 2005
|
||
|
||
|
||
3.3 RR NAME Considerations
|
||
|
||
DNS NAMEs are sequences of labels [RFC 1035]. The last label in each
|
||
NAME is "ROOT" which is the zero length label. By definition, the
|
||
null or ROOT label can not be used for any other NAME purpose.
|
||
|
||
At the present time, there are two categories of label types, data
|
||
labels and compression labels. Compression labels are pointers to
|
||
data labels elsewhere within an RR or DNS message and are intended to
|
||
shorten the wire encoding of NAMEs. The two existing data label
|
||
types are sometimes referred to as Text and Binary. Text labels can,
|
||
in fact, include any octet value including zero value octets but most
|
||
current uses involve only [US-ASCII]. For retrieval, Text labels are
|
||
defined to treat ASCII upper and lower case letter codes as matching
|
||
[insensitive]. Binary labels are bit sequences [RFC 2673]. The
|
||
Binary label type is Experimental [RFC 3363].
|
||
|
||
IANA considerations for label types are given in [RFC 2671].
|
||
|
||
NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon
|
||
1981] CLASSes are essentially for local use. The IN or Internet
|
||
CLASS is thus the only DNS CLASS in global use on the Internet at
|
||
this time.
|
||
|
||
A somewhat out-of-date description of name allocation in the IN Class
|
||
is given in [RFC 1591]. Some information on reserved top level
|
||
domain names is in BCP 32 [RFC 2606].
|
||
|
||
|
||
|
||
4. Security Considerations
|
||
|
||
This document addresses IANA considerations in the allocation of
|
||
general DNS parameters, not security. See [RFC 4033, 4034, 4035] for
|
||
secure DNS considerations.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
D. Eastlake 3rd [Page 11]
|
||
|
||
|
||
INTERNET-DRAFT DNS IANA Considerations August 2005
|
||
|
||
|
||
Appendix: Changes from RFC 2929
|
||
|
||
RFC Editor: This Appendix should be deleted for publication.
|
||
|
||
Changes from RFC 2929 to this draft:
|
||
|
||
1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE
|
||
Allocation Policy" and add the specification of that policy. Change
|
||
some remaining "IETF Standards Action" allocation requirements to say
|
||
"as modified by [RFC 4020]".
|
||
|
||
2. Updated various RFC references.
|
||
|
||
3. Mentioned that the Binary label type is now Experimental and
|
||
IQuery is Obsolete.
|
||
|
||
4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be
|
||
IETF Standards Action required.
|
||
|
||
5. Add an IANA allocation policy for the AFSDB RR Subtype field.
|
||
|
||
6. Addition of reference to case insensitive draft.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
D. Eastlake 3rd [Page 12]
|
||
|
||
|
||
INTERNET-DRAFT DNS IANA Considerations August 2005
|
||
|
||
|
||
Copyright and Disclaimer
|
||
|
||
Copyright (C) The Internet Society (2005). This document is subject to
|
||
the rights, licenses and restrictions contained in BCP 78, and except
|
||
as set forth therein, the authors retain all their rights.
|
||
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
|
||
|
||
Normative References
|
||
|
||
[RFC 1034] - Mockapetris, P., "Domain Names - Concepts and
|
||
Facilities", STD 13, RFC 1034, November 1987.
|
||
|
||
[RFC 1035] - Mockapetris, P., "Domain Names - Implementation and
|
||
Specifications", STD 13, RFC 1035, November 1987.
|
||
|
||
[RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
|
||
Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
|
||
|
||
[RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone
|
||
Changes (DNS NOTIFY)", RFC 1996, August 1996.
|
||
|
||
[RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
|
||
"Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
|
||
April 1997.
|
||
|
||
[RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS
|
||
Specification", RFC 2181, July 1997.
|
||
|
||
[RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
|
||
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
|
||
|
||
[RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
|
||
2671, August 1999.
|
||
|
||
[RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System",
|
||
RFC 2673, August 1999.
|
||
|
||
[RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B.
|
||
Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
|
||
RFC 2845, May 2000.
|
||
|
||
|
||
D. Eastlake 3rd [Page 13]
|
||
|
||
|
||
INTERNET-DRAFT DNS IANA Considerations August 2005
|
||
|
||
|
||
[RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY
|
||
RR)", September 2000.
|
||
|
||
[RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
|
||
Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
|
||
the Domain Name System (DNS)", RFC 3363, August 2002.
|
||
|
||
[RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
|
||
2002.
|
||
|
||
[RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
|
||
Standards Track Code Points", BCP 100, RFC 4020, February 2005.
|
||
|
||
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
|
||
2005.
|
||
|
||
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
|
||
March 2005.
|
||
|
||
[RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
|
||
4035, March 2005.
|
||
|
||
[US-ASCII] - ANSI, "USA Standard Code for Information Interchange",
|
||
X3.4, American National Standards Institute: New York, 1968.
|
||
|
||
|
||
|
||
Informative References
|
||
|
||
[Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena
|
||
Technical Plan - Name Service, April 1987,
|
||
|
||
[Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
|
||
Institute of Technology Artificial Intelligence Laboratory, June
|
||
1981.
|
||
|
||
[RFC 1591] - Postel, J., "Domain Name System Structure and
|
||
Delegation", RFC 1591, March 1994.
|
||
|
||
[RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
|
||
"Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
|
||
September 2000.
|
||
|
||
[RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS
|
||
Names", RFC 2606, June 1999.
|
||
|
||
[insensitive] - Eastlake, D., "Domain Name System (DNS) Case
|
||
|
||
|
||
D. Eastlake 3rd [Page 14]
|
||
|
||
|
||
INTERNET-DRAFT DNS IANA Considerations August 2005
|
||
|
||
|
||
Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt,
|
||
work in progress.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
D. Eastlake 3rd [Page 15]
|
||
|
||
|
||
INTERNET-DRAFT DNS IANA Considerations August 2005
|
||
|
||
|
||
Authors Addresses
|
||
|
||
Donald E. Eastlake 3rd
|
||
Motorola Laboratories
|
||
155 Beaver Street
|
||
Milford, MA 01757 USA
|
||
|
||
Telephone: +1-508-786-7554 (w)
|
||
email: Donald.Eastlake@motorola.com
|
||
|
||
|
||
|
||
Expiration and File Name
|
||
|
||
This draft expires February 2006.
|
||
|
||
Its file name is draft-ietf-dnsext-2929bis-01.txt.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
D. Eastlake 3rd [Page 16]
|
||
|