draft-ietf-dnsext-2929bis-04.txt   draft-ietf-dnsext-2929bis-05.txt 
INTERNET-DRAFT Donald E. Eastlake 3rd INTERNET-DRAFT Donald E. Eastlake 3rd
Obsoletes RFC 2929 Motorola Laboratories Obsoletes RFC 2929 Motorola Laboratories
Updates RFCs 1183 and 3597 Updates RFCs 1183 and 3597
Expires: May 2007 November 2006
Domain Name System (DNS) IANA Considerations Domain Name System (DNS) IANA Considerations
------ ---- ------ ----- ------------------- ------ ---- ------ ----- -------------------
<draft-ietf-dnsext-2929bis-04.txt> <draft-ietf-dnsext-2929bis-05.txt>
Status of This Document Status of This Document
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Distribution of this draft is unlimited. It is intended to become Distribution of this draft is unlimited. It is intended to become
the new BCP 42 obsoleting RFC 2929. Comments should be sent to the the new BCP 42 obsoleting RFC 2929. Comments should be sent to the
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents..........................................2 Table of Contents..........................................2
1. Introduction............................................3 1. Introduction............................................3
2. DNS Query/Response Headers..............................3 2. DNS Query/Response Headers..............................3
2.1 One Spare Bit?.........................................4 2.1 One Spare Bit?.........................................4
2.2 Opcode Assignment......................................4 2.2 Opcode Assignment......................................4
2.3 RCODE Assignment.......................................5 2.3 RCODE Assignment.......................................5
3. DNS Resource Records....................................6 3. DNS Resource Records....................................6
3.1 RRTYPE IANA Considerations.............................7 3.1 RRTYPE IANA Considerations.............................7
3.1.1 DNS RRTYPE Allocation Policy.........................8 3.1.1 DNS RRTYPE Allocation Policy.........................8
3.1.2 Expert Review DNS RRTYPE Expert Review Template......8 3.1.2 DNS RRTYPE Expert Guidelines.........................9
3.1.3 DNS RRTYPE Expert Guidelines.........................9 3.1.3 Special Note on the OPT RR...........................9
3.1.4 Special Note on the OPT RR..........................10 3.1.4 The AFSDB RR Subtype Field...........................9
3.1.5 The AFSDB RR Subtype Field..........................10 3.2 RR CLASS IANA Considerations..........................10
3.2 RR CLASS IANA Considerations..........................11
3.3 Label Considerations..................................12 3.3 Label Considerations..................................12
3.3.1 Label Types.........................................12 3.3.1 Label Types.........................................12
3.3.2 Label Contents and Use..............................13 3.3.2 Label Contents and Use..............................12
4. Security Considerations................................13 4. Security Considerations................................12
5. IANA Considerations....................................13 5. IANA Considerations....................................13
Additional IPR Provisions.................................15 Annex A: RRTYPE Allocation Template.......................14
Additional IPR Provisions.................................16
Copyright.................................................16 Copyright.................................................16
Normative References......................................16
Informative References....................................17 Normative References......................................17
Informative References....................................18
Author's Address..........................................19 Author's Address..........................................19
Expiration and File Name..................................19 Expiration and File Name..................................19
Disclaimer................................................19 Disclaimer................................................19
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 store "resource records" (RRs) under hierarchical databases which store "resource records" (RRs) under
domain names. DNS data is structured into CLASSes and zones which domain names. DNS data is structured into CLASSes and zones which
skipping to change at page 7, line 15 skipping to change at page 7, line 15
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.
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 primary means of storing data. QTYPES can only be Data TYPEs are the means of storing data. QTYPES can only be used in
used in queries. Meta-TYPEs designate transient data associated with queries. Meta-TYPEs designate transient data associated with a
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.
queries. Thus far, data TYPEs have been assigned from 1 upwards plus Thus far, data TYPEs have been assigned from 1 upwards plus the block
the block from 100 through 103 and from 32,768 upward, while Q and from 100 through 103 and from 32,768 upward, while Q and Meta-TYPEs
Meta-TYPEs have been assigned from 255 downwards except for the OPT have been assigned from 255 downwards except for the OPT Meta-RR
Meta-RR which is assigned TYPE 41. There have been DNS which is assigned TYPE 41. There have been DNS implementations which
implementations which made caching decisions based on the top bit of made caching decisions based on the top bit of the bottom byte of the
the bottom byte of the RRTYPE. RRTYPE.
There are currently three Meta-TYPEs assigned: OPT [RFC2671], TSIG There are currently three Meta-TYPEs assigned: OPT [RFC2671], 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 which must be completely disjoint from the RRTYPEs have mnemonics which must be completely disjoint from the
mnemonics used for CLASSes and which must match the following regular mnemonics used for CLASSes and which must match the following regular
expression: expression:
[A-Z][A-Z0-9-]* [A-Z][A-Z0-9-]*
Considerations for the allocation of new RRTYPEs are as follows: Considerations for the allocation of new RRTYPEs are as follows:
Decimal Decimal
Hexadecimal Hexadecimal
0 0
0x0000 - RRTYPE zero is used as a special indicator for the SIG RR 0x0000 - RRTYPE zero is used as a special indicator for the SIG RR
[RFC2931], [RFC4034] and in other circumstances and must never [RFC2931], [RFC4034] and in other circumstances and must never
skipping to change at page 8, line 24 skipping to change at page 8, line 28
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 an IETF Standards Action. 0xFFFF - Reserved, can only be assigned by an IETF Standards 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. Some guidelines for the meet the two requirements listed below. There will be a pool of a
Expert are given in Section 3.1.3. RRTYPEs that do not meet these small number of Experts appointed by the IESG. Each application will
requirements, are allocated by IETF Standards Action as modified by be ruled on by an Expert selected by IANA. In any case where the
[RFC4020]. selected Expert is unavailable or states they have a conflict of
interest, IANA may selected another Expert from the pool.
1. A complete template as specified in Section 3.1.2 has been posted Some guidelines for the Experts are given in Section 3.1.2. RRTYPEs
for three weeks to the namedroppers@ops.ietf.org mailing list that do not meet the requirements below, may nonetheless be allocated
before the Expert Review decision. by IETF Standards Action as modified by [RFC4020].
1. A complete template as specified in Annex A has been posted for
three weeks to the namedroppers@ops.ietf.org mailing list before
the Expert Review decision.
Note that partially completed or draft templates may be posted Note that partially completed or draft templates may be posted
for comment. IANA shall maintain a public archive of approved directly by the applicant for comment and discussion but the
templates. formal posting to start the three week period is made by IANA.
2. The RR for which a RRTYPE code is being requested is either (a) a 2. The RR for which a RRTYPE code is being requested is either (a) a
data TYPE which can be handled as an Unknown RR as described in data TYPE which can be handled as an Unknown RR as described in
[RFC3597] or (b) a Meta-Type who processing is optional, i.e., [RFC3597] or (b) a Meta-Type who processing is optional, i.e.,
which it is safe to simply discard. which it is safe to simply discard.
Note that such RRs may include additional section processing Note that such RRs may include additional section processing
provided such processing is optional. provided such processing is optional.
3.1.2 Expert Review DNS RRTYPE Expert Review Template IANA shall maintain a public archive of approved templates.
DNS RRTYPE PARAMETER ALLOCATION TEMPLATE
Date:
Name, email, and telephone number of originator:
Provide a pointer to internet-draft or other public document
giving a detailed description of the protocol use of the new
RRTYPE, or, alternatively, append detailed documentation to
this template:
What need is the new RRTYPE intended to satisfy?
What existing RRTYPE or RRTYPEs come closest to filling that
need and why are they unsatisfactory?
What mnemonic is requested for the new RRTYPE (optional)?
Does the requested RRTYPE make us of any existing IANA Registry
or require the creation of a new IANA Registry and if so what
is that registry or registries?
Does the proposed RRTYPE require special handling within the
DNS different from an Unknown RRTYPE or ignorable Meta-TYPE?
Comments:
3.1.3 DNS RRTYPE Expert Guidelines 3.1.2 DNS RRTYPE Expert Guidelines
The designed DNS RRTYPE Expert is required to monitor discussion of The selected DNS RRTYPE Expert is required to monitor discussion of
the proposed RRTYPE which may occur on the namedroppers mailing list the proposed RRTYPE which may occur on the namedroppers mailing list
and to consult with other experts as necessary. The Expert should and may consult with other technical experts as necessary. The Expert
normally reject any RRTYPE allocation request which meets one or more should normally reject any RRTYPE allocation request which meets one
of the following criterion: or more of the following criterion:
1. Did not have a complete template as specified above posted to the
namedroppers mailing list for at least three weeks.
2. Was documented in a manner that was not sufficiently clear to
evaluate or ensure interoperability.
3. The intended use of the proposed RRTYPE would cause problems with 1. Was documented in a manner that was not sufficiently clear to
existing DNS deployments or the DNS infrastructure. evaluate or implement.
4. The requested RRTYPE would conflict with one under development 2. Proposed RRTYPE or RRTYPEs affect DNS processing and do not meet
within the IETF and the existence of more than one such type would the criteria in point 2 in Section 3.1.1 above.
harm interoperability.
5. An existing RRTYPE or RRTYPEs appear to adequately meet the 3. The documentation of the proposed RRTYPE or RRTYPEs is incomplete.
purpose of the RR for which a RRTYPE value or values are (Additional documentation can be provided during the public
requested. comment period or by the Expert.)
6. An excessive number of RRTYPE values is being requested when the 4. Application use as documented makes incorrect assumptions about
purpose could be met with a smaller number. DNS protocol behavior, such as wild cards, CNAME, DNAME etc.
7. The request appears to be for a RRTYPE value that would not 5. An excessive number of RRTYPE values is being requested when the
genuinely be used in the DNS or whose use would be insignificant purpose could be met with a smaller number or with Private Use
or whose near term use would be better met by a value from the values.
range reserved for Private Use.
3.1.4 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 [RFC2671]. Its primary purpose is to extend the specified in [RFC2671]. 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 type, OpCode, flag bits, and RDATA size. In particular, for
resolvers and servers that recognize it, it extends the RCODE field resolvers and servers that recognize it, it extends the RCODE field
from 4 to 12 bits. from 4 to 12 bits.
3.1.5 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 but the 16 bit unsigned integer 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 field at the beginning of the RDATA is interpreted as a subtype as
follows: follows:
Decimal Decimal
Hexadecimal Hexadecimal
0 0
skipping to change at page 11, line 7 skipping to change at page 10, line 22
0x0003 - 0xFEFF - Allocation by IETF Consensus. 0x0003 - 0xFEFF - Allocation by IETF Consensus.
65,280 - 65,534 65,280 - 65,534
0xFF00 - 0xFFFE - Private Use. 0xFF00 - 0xFFFE - Private Use.
65,535 65,535
0xFFFF - Reserved, allocation requires IETF Standards Action. 0xFFFF - Reserved, allocation requires IETF Standards Action.
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
are the same and the null label is usable only as root in every are the same and the null label is usable only as root in every
CLASS. As global networking and DNS have evolved, the IN, or CLASS. As global networking and DNS have evolved, the IN, or
skipping to change at page 13, line 32 skipping to change at page 13, line 9
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
[RFC4035] for secure DNS considerations. [RFC4035] for secure DNS considerations.
5. IANA Considerations 5. IANA Considerations
This document consists entirely of DNS IANA Considerations and This document consists entirely of DNS IANA Considerations and
includes the following changes from its predecessor [RFC2929]. It includes the following changes from its predecessor [RFC2929]. It
affect the registry currently at http://www.iana.org/assignments/dns- affects the registry currently at
parameters and its subregistries. http://www.iana.org/assignments/dns-parameters and its subregistries.
1. In the Domain Name System "Resource record (RR) TYPES and QTYPEs" 1. In the Domain Name System "Resource record (RR) TYPES and QTYPEs"
resgistry, it changes most "IETF Consensus" and all "Specification registry, it changes most "IETF Consensus" and all "Specification
Required" allocation policies for RRTYPEs to be "DNS TYPE Required" allocation policies for RRTYPEs to be "DNS TYPE
Allocation Policy" and changes the policy for RRTYPE 0xFFFF to be Allocation Policy" and changes the policy for RRTYPE 0xFFFF to be
"IETF Standards Action". It also speciies the "DNS TYPE "IETF Standards Action". It also specifies the "DNS TYPE
Allocation Policy" which is based on Expert Review with additional Allocation Policy" which is based on Expert Review with additional
provisions and restrictions, including the posting of a template, provisions and restrictions, including the sending of a completed
in most cases and requires "IETF Standards Action as modfiied by copy of the template in Annex A to <iana@iana.org>, in most cases,
[RFC4020]" in other cases. See Section 3.1 for details. IANA and requires "IETF Standards Action as modified by [RFC4020]" in
shall archive and make available all approved RRTYPE allocation other cases. IANA shall establish a process for accepting such
templates. templates, posting them to the namedroppers@ops.ietf.org mailing
list, selecting one of such Experts as have been appointed to
review such template form applications, and archive and make
available all approved RRTYPE allocation templates. See Section
3.1 and Annex A for more details.
2. For Opcodes (see Section 2.2), it changes "IETF Standards Action" 2. For Opcodes (see Section 2.2), it changes "IETF Standards Action"
allocation requirements to say "as modified by [RFC4020]". allocation requirements to add "as modified by [RFC4020]".
3. It changes the allocation status of RCODE 0xFFFF to be IETF 3. It changes the allocation status of RCODE 0xFFFF to be IETF
Standards Action required. See Section 2.3. Standards Action required. See Section 2.3.
4. It adds an IANA allocation policy for the AFSDB RR Subtype field 4. It adds an IANA allocation policy for the AFSDB RR Subtype field
which requires the creation of a new registry. See Section 3.1.5. which requires the creation of a new registry. See Section 3.1.4.
5. It splits Specification Required CLASSes into data CLASSes and 5. It splits Specification Required CLASSes into data CLASSes and
query or meta CLASSes. See Section 3.2. query or meta CLASSes. See Section 3.2.
Annex A: RRTYPE Allocation Template
DNS RRTYPE PARAMETER ALLOCATION TEMPLATE
This template is to be submitted to IANA for processing by emailing
the template to <TDB>@iana.org.
A. Submission Date:
B. Contact Information for submitter:
Name:
Email Address:
International telephone number:
Other contact handles:
C. Motivation for the new RRTYPE application?
Please keep this part at a high level to inform the Expert and
reviewers about uses of the RRTYPE. Remember most reviewers
will be DNS experts that may have limited knowledge of your
application space.
D. Description of the new RRTYPE, including any special processing
for it by applications or DNS resolvers as well as servers.
This description can be provided in-line in the template, as an
attachment or with a publicly available URL:
E. What existing RRTYPE or RRTYPEs come closest to filling that
need and why are they unsatisfactory?
F. What mnemonic is requested for the new RRTYPE (optional)?
Note: this can be left blank and the mnemonic decided after the
template is accepted.
G. Does the requested RRTYPE make use of any existing IANA
Registry or require the creation of a new IANA Registry and if
so what is that registry or registries?
If a new registry is needed, specify allocation policy for it
and initial contents.
H. Does the proposal require/expect any changes in DNS
servers/resolvers that prevent the new type from being
processed as an unknown RRTYPE?
I. Comments:
Additional IPR Provisions Additional IPR Provisions
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 16, line 7 skipping to change at page 16, line 31
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Copyright Copyright
Copyright (C) The IETF Trust (2006). This document is subject to the Copyright (C) The IETF Trust (2007).
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. 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.
Normative References Normative References
[RFC1034] - Mockapetris, P., "Domain Names - Concepts and [RFC1034] - Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987. Facilities", STD 13, RFC 1034, November 1987.
[RFC1035] - Mockapetris, P., "Domain Names - Implementation and [RFC1035] - Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987. Specifications", STD 13, RFC 1035, November 1987.
[RFC1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
[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., Thomson, S., Rekhter, Y. and J. Bound, [RFC2136] - Vixie, P., 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)", RFC 2136,
April 1997. 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.
[RFC2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC [RFC2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
2671, August 1999. 2671, August 1999.
[RFC2673] - Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
[RFC2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B. [RFC2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B.
Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000. RFC 2845, May 2000.
[RFC2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY [RFC2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", September 2000. RR)", September 2000.
[RFC3363] - 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.
[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.
skipping to change at page 17, line 41 skipping to change at page 18, line 21
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] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts [Moon1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
Institute of Technology Artificial Intelligence Laboratory, June Institute of Technology Artificial Intelligence Laboratory, June
1981. 1981.
[RFC1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
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, D. and A. Panitz, "Reserved Top Level DNS [RFC2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", RFC 2606, June 1999. Names", RFC 2606, June 1999.
[RFC2673] - Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
[RFC2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, [RFC2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
"Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
September 2000. September 2000.
[RFC2931] - Eastlake, E., "DNS Request and Transaction Signatures ( [RFC2931] - Eastlake, E., "DNS Request and Transaction Signatures (
SIG(0)s )", RFC 2931, September 2000. SIG(0)s )", RFC 2931, September 2000.
[RFC3363] - 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.
[RFC4343] - Eastlake, D., "Domain Name System (DNS) Case [RFC4343] - Eastlake, D., "Domain Name System (DNS) Case
Insensitivity Clarification", RFC 4343, December 2005. Insensitivity Clarification", RFC 4343, December 2005.
Author's Address Author's Address
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Motorola Laboratories Motorola Laboratories
155 Beaver Street 155 Beaver Street
Milford, MA 01757 USA Milford, MA 01757 USA
Telephone: +1-508-786-7554 (w) Telephone: +1-508-786-7554 (w)
email: Donald.Eastlake@motorola.com email: Donald.Eastlake@motorola.com
Expiration and File Name Expiration and File Name
This draft expires May 2007. This draft expires January 2008.
Its file name is draft-ietf-dnsext-2929bis-04.txt. Its file name is draft-ietf-dnsext-2929bis-05.txt.
Disclaimer Disclaimer
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 40 change blocks. 
113 lines changed or deleted 134 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/