< draft-ietf-dnsext-axfr-clarify-13.txt   draft-ietf-dnsext-axfr-clarify-14.txt >
DNS Extensions Working Group Edward Lewis DNS Extensions Working Group Edward Lewis
Internet-Draft NeuStar, Inc. Internet-Draft NeuStar, Inc.
Updates: 1034, 1035 (if approved) A. Hoenes, Ed. Updates: 1034, 1035 (if approved) A. Hoenes, Ed.
Intended status: Standards Track TR-Sys Intended status: Standards Track TR-Sys
Expires: July 18, 2010 January 18, 2010 Expires: September 26, 2010 March 26, 2010
DNS Zone Transfer Protocol (AXFR) DNS Zone Transfer Protocol (AXFR)
draft-ietf-dnsext-axfr-clarify-13 draft-ietf-dnsext-axfr-clarify-14
Abstract Abstract
The Domain Name System standard mechanisms for maintaining coherent The standard means within the Domain Name System protocol for
servers for a zone consist of three elements. One mechanism is the maintaining coherence among a zone's authoritative name servers
Authoritative Transfer (AXFR) defined in RFC 1034 and RFC 1035. consists of three mechanisms. Authoritative Transfer (AXFR) is one
of the mechanisms and is defined in RFC 1034 and RFC 1035.
The definition of AXFR has proven insufficient in detail, thereby The definition of AXFR has proven insufficient in detail, thereby
forcing implementations intended to be compliant to make assumptions, forcing implementations intended to be compliant to make assumptions,
impeding interoperability. Yet today we have a satisfactory set of impeding interoperability. Yet today we have a satisfactory set of
implementations that do interoperate. This document is a new implementations that do interoperate. This document is a new
definition of AXFR -- new in the sense that it records an accurate definition of AXFR -- new in the sense that it records an accurate
definition of an interoperable AXFR mechanism. definition of an interoperable AXFR mechanism.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to Process, except to format it for publication as an RFC or to
translate it into languages other than English. translate it into languages other than English.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 18, 2010. This Internet-Draft will expire on September 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 46 skipping to change at page 3, line 46
4.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5. Authorization . . . . . . . . . . . . . . . . . . . . . . . 22 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . 22
6. Zone Integrity . . . . . . . . . . . . . . . . . . . . . . . 23 6. Zone Integrity . . . . . . . . . . . . . . . . . . . . . . . 23
7. Backwards Compatibility . . . . . . . . . . . . . . . . . . 24 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . 24
7.1. Server . . . . . . . . . . .. . . . . . . . . . . . . . . 24 7.1. Server . . . . . . . . . . .. . . . . . . . . . . . . . . 24
7.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25
10. Internationalization Considerations . . . . . . . . . . . . 25 10. Internationalization Considerations . . . . . . . . . . . . 25
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . .. . . . . . . . . . . . . . . . 26 12.1. Normative References . .. . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
The Domain Name System standard facilities for maintaining coherent The Domain Name System standard facilities for maintaining coherent
servers for a zone consist of three elements. Authoritative Transfer servers for a zone consist of three elements. Authoritative Transfer
(AXFR) is defined in "Domain Names - Concepts and Facilities" (AXFR) is defined in "Domain Names - Concepts and Facilities"
[RFC1034] (referred to in this document as RFC 1034) and "Domain [RFC1034] (referred to in this document as RFC 1034) and "Domain
Names - Implementation and Specification" [RFC1035] (henceforth Names - Implementation and Specification" [RFC1035] (henceforth
RFC 1035). Incremental Zone Transfer (IXFR) is defined in RFC 1035). Incremental Zone Transfer (IXFR) is defined in
skipping to change at page 6, line 12 skipping to change at page 6, line 12
when zone data changes occur during an ongoing zone transfer using when zone data changes occur during an ongoing zone transfer using
AXFR. AXFR.
This document will update the specification of AXFR. To this end, it This document will update the specification of AXFR. To this end, it
fully specifies the record formats and processing rules for AXFR, fully specifies the record formats and processing rules for AXFR,
largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and it largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and it
details the transport considerations for AXFR, thus amending Section details the transport considerations for AXFR, thus amending Section
4.2.2 of RFC 1035. Furthermore, it discusses backward compatibility 4.2.2 of RFC 1035. Furthermore, it discusses backward compatibility
issues and provides policy/management considerations as well as issues and provides policy/management considerations as well as
specific Security Considerations for AXFR. The goal of this document specific Security Considerations for AXFR. The goal of this document
is to define AXFR as it exists, or is supposed to exist, currently. is to define AXFR as it is understood by the DNS community to exist
today.
2. AXFR Messages 2. AXFR Messages
An AXFR session consists of an AXFR query message and the sequence of An AXFR session consists of an AXFR query message and the sequence of
AXFR response messages returned for it. In this document, the AXFR AXFR response messages returned for it. In this document, the AXFR
client is the sender of the AXFR query and the AXFR server is the client is the sender of the AXFR query and the AXFR server is the
responder. (Use of terms such as master, slave, primary, secondary responder. (Use of terms such as master, slave, primary, secondary
are not important for defining AXFR.) The use of the word "session" are not important for defining AXFR.) The use of the word "session"
without qualification refers to an AXFR session. without qualification refers to an AXFR session.
skipping to change at page 7, line 50 skipping to change at page 7, line 50
- "DNS Security Introduction and Requirements" [RFC4033] - "DNS Security Introduction and Requirements" [RFC4033]
- "Resource Records for the DNS Security Extensions" [RFC4034] - "Resource Records for the DNS Security Extensions" [RFC4034]
- "Protocol Modifications for the DNS Security Extensions" [RFC4035] - "Protocol Modifications for the DNS Security Extensions" [RFC4035]
- "Use of SHA-256 in DNSSEC Delegation Signer RRs" [RFC4509] - "Use of SHA-256 in DNSSEC Delegation Signer RRs" [RFC4509]
- "DNS Security Hashed Authenticated Denial of Existence" [RFC5155] - "DNS Security Hashed Authenticated Denial of Existence" [RFC5155]
- "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource - "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource
Records for DNSSEC" [RFC5702] Records for DNSSEC" [RFC5702]
- "Clarifications and Implementation Notes for DNSSECbis" [DNSSEC-U] - "Clarifications and Implementation Notes for DNSSECbis" [DNSSEC-U]
These documents contain information about the syntax and semantics of These documents contain information about the syntax and semantics of
DNS messages. They ought not interfere with AXFR but are also DNS messages. They do not interfere with AXFR but are also helpful
helpful in understanding what will be carried via AXFR. in understanding what will be carried via AXFR.
For convenience, the synopsis of the DNS message header from For convenience, the synopsis of the DNS message header from
[RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is
reproduced here informally: reproduced here informally:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID | | ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE | |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE |
skipping to change at page 10, line 6 skipping to change at page 10, line 6
more details. more details.
b) 'n/a' -- The value in this field has no meaning in the context of b) 'n/a' -- The value in this field has no meaning in the context of
AXFR query messages. For the client, it is RECOMMENDED that the AXFR query messages. For the client, it is RECOMMENDED that the
value be zero. The server MUST ignore this value. value be zero. The server MUST ignore this value.
c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore
it. it.
d) The client MUST set this field to the number of resource records d) The client MUST set this field to the number of resource records
it places into the Additional section. In the absense of explicit it places into the Additional section. In the absence of explicit
specification of new RRs to be carried in the Additional section specification of new RRs to be carried in the Additional section
of AXFR queries, the value MAY be 0, 1 or 2. See Section 2.1.5 of AXFR queries, the value MAY be 0, 1 or 2. See Section 2.1.5
"Additional Section" for details on the currently applicable RRs. "Additional Section" for details on the currently applicable RRs.
2.1.2. Question Section 2.1.2. Question Section
The Question Section of the AXFR query MUST conform to Section 4.1.2 The Question section of the AXFR query MUST conform to Section 4.1.2
of RFC 1035, and contain a single resource record with the following of RFC 1035, and contain a single resource record with the following
values: values:
QNAME the name of the zone requested QNAME the name of the zone requested
QTYPE AXFR (= 252), the pseudo-RR type for zone transfer QTYPE AXFR (= 252), the pseudo-RR type for zone transfer
[DNSVALS] [DNSVALS]
QCLASS the class of the zone requested [DNSVALS] QCLASS the class of the zone requested [DNSVALS]
skipping to change at page 10, line 40 skipping to change at page 10, line 40
The Authority section MUST be empty. The Authority section MUST be empty.
2.1.5. Additional Section 2.1.5. Additional Section
Currently, two kinds of resource records are defined that can appear Currently, two kinds of resource records are defined that can appear
in the Additional section of AXFR queries and responses: EDNS and DNS in the Additional section of AXFR queries and responses: EDNS and DNS
transaction security. Future specifications defining RRs that can be transaction security. Future specifications defining RRs that can be
carried in the Additional section of normal DNS transactions need to carried in the Additional section of normal DNS transactions need to
explicitly describe their use with AXFR, should that be desired. explicitly describe their use with AXFR, should that be desired.
The client MAY include one EDNS0 OPT [RFC2671] resource record. If The client MAY include one OPT resource record [RFC2671]. If
the server does not support EDNS0, the client MUST send this section the server does not support EDNS0, the client MUST send this section
without an EDNS0 OPT resource record if there is a retry. However, without an OPT resource record if there is a retry. However,
the protocol does not define an explicit indication that the server the protocol does not define an explicit indication that the server
does not support EDNS0; that needs to be inferred by the client. does not support EDNS0; that needs to be inferred by the client.
Often, the server will return a FormErr(1) which might be related to Often, the server will return a FormErr(1) which might be related to
the OPT resource record. Note that, at the time of this writing, the OPT resource record. Note that, at the time of this writing,
only the EXTENDED-RCODE field of the EDNS0 OPT RR is meaningful in only the EXTENDED-RCODE field of the OPT RR is meaningful in
the context of AXFR; future specifications of EDNS0 flags and/or the context of AXFR; future specifications of EDNS flags and/or
EDNS0 options must describe their usage in the context of AXFR, if EDNS options must describe their usage in the context of AXFR, if
applicable. applicable.
The client MAY include one transaction integrity and authentication The client MAY include one transaction integrity and authentication
resource record, currently a choice of TSIG [RFC2845] or SIG(0) resource record, currently a choice of TSIG [RFC2845] or SIG(0)
[RFC2931]. If the server has indicated that it does not recognize [RFC2931]. If the server has indicated that it does not recognize
the resource record, and that the error is indeed caused by the the resource record, and that the error is indeed caused by the
resource record, the client probably should not try again. Removing resource record, the client probably should not try again. Removing
the security data in the face of an obstacle ought to only be done the security data in the face of an obstacle ought to only be done
with full awareness of the implication of doing so. with full awareness of the implication of doing so.
In general, if an AXFR client is aware that an AXFR server does not In general, if an AXFR client is aware that an AXFR server does not
support a particular mechanism, the client SHOULD NOT attempt to support a particular mechanism, the client SHOULD NOT attempt to
engage the server using the mechanism (or at all). A client could engage the server using the mechanism (or at all). A client could
become aware of a server's abilities via a configuration setting or become aware of a server's abilities via a configuration setting or
via some other (as yet) undefined means. via some other (as yet) undefined means.
The range of permissible resource records that MAY appear in the The range of permissible resource records that MAY appear in the
Additional section might change over time. If either a change to an Additional section might change over time. If either a change to an
existing resource record (like the OPT RR for EDNS0) is made or a new existing resource record (like the OPT RR for EDNS) is made or a new
Additional section record is created, the new definitions ought to Additional section record is created, the new definitions ought to
include a discussion on the applicability and impact upon AXFR. include a discussion on the applicability and impact upon AXFR.
Future resource records residing in the Additional section might have Future resource records residing in the Additional section might have
an effect that is orthogonal to AXFR, so can ride through the session an effect that is orthogonal to AXFR, so can ride through the session
as opaque data. In this case, a "wise" implementation ought to be as opaque data. In this case, a "wise" implementation ought to be
able to pass these records through without disruption. able to pass these records through without disruption.
2.2. AXFR Response 2.2. AXFR Response
The AXFR response will consist of one or more messages. The special The AXFR response will consist of one or more messages. The special
skipping to change at page 13, line 49 skipping to change at page 13, line 49
d) 'mbz' -- The server MUST set this bit to 0, the client MUST ignore d) 'mbz' -- The server MUST set this bit to 0, the client MUST ignore
it. it.
e) In the absence of an error, the server MUST set the value of this e) In the absence of an error, the server MUST set the value of this
field to NoError(0). If a server is not authoritative for the field to NoError(0). If a server is not authoritative for the
queried zone, the server SHOULD set the value to NotAuth(9). queried zone, the server SHOULD set the value to NotAuth(9).
(Reminder, consult the appropriate IANA registry [DNSVALS].) If a (Reminder, consult the appropriate IANA registry [DNSVALS].) If a
client receives any other value in response, it MUST act according client receives any other value in response, it MUST act according
to the error. For example, a malformed AXFR query or the presence to the error. For example, a malformed AXFR query or the presence
of an EDNS0 OPT resource record sent to an old server will result of an OPT resource record sent to an old server will result
in a FormErr(1) value. This value is not set as part of the AXFR- in a FormErr(1) value. This value is not set as part of the AXFR-
specific response processing. The same is true for other values specific response processing. The same is true for other values
indicating an error. indicating an error.
f) The count of answer records MUST equal the number of resource f) The count of answer records MUST equal the number of resource
records in the AXFR Answer Section. When a server is aware that a records in the AXFR Answer Section. When a server is aware that a
client will only accept response messages with a single resource client will only accept response messages with a single resource
record, then the value MUST be 1. A server MAY be made aware of a record, then the value MUST be 1. A server MAY be made aware of a
client's limitations via configuration data. client's limitations via configuration data.
g) The server MUST set this field to the number of resource records g) The server MUST set this field to the number of resource records
it places into the Additional section. In the absense of explicit it places into the Additional section. In the absence of explicit
specification of new RRs to be carried in the Additional section specification of new RRs to be carried in the Additional section
of AXFR response messages, the value MAY be 0, 1 or 2. See of AXFR response messages, the value MAY be 0, 1 or 2. See
Section 2.1.5 above for details on the currently applicable RRs Section 2.1.5 above for details on the currently applicable RRs
and Section 2.2.5 for additional considerations specific to AXFR and Section 2.2.5 for additional considerations specific to AXFR
servers. servers.
2.2.2. Question Section 2.2.2. Question Section
In the first response message, this section MUST be copied from the In the first response message, this section MUST be copied from the
query. In subsequent messages, this section MAY be copied from the query. In subsequent messages, this section MAY be copied from the
skipping to change at page 14, line 39 skipping to change at page 14, line 39
The Answer section MUST be populated with the zone contents. See The Answer section MUST be populated with the zone contents. See
Section 3 below on encoding zone contents. Section 3 below on encoding zone contents.
2.2.4. Authority Section 2.2.4. Authority Section
The Authority section MUST be empty. The Authority section MUST be empty.
2.2.5. Additional Section 2.2.5. Additional Section
The contents of this section MUST follow the guidelines for EDNS0 and The contents of this section MUST follow the guidelines for the OPT,
TSIG, SIG(0), or whatever other future record is possible here. The TSIG, and SIG(0) RRs, or whatever other future record is possible
contents of Section 2.1.5 apply analogously as well. here. The contents of Section 2.1.5 apply analogously as well.
The following considerations specifically apply to AXFR responses: The following considerations specifically apply to AXFR responses:
If the client has supplied an EDNS0 OPT RR in the AXFR query and if If the client has supplied an EDNS OPT RR in the AXFR query and if
the server supports ENDS0 as well, it SHOULD include one EDNS0 OPT RR the server supports EDNS as well, it SHOULD include one OPT RR
in the first response message and MAY do so in subsequent response in the first response message and MAY do so in subsequent response
messages (see Section 2.2); the specifications of EDNS0 options to be messages (see Section 2.2); the specifications of EDNS options to be
carried in the OPT RR may impose stronger requirements. carried in the OPT RR may impose stronger requirements.
If the client has supplied a transaction security resource record If the client has supplied a transaction security resource record
(currently a choice of TSIG and SIG(0)) and the server supports the (currently a choice of TSIG and SIG(0)) and the server supports the
method chosen by the client, it MUST place the corresponding resource method chosen by the client, it MUST place the corresponding resource
record into the AXFR response message(s), according to the rules record into the AXFR response message(s), according to the rules
specified for that method. specified for that method.
2.3. TCP Connection Aborts 2.3. TCP Connection Aborts
skipping to change at page 20, line 28 skipping to change at page 20, line 28
necessary that new general purpose client implementations still necessary that new general purpose client implementations still
provide options for graceful fallback to the old behavior in their provide options for graceful fallback to the old behavior in their
support of concurrent DNS transactions and AXFR sessions on a single support of concurrent DNS transactions and AXFR sessions on a single
TCP connection. TCP connection.
4.1. TCP 4.1. TCP
In the original definition there arguably is an implicit assumption In the original definition there arguably is an implicit assumption
(probably unintentional) that a TCP connection is used for one and (probably unintentional) that a TCP connection is used for one and
only one AXFR session. This is evidenced in the lack of an explicit only one AXFR session. This is evidenced in the lack of an explicit
requirement to copy the Question Section and/or the message ID into requirement to copy the Question section and/or the message ID into
responses, no explicit ordering information within the AXFR response responses, no explicit ordering information within the AXFR response
messages, and the lack of an explicit notice indicating that a zone messages, and the lack of an explicit notice indicating that a zone
transfer continues in the next message. transfer continues in the next message.
The guidance given below is intended to enable better performance of The guidance given below is intended to enable better performance of
the AXFR exchange as well as provide guidelines on interactions with the AXFR exchange as well as provide guidelines on interactions with
older software. Better performance includes being able to multiplex older software. Better performance includes being able to multiplex
DNS message exchanges including zone transfer sessions. Guidelines DNS message exchanges including zone transfer sessions. Guidelines
for interacting with older software are generally applicable to new for interacting with older software are generally applicable to new
AXFR clients. In the reverse situation, older AXFR client and newer AXFR clients. In the reverse situation, older AXFR client and newer
skipping to change at page 25, line 7 skipping to change at page 25, line 7
not defined by this document) when querying an AXFR server. not defined by this document) when querying an AXFR server.
Attempting to issue multiple DNS queries over a TCP transport for an Attempting to issue multiple DNS queries over a TCP transport for an
AXFR session SHOULD be aborted if it interrupts the original request, AXFR session SHOULD be aborted if it interrupts the original request,
and SHOULD take into consideration whether the AXFR server intends to and SHOULD take into consideration whether the AXFR server intends to
close the connection immediately upon completion of the original close the connection immediately upon completion of the original
(connection-causing) zone transfer. (connection-causing) zone transfer.
8. Security Considerations 8. Security Considerations
This document is a clarification of a mechanism outlined in RFCs 1034
and 1035 and as such does not add any new security considerations.
RFC 3833 [RFC3833] is devoted entirely to security considerations for
the DNS; its Section 4.3 delineates zone transfer security aspects
from the security threats addressed by DNSSEC.
Concerns regarding authorization, traffic flooding, and message Concerns regarding authorization, traffic flooding, and message
integrity are mentioned in "Authorization" (Section 5), "TCP" integrity are mentioned in "Authorization" (Section 5), "TCP"
(Section 4.2) and "Zone Integrity" (Section 6). (Section 4.2) and "Zone Integrity" (Section 6).
9. IANA Considerations 9. IANA Considerations
[[ Note to RFC-Ed: this section may be deleted before publication. ]] IANA has added a reference to this RFC in the AXFR (252) row of the
No new registries or new registrations are included in this document. "Resource Record (RR) TYPEs" subregistry of the "Domain Name System
(DNS) Parameters" registry.
10. Internationalization Considerations 10. Internationalization Considerations
The AXFR protocol is transparent to the parts of DNS zone content The AXFR protocol is transparent to the parts of DNS zone content
that can possibly be subject to Internationalization considerations. that can possibly be subject to Internationalization considerations.
It is assumed that for DNS labels and domain names, the issue has It is assumed that for DNS labels and domain names, the issue has
been solved via "Internationalizing Domain Names in Applications been solved via "Internationalizing Domain Names in Applications
(IDNA)" [RFC3490] or its successor(s). (IDNA)" [RFC3490] or its successor(s).
11. Acknowledgments 11. Acknowledgments
skipping to change at page 28, line 9 skipping to change at page 28, line 21
http://www.iana.org/assignments/Address-family-numbers/ . http://www.iana.org/assignments/Address-family-numbers/ .
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
Malis, "A Framework for IP Based Virtual Private Malis, "A Framework for IP Based Virtual Private
Networks", RFC 2764, February 2000. Networks", RFC 2764, February 2000.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
[RFC3833] Atkins, D., and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004.
[DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and [DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and
Implementation Notes for DNSSECbis", Implementation Notes for DNSSECbis",
draft-ietf-dnsext-dnssec-bis-updates-09 (work in draft-ietf-dnsext-dnssec-bis-updates-10 (work in
progress), September 2009. progress), March 2010.
Authors' Addresses Authors' Addresses
Edward Lewis Edward Lewis
46000 Center Oak Plaza 46000 Center Oak Plaza
Sterling, VA, 22033, US Sterling, VA, 22033, US
Email: ed.lewis@neustar.biz Email: ed.lewis@neustar.biz
Alfred Hoenes, Editor Alfred Hoenes, Editor
 End of changes. 25 change blocks. 
33 lines changed or deleted 46 lines changed or added

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