draft-ietf-dnsext-iana-dns-00.txt   rfc2929.txt 
INTERNET-DRAFT Donald E. Eastlake 3rd Network Working Group D. Eastlake, 3rd
Eric Brunner Request for Comments: 2929 Motorola
Bill Manning BCP: 42 E. Brunner-Williams
Expires: June 2000 February 2000 Category: Best Current Practice Engage
B. Manning
ISI
September 2000
Domain Name System (DNS) IANA Considerations Domain Name System (DNS) IANA Considerations
------ ---- ------ ----- ---- --------------
Status of This Document
Distribution of this draft <draft-ietf-dnsext-iana-dns-00.txt>, which Status of this Memo
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 This document specifies an Internet Best Current Practices for the
months. Internet-Drafts may be updated, replaced, or obsoleted by Internet Community, and requests discussion and suggestions for
other documents at any time. It is not appropriate to use Internet- improvements. Distribution of this memo is unlimited.
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 Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2000). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
Internet Assigned Number Authority (IANA) parameter assignment Internet Assigned Number Authority (IANA) parameter assignment
considerations are given for the allocation of Domain Name System considerations are given for the allocation of Domain Name System
(DNS) classes, RR types, operation codes, error codes, etc. (DNS) classes, Resource Record (RR) types, operation codes, error
codes, etc.
Table of Contents Table of Contents
Status of This Document....................................1 1. Introduction................................................. 2
Abstract...................................................1 2. DNS Query/Response Headers................................... 2
2.1 One Spare Bit?.............................................. 3
Table of Contents..........................................2 2.2 Opcode Assignment........................................... 3
2.3 RCODE Assignment............................................ 4
1. Introduction............................................3 3. DNS Resource Records......................................... 5
2. DNS Query/Response Headers..............................3 3.1 RR TYPE IANA Considerations................................. 6
2.1 One Spare Bit?.........................................4 3.1.1 Special Note on the OPT RR................................ 7
2.2 Opcode Assignment......................................4 3.2 RR CLASS IANA Considerations................................ 7
2.3 RCODE Assignment.......................................5 3.3 RR NAME Considerations...................................... 8
3. DNS Resource Records....................................5 4. Security Considerations...................................... 9
3.1 RR TYPE IANA Considerations............................7 References...................................................... 9
3.1.1 Special Note on the OPT RR...........................8 Authors' Addresses.............................................. 11
3.2 RR CLASS IANA Considerations...........................8 Full Copyright Statement........................................ 12
3.3 RR NAME Considerations.................................9
4. Designated Expert......................................10
5. Security Considerations................................10
References................................................10
Authors Addresses.........................................12
Expiration and File Name..................................12
1. Introduction 1. Introduction
The Domain Name System (DNS) provides replicated distributed secure The Domain Name System (DNS) provides replicated distributed secure
hierarchical databases which hierarchically store "resource records" hierarchical databases which hierarchically store "resource records"
(RRs) under domain names. (RRs) under domain names.
This data is structured into CLASSes and zones which can be This data is structured into CLASSes and zones which can be
independently maintained. See [RFC 1034, 1035, 2136, 2181, 2535] independently maintained. See [RFC 1034, 1035, 2136, 2181, 2535]
familiarity with which is assumed. familiarity with which is assumed.
This document covers, either directly or by reference, general IANA This document covers, either directly or by reference, general IANA
parameter assignment considerations applying across DNS query and parameter assignment considerations applying across DNS query and
response headers and all RRs. There may be additional IANA response headers and all RRs. There may be additional IANA
considerations that apply to only a particular RR type or 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. See the specific RFC defining that RR type or
query/response opcode for such considerations if they have been query/response opcode for such considerations if they have been
defined. defined.
IANA currently maintains a web page of DNS parameters at IANA currently maintains a web page of DNS parameters. See
<http://www.isi.edu/in-notes/iana/assignments/dns-parameters>. <http://www.iana.org/numbers.htm>.
"IETF Standards Action", "IETF Consensus", "Specification Required", "IETF Standards Action", "IETF Consensus", "Specification Required",
and "Private Use" are as defined in [RFC 2434]. and "Private Use" are as defined in [RFC 2434].
2. DNS Query/Response Headers 2. DNS Query/Response Headers
The header for DNS queries and responses contains field/bits in the The header for DNS queries and responses contains field/bits in the
following diagram taken from [RFC 2136, 2535]: following diagram taken from [RFC 2136, 2535]:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID | | ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT | | QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT | | ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT | | NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT | | ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The ID field identifies the query and is echoed in the response so The ID field identifies the query and is echoed in the response so
they can be matched. they can be matched.
The QR bit indicates whether the header is for a query or a response. The QR bit indicates whether the header is for a query or a response.
The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
only in queries or only in responses, depending on the bit. However, only in queries or only in responses, depending on the bit. However,
many DNS implementations copy the query header as the initial value many DNS implementations copy the query header as the initial value
of the response header without clearing bits. Thus any attempt to of the response header without clearing bits. Thus any attempt to
skipping to change at page 4, line 39 skipping to change at page 3, line 39
implementations ignore this bit. implementations ignore this bit.
Assigning a meaning to the Z bit requires an IETF Standards Action. Assigning a meaning to the Z bit requires an IETF Standards Action.
2.2 Opcode Assignment 2.2 Opcode Assignment
New OpCode assignments require an IETF Standards Action. New OpCode assignments require an IETF Standards Action.
Currently DNS OpCodes are assigned as follows: Currently DNS OpCodes are assigned as follows:
OpCode Name Reference OpCode Name Reference
0 Query [RFC 1035] 0 Query [RFC 1035]
1 IQuery (Inverse Query) [RFC 1035] 1 IQuery (Inverse Query) [RFC 1035]
2 Status [RFC 1035] 2 Status [RFC 1035]
3 available for assignment 3 available for assignment
4 Notify [RFC 1996] 4 Notify [RFC 1996]
5 Update [RFC 2136] 5 Update [RFC 2136]
6-15 available for assignment 6-15 available for assignment
2.3 RCODE Assignment 2.3 RCODE Assignment
It would appear from the DNS header above that only four bits of It would appear from the DNS header above that only four bits of
RCODE, or response/error code are available. However, RCODEs can RCODE, or response/error code are available. However, RCODEs can
appear not only at the top level of a DNS response but also inside appear not only at the top level of a DNS response but also inside
TSIG RRs [RFC XXX3] and OPT RRs [RFC 2671]. The OPT RR provides an OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
eight bit extension resulting in a 12 bit RCODE field and the TSIG RR The OPT RR provides an eight bit extension resulting in a 12 bit
has a 16 bit RCODE field. RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
RCODE Name Description Reference Error codes appearing in the DNS header and in these three RR types
Decimal all refer to the same error code space with the single exception of
Hexadecimal error code 16 which has a different meaning in the OPT RR from its
0 NoError No Error [RFC 1035] meaning in other contexts. See table below.
1 FormErr Format Error [RFC 1035]
2 ServFail Server Failure [RFC 1035] RCODE Name Description Reference
3 NXDomain Non-Existent Domain [RFC 1035] Decimal
4 NotImp Not Implemented [RFC 1035] Hexadecimal
5 Refused Query Refused [RFC 1035] 0 NoError No Error [RFC 1035]
6 YXDomain Name Exists when it should not [RFC 2136] 1 FormErr Format Error [RFC 1035]
7 YXRRSet RR Set Exists when it should not [RFC 2136] 2 ServFail Server Failure [RFC 1035]
8 NXRRSet RR Set that should exist does not [RFC 2136] 3 NXDomain Non-Existent Domain [RFC 1035]
9 NotAuth Server Not Authoritative for zone [RFC 2136] 4 NotImp Not Implemented [RFC 1035]
10 NotZone Name not contained in zone [RFC 2136] 5 Refused Query Refused [RFC 1035]
11-15 available for assignment 6 YXDomain Name Exists when it should not [RFC 2136]
16 BADVERS Bad OPT Version [RFC 2671] 7 YXRRSet RR Set Exists when it should not [RFC 2136]
16 BADSIG TSIG Signature Failure [RFC XXX3] 8 NXRRSet RR Set that should exist does not [RFC 2136]
17 BADKEY Key not recognized [RFC XXX3] 9 NotAuth Server Not Authoritative for zone [RFC 2136]
18 BADTIME Signature out of time window [RFC XXX3] 10 NotZone Name not contained in zone [RFC 2136]
19-3840 available for assignment 11-15 available for assignment
0x0013-0x0F00 16 BADVERS Bad OPT Version [RFC 2671]
3841-4095 Private Use 16 BADSIG TSIG Signature Failure [RFC 2845]
0x0F01-0x0FFF 17 BADKEY Key not recognized [RFC 2845]
4096-65535 available for assignment 18 BADTIME Signature out of time window [RFC 2845]
0x1000-0xFFFF 19 BADMODE Bad TKEY Mode [RFC 2930]
20 BADNAME Duplicate key name [RFC 2930]
21 BADALG Algorithm not supported [RFC 2930]
22-3840 available for assignment
0x0016-0x0F00
3841-4095 Private Use
0x0F01-0x0FFF
4096-65535 available for assignment
0x1000-0xFFFF
Since it is important that RCODEs be understood for interoperability, Since it is important that RCODEs be understood for interoperability,
assignment of new RCODE listed above as "available for assignment" assignment of new RCODE listed above as "available for assignment"
requires an IETF Consensus. requires an IETF Consensus.
3. DNS Resource Records 3. DNS Resource Records
All RRs have the same top level format shown in the figure below All RRs have the same top level format shown in the figure below
taken from [RFC 1035]: taken from [RFC 1035]:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | | |
/ / / /
/ NAME / / NAME /
| | | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE | | TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS | | CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL | | TTL |
| | | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH | | RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA / / RDATA /
/ / / /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NAME is an owner name, i.e., the name of the node to which this 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 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 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]. labels each of which has a label type [RFC 1035, 2671].
TYPE is a two octet unsigned integer containing one of the RR TYPE TYPE is a two octet unsigned integer containing one of the RR TYPE
codes. See section 3.1. codes. See section 3.1.
CLASS is a two octet unsigned integer containing one of the RR CLASS CLASS is a two octet unsigned integer containing one of the RR CLASS
skipping to change at page 7, line 21 skipping to change at page 6, line 25
used in queries. Meta-TYPEs designate transient data associated with used in queries. Meta-TYPEs designate transient data associated with
an particular DNS message and in some cases can also be used in 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 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 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 from 255 downwards (except for the OPT Meta-RR which is
assigned TYPE 41). There have been DNS implementations which made assigned TYPE 41). There have been DNS implementations which made
caching decisions based on the top bit of the bottom byte of the RR caching decisions based on the top bit of the bottom byte of the RR
TYPE. TYPE.
There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
[RFC XXX3], and TKEY [work in progress]. [RFC 2845], and TKEY [RFC 2930].
There are currently five QTYPEs assigned: * (all), MAILA, MAILB, There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
AXFR, and IXFR. AXFR, and IXFR.
Considerations for the allocation of new RR TYPEs are as follows: Considerations for the allocation of new RR TYPEs are as follows:
Decimal Decimal
Hexadecimal Hexadecimal
0 0
skipping to change at page 8, line 9 skipping to change at page 7, line 15
32768 - 65279 32768 - 65279
0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434]. 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
65280 - 65535 65280 - 65535
0xFF00 - 0xFFFF - Private Use. 0xFF00 - 0xFFFF - Private Use.
3.1.1 Special Note on the OPT RR 3.1.1 Special Note on the OPT RR
The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its
primary purpose is to extend the effective field size of various DNS primary purpose is to extend the effective field size of various DNS
fields including RCODE, label type, OpCode, flag bits, and RDATA fields including RCODE, label type, flag bits, and RDATA size. In
size. In particular, for resolvers and servers that recognize it, it particular, for resolvers and servers that recognize it, it extends
extends the RCODE field from 4 to 12 bits. the RCODE field from 4 to 12 bits.
3.2 RR CLASS IANA Considerations 3.2 RR CLASS IANA Considerations
DNS CLASSes have been little used but constitute another dimension of DNS CLASSes have been little used but constitute another dimension of
the DNS distributed database. In particular, there is no necessary the DNS distributed database. In particular, there is no necessary
relationship between the name space or root servers for one CLASS and relationship between the name space or root servers for one CLASS and
those for another CLASS. The same name can have completely different those for another CLASS. The same name can have completely different
meanings in different CLASSes although the label types are the same meanings in different CLASSes although the label types are the same
and the null label is usable only as root in every CLASS. However, 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 as global networking and DNS have evolved, the IN, or Internet, CLASS
skipping to change at page 8, line 43 skipping to change at page 7, line 49
0 0
0x0000 - assignment requires an IETF Standards Action. 0x0000 - assignment requires an IETF Standards Action.
1 1
0x0001 - Internet (IN). 0x0001 - Internet (IN).
2 2
0x0002 - available for assignment by IETF Consensus as a data CLASS. 0x0002 - available for assignment by IETF Consensus as a data CLASS.
3 3
0x0003 - Chaos (CH) [Moon 81]. 0x0003 - Chaos (CH) [Moon 1981].
4 4
0x0004 - Hesiod (HS) [Dyer 87]. 0x0004 - Hesiod (HS) [Dyer 1987].
5 - 127 5 - 127
0x0005 - 0x007F - available for assignment by IETF Consensus as data 0x0005 - 0x007F - available for assignment by IETF Consensus as data
CLASSes only. CLASSes only.
128 - 253 128 - 253
0x0080 - 0x00FD - available for assignment by IETF Consensus as 0x0080 - 0x00FD - available for assignment by IETF Consensus as
QCLASSes only. QCLASSes only.
254 254
skipping to change at page 9, line 38 skipping to change at page 8, line 42
3.3 RR NAME Considerations 3.3 RR NAME Considerations
DNS NAMEs are sequences of labels [RFC 1035]. The last label in each 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 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. 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 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. The two existing data label shorten the wire encoding of NAMEs. The two existing data label
types are frequently referred to as ASCII and Binary. ASCII labels types are sometimes referred to as Text and Binary. Text labels can,
can, in fact, include any octet value including zero octets but most in fact, include any octet value including zero octets but most
current uses involve only [US-ASCII] For retrieval ASCII labels are current uses involve only [US-ASCII]. For retrieval, Text labels are
defined to treat upper and lower case letters the same. Binary defined to treat ASCII upper and lower case letter codes as matching.
labels are bit sequences [RFC 2673]. Binary labels are bit sequences [RFC 2673].
IANA considerations for label types are given in [RFC 2671]. IANA considerations for label types are given in [RFC 2671].
NAMEs are local to a CLASS. The Hesiod [Dyer 87] and Chaos [Moon 81] NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon
CLASSes are essentially for local use. The IN or Internet CLASS is 1981] CLASSes are essentially for local use. The IN or Internet
thus the only DNS CLASS in global use on the Internet at this time. 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 A somewhat dated description of name allocation in the IN Class is
given in [RFC 1591]. Some information on reserved top level domain given in [RFC 1591]. Some information on reserved top level domain
names is in Best Current Practice 32 [RFC 2606]. names is in Best Current Practice 32 [RFC 2606].
4. Designated Expert 4. Security Considerations
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 This document addresses IANA considerations in the allocation of
general DNS parameters, not security. See [RFC 2535] for secure DNS general DNS parameters, not security. See [RFC 2535] for secure DNS
considerations. considerations.
References References
[Dyer 87] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical [Dyer 1987] Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
Plan - Name Service, April 1987, Plan - Name Service, April 1987,
[Moon 81] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts [Moon 1981] D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
Institute of Technology Artificial Intelligence Laboratory, June Institute of Technology Artificial Intelligence
1981. Laboratory, June 1981.
[RFC 1034] - P. Mockapetris, "Domain Names - Concepts and [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, November 1987. Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] - P. Mockapetris, "Domain Names - Implementation and [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, November 1987. Specifications", STD 13, RFC 1035, November 1987.
[RFC 1591] - J. Postel, "Domain Name System Structure and [RFC 1591] Postel, J., "Domain Name System Structure and
Delegation", March 1994. Delegation", RFC 1591, March 1994.
[RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone [RFC 1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", August 1996. Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS [RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", July 1997. Specification", RFC 2181, July 1997.
[RFC 2434] - "Guidelines for Writing an IANA Considerations Section [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
in RFCs", T. Narten, H. Alvestrand, October 1998. IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
March 1999. RFC 2535, March 1999.
[RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", [RFC 2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
June 1999. Names", RFC 2606, June 1999.
[RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August [RFC 2671] Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
1999. 2671, August 1999.
[RFC 2672] - M. Crawford, " Non-Terminal DNS Name Redirection", [RFC 2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
August 1999. 2672, August 1999.
[RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", [RFC 2673] Crawford, M., "Binary Labels in the Domain Name System",
August 1999. RFC 2673, August 1999.
[RFC XXX3] - P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
"Secret Key Transaction Signatures for DNS (TSIG)", xxx 2000 (draft- Wellington, "Secret Key Transaction Authentication for
ietf-dnsind-tsig-*.txt). DNS (TSIG)", RFC 2845, May 2000.
[US-ASCII] - ANSI, "USA Standard Code for Information [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
Interchange", X3.4, American National Standards Institute: New York, RR)", RFC 2930, September 2000.
1968.
Authors Addresses [US-ASCII] ANSI, "USA Standard Code for Information Interchange",
X3.4, American National Standards Institute: New York,
1968.
Authors' Addresses
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Motorola Motorola
65 Shindegan Hill Road 140 Forest Avenue
Carmel, NY 10512 USA Hudson, MA 01749 USA
Telephone: +1-914-276-2668 (h) Phone: +1-978-562-2827 (h)
+1-508-261-5434 (w) +1-508-261-5434 (w)
email: dee3@torque.pothole.com Fax: +1-508-261-4447 (w)
EMail: Donald.Eastlake@motorola.com
Eric Brunner Eric Brunner-Williams
1415 Forest Avenue Engage
Portland, ME 04103 USA 100 Brickstone Square, 2nd Floor
Andover, MA 01810
Telephone: +1 207-797-0525 Phone: +1-207-797-0525 (h)
email: brunner@world.std.com +1-978-684-7796 (w)
Fax: +1-978-684-3118
EMail: brunner@engage.com
Bill Manning Bill Manning
USC/ISI USC/ISI
4676 Admiralty Way, #1001 4676 Admiralty Way, #1001
Marina del Rey, CA 90292 USA Marina del Rey, CA 90292 USA
Telephone: +1 310 822 1511 Phone: +1-310-822-1511
email: bmanning@isi.edu EMail: bmanning@isi.edu
Expiration and File Name Full Copyright Statement
This draft expires August 2000. Copyright (C) The Internet Society (2000). All Rights Reserved.
Its file name is draft-ietf-dnsext-iana-dns-00.txt. This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 47 change blocks. 
191 lines changed or deleted 185 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/