ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

pulled up removal of old drafts

Browse Source
This commit is contained in:
Andreas Gustafsson
2000-07-10 04:37:49 +00:00
parent 67c0dcb985
commit 807c0c6103
2 changed files with 0 additions and 1085 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/draft/draft-ietf-dnsext-apl-rr-00.txt
-389
View File
@@ -1,389 +0,0 @@
INTERNET-DRAFT Peter Koch
Expires: September 2000 Universitaet Bielefeld
Updates: RFC 1035 March 2000
A DNS RR Type for Lists of Address Prefixes (APL RR)
draft-ietf-dnsext-apl-rr-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Comments should be sent to the author or the DNSIND WG mailing list
<namedroppers@internic.net>.
Abstract
The Domain Name System is primarily used to translate domain names
into IPv4 addresses using A RRs. Several approaches exist to describe
networks or address ranges. This document specifies a new DNS RR type
"APL" for address prefix lists.
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Domain names herein are for explanatory purposes only and should not
be expected to lead to useful information in real life [RFC2606].
Koch Expires September 2000 [Page 1]
INTERNET-DRAFT DNS APL RR March 2000
2. Background
The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
associate addresses and other internet infrastructure elements with
hierarchically built domain names. Various types of resource records
have been defined, especially those for IPv4 and IPv6 [RFC1886]
addresses. In [RFC1101] a method is described to publish information
about the address space allocated to an organisation. In older BIND
versions, a weak form of controlling access to zone data was
implemented using TXT RRs describing address ranges.
This document specifies a new RR type for address prefix lists.
3. APL RR Type
An APL record has the DNS type of "APL" [draft: not yet applied for]
and a numeric value of [draft:to be assigned]. The APL RR is defined
in the IN class only. APL RRs cause no additional section processing.
4. APL RDATA format
The RDATA section consists of zero or more strings (<apstring>) of
the form
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ADDRESSFAMILY |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| PREFIX | N | AFDLENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/ AFDPART /
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
ADDRESSFAMILY 16 bit unsigned value as assigned by IANA
(see IANA Considerations)
PREFIX 8 bit unsigned binary coded prefix length.
Upper and lower bounds and interpretation of
this value are address family specific.
N negation flag, indicates the presence of the
"!" character in the textual format. It has
the value "1" if the "!" was given, "0" else.
AFDLENGTH length in octets of the following address
family dependent part (7 bit unsigned).
AFDPART address family dependent part. See below.
This document defines the AFDPARTs for address families 1 (IPv4) and
Koch Expires September 2000 [Page 2]
INTERNET-DRAFT DNS APL RR March 2000
2 (IPv6). Future revisions may deal with additional address
families.
4.1. AFDPART for IPv4
The encoding of an IPv4 address (address family 1) follows the
encoding specified for the A RR by [RFC1035], section 3.4.1. Trailing
zero octets MUST be ignored, regardless of the prefix length.
PREFIX specifies the number of bits of the IPv4 address starting at
the most significant bit. Legal values range from 0 to 32.
An IPv4 AFDPART has a variable length of 0 to 4 octets.
4.2. AFDPART for IPv6
The encoding of an IPv6 address (address family 2) follows the
specification for the AAAA RR in [RFC1886], section 2.2. The 128 bit
address is encoded in network byte order. Trailing zero octets MUST
be ignored, regardless of the prefix length.
PREFIX specifies the number of bits of the IPv6 address starting at
the most significant bit. Legal values range from 0 to 128.
An IPv6 AFDPART has a variable length of 0 to 16 octets.
5. Zone File Syntax
The textual representation of an APL RR in a DNS zone file is as
follows:
<owner> IN <TTL> APL {[!]afi:address/prefix}*
The data consists of zero or more strings of the address family
indicator <afi>, immediately followed by a colon ":", an address,
immediately followed by the "/" character, immediately followed by a
decimal numeric value for the prefix length. Any such string may be
preceeded by a "!" character. The strings are separated by
whitespace. The <afi> is the decimal numeric value of that
particular address family.
5.1. Textual Representation of IPv4 Addresses
An IPv4 address in the <address> part of an <apstring> is in dotted
quad notation, just as in an A RR. The <prefix> has values from the
interval 0..32 (decimal).
5.2. Textual Representation of IPv6 Addresses
Koch Expires September 2000 [Page 3]
INTERNET-DRAFT DNS APL RR March 2000
The representation of an IPv6 address in the <address> part of an
<apstring> follows [RFC2373], section 2.2. Legal values for <prefix>
are from the interval 0..128 (decimal).
6. APL RR usage
An APL RR with empty RDATA is valid and implements an empty list.
Multiple occurences of the same <apstring> in a single APL RR are
allowed and MUST NOT be merged by a DNS server or resolver.
<apstrings> MUST be kept in order and MUST NOT be rearranged or
aggregated.
A single APL RR may contain <apstrings> belonging to different
address families. The maximum number of <apstrings> is upperbounded
by the available RDATA space.
RRSets consisting of more than one APL RR are legal but the
interpretation is left to the particular application.
7. Applicability Statement
The APL RR defines a framework without specifying any particular
meaning for the list of prefixes. It is expected that APL RRs will
be used in different application scenarios which have to be
documented separately. Those scenarios may be distinguished by
characteristic prefixes placed in front of the DNS owner name.
An APL application specification MUST include information on
o the characteristic prefix, if any
o how to interpret APL RRSets consisting of more than one RR
o how to interpret an empty APL RR
o which address families are expected to appear in the APL RRs for
that application
o how to deal with APL RR list elements which belong to other
address families, including those not yet defined
o the exact semantics of list elements negated by the "!" character
Possible applications include the publication of address ranges
similar to [RFC1101], description of zones built following [RFC2317]
and in-band access control to limit general access or zone transfer
(AXFR) availability for zone data held in DNS servers.
Koch Expires September 2000 [Page 4]
INTERNET-DRAFT DNS APL RR March 2000
The specification of particular application scenarios is out of the
scope of this document.
8. Examples
The following examples only illustrate some of the possible usages
outlined in the previous section. None of those applications are
hereby specified nor is it implied that any particular APL RR based
application does exist now or will exist in the future.
; RFC 1101-like announcement of address ranges for foo.example
foo.example APL 1:192.168.32.0/21 !1:192.168.38.0/28
; CIDR blocks covered by classless delegation
42.168.192.IN-ADDR.ARPA APL ( 1:192.168.42.0/26 1:192.168.42.64/26
1:192.168.42.128/25 )
; Zone transfer restriction
_axfr.sbo.example APL 1:127.0.0.1/32 1:172.16.64.0/22
; List of address ranges for multicast
multicast.example APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8
Note that since trailing zeroes are ignored in the first APL RR the
AFDLENGTH of both <apstrings> is three.
9. Security Considerations
Any information obtained from the DNS should be regarded as unsafe
unless techniques specified in [RFC2535] or [TSIGRR] were used. The
definition of a new RR type does not introduce security problems into
the DNS, but usage of information made available by APL RRs may
compromise security. This includes disclosure of network topology
information and in particular the use of APL RRs to construct access
control lists.
10. IANA Considerations
This section is to be interpreted as following [RFC2434].
This document does not define any new namespaces. It uses the 16 bit
identifiers for address families maintained by IANA in
ftp://ftp.iana.org/in-notes/iana/assignments/address-family-numbers.
IANA is asked to assign a numeric RR type value for APL.
11. Acknowledgements
Koch Expires September 2000 [Page 5]
INTERNET-DRAFT DNS APL RR March 2000
The author would like to thank Mark Andrews for his review and
constructive comments.
12. References
[RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities",
RFC 1034, STD 13, November 1987
[RFC1035] Mockapetris,P., "Domain Names - Implementation and
Specification", RFC 1035, STD 13, November 1987
[RFC1101] Mockapetris,P., "DNS Encoding of Network Names and Other
Types", RFC 1101, April 1989
[RFC1886] Thomson,S., Huitema.,C., "DNS Extensions to support IP
version 6", RFC 1886, December 1995
[RFC2119] Bradner,S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997
[RFC2181] Elz,R., Bush,R., "Clarifications to the DNS
Specification", RFC 2181, July 1997
[RFC2317] Eidnes,H., de Groot,G., Vixie,P., "Classless IN-ADDR.ARPA
delegation", RFC 2317, March 1998
[RFC2373] Hinden,R., Deering,S., "IP Version 6 Addressing
Architecture", RFC 2373, July 1998
[RFC2434] Narten,T., Alvestrand,H., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, BCP 26, October
1998
[RFC2535] Eastlake,D., "Domain Name System Security Extensions", RFC
2535, March 1999
[RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names",
RFC 2606, BCP 32, June 1999
[TSIGRR] Vixie,P., Gudmundsson,O., Eastlake,D., Wellington,B.,
"Secret Key Transaction Signatures for DNS (TSIG)",
<draft-ietf-dnsind-tsig-XX.txt>, work in progress
13. Author's Address
Peter Koch
Koch Expires September 2000 [Page 6]
INTERNET-DRAFT DNS APL RR March 2000
Universitaet Bielefeld
Technische Fakultaet
D-33594 Bielefeld
Germany
+49 521 106 2902
<pk@TechFak.Uni-Bielefeld.DE>
Koch Expires September 2000 [Page 7]
doc/draft/draft-ietf-dnsext-iana-dns-00.txt
-696
View File
@@ -1,696 +0,0 @@
INTERNET-DRAFT Donald E. Eastlake 3rd
Eric Brunner
Bill Manning
Expires: June 2000 February 2000
Domain Name System (DNS) IANA Considerations
------ ---- ------ ----- ---- --------------
Status of This Document
Distribution of this draft <draft-ietf-dnsext-iana-dns-00.txt>, which
is intended to become a Best Current Practice, is unlimited. Comments
should be sent to the DNS Working Group mailing list
<namedroppers@internic.net> or to the authors.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
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, etc.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 1]
INTERNET-DRAFT DNS IANA Considerations February 2000
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....................................5
3.1 RR TYPE IANA Considerations............................7
3.1.1 Special Note on the OPT RR...........................8
3.2 RR CLASS IANA Considerations...........................8
3.3 RR NAME Considerations.................................9
4. Designated Expert......................................10
5. Security Considerations................................10
References................................................10
Authors Addresses.........................................12
Expiration and File Name..................................12
D. Eastlake 3rd, E. Brunner, B. Manning [Page 2]
INTERNET-DRAFT DNS IANA Considerations February 2000
1. Introduction
The Domain Name System (DNS) provides replicated distributed secure
hierarchical databases which hierarchically store "resource records"
(RRs) under domain names.
This data is structured into CLASSes and zones which can be
independently maintained. See [RFC 1034, 1035, 2136, 2181, 2535]
familiarity with which is assumed.
This document covers, 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.
IANA currently maintains a web page of DNS parameters at
<http://www.isi.edu/in-notes/iana/assignments/dns-parameters>.
"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, 2535]:
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.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 3]
INTERNET-DRAFT DNS IANA Considerations February 2000
The QR bit indicates whether the header is for a query or a response.
The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
only in queries or only in responses, depending on the bit. However,
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
New OpCode assignments require an IETF Standards Action.
Currently DNS OpCodes are assigned as follows:
OpCode Name Reference
0 Query [RFC 1035]
1 IQuery (Inverse Query) [RFC 1035]
2 Status [RFC 1035]
3 available for assignment
4 Notify [RFC 1996]
5 Update [RFC 2136]
6-15 available for assignment
D. Eastlake 3rd, E. Brunner, B. Manning [Page 4]
INTERNET-DRAFT DNS IANA Considerations February 2000
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
TSIG RRs [RFC XXX3] and OPT RRs [RFC 2671]. The OPT RR provides an
eight bit extension resulting in a 12 bit RCODE field and the TSIG RR
has a 16 bit RCODE field.
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 XXX3]
17 BADKEY Key not recognized [RFC XXX3]
18 BADTIME Signature out of time window [RFC XXX3]
19-3840 available for assignment
0x0013-0x0F00
3841-4095 Private Use
0x0F01-0x0FFF
4096-65535 available for assignment
0x1000-0xFFFF
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]:
D. Eastlake 3rd, E. Brunner, B. Manning [Page 5]
INTERNET-DRAFT DNS IANA Considerations February 2000
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
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.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 6]
INTERNET-DRAFT DNS IANA Considerations February 2000
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 XXX3], and TKEY [work in progress].
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 IETF Consensus.
128 - 255
0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
Meta TYPEs by IETF Consensus.
256 - 32767
0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF
Consensus.
32768 - 65279
0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
65280 - 65535
0xFF00 - 0xFFFF - Private Use.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 7]
INTERNET-DRAFT DNS IANA Considerations February 2000
3.1.1 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.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 although 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.
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 - 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 81].
4
0x0004 - Hesiod (HS) [Dyer 87].
5 - 127
0x0005 - 0x007F - available for assignment by IETF Consensus as data
CLASSes only.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 8]
INTERNET-DRAFT DNS IANA Considerations February 2000
128 - 253
0x0080 - 0x00FD - available for assignment by IETF Consensus as
QCLASSes only.
254
0x00FE - QCLASS None [RFC 2136].
255
0x00FF - QCLASS Any [RFC 1035].
256 - 32767
0x0100 - 0x7FFF - assigned by IETF Consensus.
32768 - 65280
0x8000 - 0xFEFF - assigned based on Specification Required as defined
in [RFC 2434].
65280 - 65534
0xFF00 - 0xFFFE - Private Use.
65535
0xFFFF - can only be assigned by an IETF Standards Action.
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 frequently referred to as ASCII and Binary. ASCII labels
can, in fact, include any octet value including zero octets but most
current uses involve only [US-ASCII] For retrieval ASCII labels are
defined to treat upper and lower case letters the same. Binary
labels are bit sequences [RFC 2673].
IANA considerations for label types are given in [RFC 2671].
NAMEs are local to a CLASS. The Hesiod [Dyer 87] and Chaos [Moon 81]
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 dated description of name allocation in the IN Class is
given in [RFC 1591]. Some information on reserved top level domain
names is in Best Current Practice 32 [RFC 2606].
D. Eastlake 3rd, E. Brunner, B. Manning [Page 9]
INTERNET-DRAFT DNS IANA Considerations February 2000
4. Designated Expert
To provide additional support to IANA in the DNS area, the IESG MAY
appoint a designed expert.
5. Security Considerations
This document addresses IANA considerations in the allocation of
general DNS parameters, not security. See [RFC 2535] for secure DNS
considerations.
References
[Dyer 87] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
Plan - Name Service, April 1987,
[Moon 81] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
Institute of Technology Artificial Intelligence Laboratory, June
1981.
[RFC 1034] - P. Mockapetris, "Domain Names - Concepts and
Facilities", STD 13, November 1987.
[RFC 1035] - P. Mockapetris, "Domain Names - Implementation and
Specifications", STD 13, November 1987.
[RFC 1591] - J. Postel, "Domain Name System Structure and
Delegation", March 1994.
[RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", August 1996.
[RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.
[RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS
Specification", July 1997.
[RFC 2434] - "Guidelines for Writing an IANA Considerations Section
in RFCs", T. Narten, H. Alvestrand, October 1998.
[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
[RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
June 1999.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 10]
INTERNET-DRAFT DNS IANA Considerations February 2000
[RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
1999.
[RFC 2672] - M. Crawford, " Non-Terminal DNS Name Redirection",
August 1999.
[RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
August 1999.
[RFC XXX3] - P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
"Secret Key Transaction Signatures for DNS (TSIG)", xxx 2000 (draft-
ietf-dnsind-tsig-*.txt).
[US-ASCII] - ANSI, "USA Standard Code for Information
Interchange", X3.4, American National Standards Institute: New York,
1968.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 11]
INTERNET-DRAFT DNS IANA Considerations February 2000
Authors Addresses
Donald E. Eastlake 3rd
Motorola
65 Shindegan Hill Road
Carmel, NY 10512 USA
Telephone: +1-914-276-2668 (h)
+1-508-261-5434 (w)
email: dee3@torque.pothole.com
Eric Brunner
1415 Forest Avenue
Portland, ME 04103 USA
Telephone: +1 207-797-0525
email: brunner@world.std.com
Bill Manning
USC/ISI
4676 Admiralty Way, #1001
Marina del Rey, CA 90292 USA
Telephone: +1 310 822 1511
email: bmanning@isi.edu
Expiration and File Name
This draft expires August 2000.
Its file name is draft-ietf-dnsext-iana-dns-00.txt.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 12]