draft-ietf-dnsext-axfr-clarify-10.txt   draft-ietf-dnsext-axfr-clarify-11.txt 
DNS Extensions Working Group Edward Lewis DNS Extensions Working Group Edward Lewis
INTERNET-DRAFT NeuStar, Inc. INTERNET-DRAFT NeuStar, Inc.
Expires: July 1, 2009 January 2009
Updates: 1034, 1035 (if approved) Updates: 1034, 1035 (if approved)
Intended status: Standards Track Intended status: Standards Track
DNS Zone Transfer Protocol (AXFR) DNS Zone Transfer Protocol (AXFR)
draft-ietf-dnsext-axfr-clarify-10.txt draft-ietf-dnsext-axfr-clarify-11.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at line 31 skipping to change at line 31
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 October 1, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the Copyright (c) 2009 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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. respect to this document.
Abstract Abstract
skipping to change at line 130 skipping to change at line 132
1.3 Context 1.3 Context
Besides describing the mechanisms themselves, there is the context in Besides describing the mechanisms themselves, there is the context in
which they operate to consider. When AXFR, IXFR and NOTIFY were which they operate to consider. When AXFR, IXFR and NOTIFY were
defined, there was little consideration given to security and privacy defined, there was little consideration given to security and privacy
issues. Since the original definition of AXFR, new opinions have issues. Since the original definition of AXFR, new opinions have
appeared on the access to an entire zone's contents. In this document, appeared on the access to an entire zone's contents. In this document,
the basic mechanisms will be discussed separately from the permission the basic mechanisms will be discussed separately from the permission
to use these mechanisms. to use these mechanisms.
1.4 Coverage
This document concentrates on just the definition of AXFR. Any effort
to update the IXFR or NOTIFY mechanisms would be done in different
documents. This is not strictly a clarification of the definition in
RFC 1034 and RFC 1035. This document will update those sections, and
invalidate at least one part of that definition. The goal of this
document is to define AXFR as it exists, or is supposed to exist,
currently.
1.4 Coverage and Relationship to Original AXFR Specification 1.4 Coverage and Relationship to Original AXFR Specification
This document concentrates on just the definition of AXFR. Any effort This document concentrates on just the definition of AXFR. Any effort
to update the IXFR or NOTIFY mechanisms would be done in different to update the IXFR or NOTIFY mechanisms would be done in different
documents. documents.
The original "specification" of the AXFR sub-protocol is scattered The original "specification" of the AXFR sub-protocol is scattered
depicts the scenario for which AXFR has been designed. Section 4.3.5 depicts the scenario for which AXFR has been designed. Section 4.3.5
of RFC 1034 describes the zone synchronization strategies in general of RFC 1034 describes the zone synchronization strategies in general
and rules for the invocation of a full zone transfer via AXFR; the and rules for the invocation of a full zone transfer via AXFR; the
fifth paragraph of that section contains a very short sketch of the fifth paragraph of that section contains a very short sketch of the
AXFR protocol. Section 3.2.3 of RFC 1035 has assigned the code point AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant
for the AXFR QTYPE (see section 2.1.2 below for more details). flaw in that specification. Section 3.2.3 of RFC 1035 has assigned
Section 4.2 of RFC 1035 discusses the transport layer use of DNS and the code point for the AXFR QTYPE (see section 2.1.2 below for more
shortly explains why UDP transport is deemed inappropriate for AXFR; details). Section 4.2 of RFC 1035 discusses the transport layer use
the last paragraph of Section 4.2.2 gives details for the TCP of DNS and shortly explains why UDP transport is deemed inappropriate
connection management with AXFR. Finally, the second paragraph of for AXFR; the last paragraph of Section 4.2.2 gives details for the
Section 6.3 in RFC 1035 mandates server behavior when zone data TCP connection management with AXFR. Finally, the second paragraph
of Section 6.3 in RFC 1035 mandates server behavior when zone data
changes occur during an ongoing zone transfer using AXFR. changes occur during an ongoing zone transfer using AXFR.
This document will update the specification of AXFR in fully This document will update the specification of AXFR in fully
specifying the record formats and processing rules for AXFR, largely specifying the record formats and processing rules for AXFR, largely
expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and detailing expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and detailing
the transport considerations for AXFR, thus amending Section 4.2.2 of the transport considerations for AXFR, thus amending Section 4.2.2 of
RFC 1035. Furthermore, it discusses backward compatibility issues RFC 1035. Furthermore, it discusses backward compatibility issues
and provides policy/management considerations as well as specific and provides policy/management considerations as well as specific
Security Considerations for AXFR. The goal of this document is to Security Considerations for AXFR. The goal of this document is to
define AXFR as it exists, or is supposed to exist, currently. define AXFR as it exists, or is supposed to exist, currently.
2 AXFR Messages 2 AXFR Messages
An AXFR session consists of an exchange of a AXFR query message and a An AXFR session consists of an AXFR query message and the sequence of
set of AXFR response messages. In this document, the AXFR client is AXFR response messages returned for it. In this document, the AXFR
the sender of the AXFR query and the AXFR server is the responder. client is the sender of the AXFR query and the AXFR server is the
(Use of terms such as master, slave, primary, secondary are not responder. (Use of terms such as master, slave, primary, secondary
important to defining AXFR.) The use of the word "session" without are not important to defining AXFR.) The use of the word "session"
qualification refers to an AXFR session. without qualification refers to an AXFR session.
An important aspect to keep in mind is that the definition of AXFR is An important aspect to keep in mind is that the definition of AXFR is
restricted to TCP [RFC0793]. The design of the AXFR process has restricted to TCP [RFC0793]. The design of the AXFR process has
certain inherent features that are not easily ported to UDP [RFC0768]. certain inherent features that are not easily ported to UDP [RFC0768].
The basic format of an AXFR message is the DNS message as defined in The basic format of an AXFR message is the DNS message as defined in
RFC 1035, Section 4 ("MESSAGES") [RFC1035], updated by the following: RFC 1035, Section 4 ("MESSAGES") [RFC1035], updated by the following:
- "A Mechanism for Prompt Notification of Zone Changes (...)" [RFC1996] - "A Mechanism for Prompt Notification of Zone Changes (...)" [RFC1996]
- "Domain Name System (DNS) IANA Considerations" [RFC5395] - "Domain Name System (DNS) IANA Considerations" [RFC5395]
- "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136] - "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136]
- "Clarifications to the DNS Specification" [RFC2181]
- "Extension Mechanisms for DNS (EDNS0)" [RFC2671] - "Extension Mechanisms for DNS (EDNS0)" [RFC2671]
- "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845] - "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845]
- "Secret Key Establishment for DNS (TKEY RR)" [RFC2930] - "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]
- "Obsoleting IQUERY" [RFC3425] - "Obsoleting IQUERY" [RFC3425]
- "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597] - "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597]
- "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 ... (DS) ... (RRs)" [RFC4509]
- "HMAC SHA TSIG Algorithm Identifiers" [RFC4635] - "HMAC SHA TSIG Algorithm Identifiers" [RFC4635]
- "... (DNSSEC) Hashed Authenticated Denial of Existence" [RFC5155]
For completeness, the following, in process, documents contain
information about the DNS message. These documents ought not interfere
with AXFR but these documents are helpful in understanding what will
be carried via AXFR.
- "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource
Records for DNSSEC" [DRAFT1]
- "Clarifications and Implementation Notes for DNSSECbis" [DRAFT2]
The upper limit on the permissible size of a DNS message over TCP is The upper limit on the permissible size of a DNS message over TCP is
only restricted by the TCP framing defined in RFC 1035, section 4.2.2 only restricted by the TCP framing defined in RFC 1035, section 4.2.2
which specifies a two-octet message length field, understood to be which specifies a two-octet message length field, understood to be
unsigned, and thus causing a limit of 65535 octets. Unlike DNS unsigned, and thus causing a limit of 65535 octets. Unlike DNS
messages over UDP, this limit is not changed by EDNS0. messages over UDP, this limit is not changed by EDNS0.
Note that the TC (truncation) bit is never set by an AXFR server nor
considered/read by an AXFR client.
Field names used in this document will correspond to the names as they Field names used in this document will correspond to the names as they
appear in the IANA registry for DNS Header Flags [DNSFLGS]. appear in the IANA registry for DNS Header Flags [DNSFLGS].
2.1 AXFR query 2.1 AXFR query
An AXFR query is sent by a client whenever there is a reason to ask. An AXFR query is sent by a client whenever there is a reason to ask.
This might be because of zone maintenance activities or as a result of This might be because of zone maintenance activities or as a result of
a command line request, say for debugging. a command line request, say for debugging.
An AXFR query is sent by a client whenever there is a reason to ask.
This might be because of scheduled or triggered zone maintenance
activities (see section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996],
respectively) or as a result of a command line request, say for
debugging.
2.1.1 Header Values 2.1.1 Header Values
These are the DNS message header values for an AXFR query. These are the DNS message header values for an AXFR query.
ID See note 2.1.1.a ID See note 2.1.1.a
QR MUST be 0 (Query) QR MUST be 0 (Query)
OPCODE MUST be 0 (Standard Query) OPCODE MUST be 0 (Standard Query)
AA See note 2.1.1.b AA See note 2.1.1.b
TC See note 2.1.1.b TC See note 2.1.1.b
RD See note 2.1.1.b RD See note 2.1.1.b
skipping to change at line 326 skipping to change at line 341
In such a series, the first message MUST begin with the SOA In such a series, the first message MUST begin with the SOA
resource record of the zone, the last message MUST conclude with the resource record of the zone, the last message MUST conclude with the
same SOA resource record. Intermediate messages MUST NOT contain the same SOA resource record. Intermediate messages MUST NOT contain the
SOA resource record. The first message MUST copy the Query Section SOA resource record. The first message MUST copy the Query Section
from the corresponding AXFR query message in to the first response from the corresponding AXFR query message in to the first response
message's query section. Subsequent messages MAY do the same. message's query section. Subsequent messages MAY do the same.
An AXFR response that is indicating an error MUST consist of a single An AXFR response that is indicating an error MUST consist of a single
DNS message with the return code set to the appropriate value for the DNS message with the return code set to the appropriate value for the
condition encountered - once the error condition is detected. Such condition encountered - once the error condition is detected. Such
a message MUST copy the AXFR query Query Section into its Query a message MUST terminate the AXFR session; it MUST copy the Query
Section. The inclusion of the terminating SOA resource record is not Section from the AXFR query into its Query Section, but the inclusion
necessary. of the terminating SOA resource record is not necessary.
An AXFR client might receive a number of AXFR response messages An AXFR client might receive a number of AXFR response messages
free of an error condition before the message indicating an error free of an error condition before the message indicating an error
is received. But once an error is reported, the AXFR client can is received.
assume that the error reporting message is the last message sent by
the AXFR server in the current AXFR session.
2.2.1 "0 Message" Response 2.2.1 "0 Message" Response
A legitimate "0 message" response, i.e., the client sees no response A legitimate "0 message" response, i.e., the client sees no response
whatsoever, is very exceptional and controversial. Unquestionably it whatsoever, is very exceptional and controversial. Unquestionably it
is unhealthy for there to be 0 responses in a protocol that is designed is unhealthy for there to be 0 responses in a protocol that is designed
around a query - response paradigm over an unreliable transport. The around a query - response paradigm over an unreliable transport. The
lack of a response could be a sign of underlying network problems and lack of a response could be a sign of underlying network problems and
cause the protocol state machine to react accordingly. However, AXFR cause the protocol state machine to react accordingly. However, AXFR
uses TCP and not UDP, eliminating undetectable network errors. uses TCP and not UDP, eliminating undetectable network errors.
skipping to change at line 416 skipping to change at line 429
(see below) then this value MUST be set according to the rules in RFC (see below) then this value MUST be set according to the rules in RFC
4035, section 3.1.6, "The AD and CD Bits in an Authoritative Response". 4035, section 3.1.6, "The AD and CD Bits in an Authoritative Response".
If the implementation does not support the DNS Security Extensions, If the implementation does not support the DNS Security Extensions,
then this value MUST be set to 0 and MUST be ignored upon receipt. then this value MUST be set to 0 and MUST be ignored upon receipt.
The DNS Security Extensions (DNSSEC) is defined in these base The DNS Security Extensions (DNSSEC) is defined in these base
documents: documents:
- "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]
- "DNS Security Hashed Authenticated Denial of Existence" [RFC5155]
as well pending documents, such as these:
- "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource
Records for DNSSEC" [DRAFT1]
- "Clarifications and Implementation Notes for DNSSECbis" [DRAFT2]
Note 2.2.2.f In the absence of an error, the server MUST set the value Note 2.2.2.f In the absence of an error, the server MUST set the value
of this field to NoError. If a server is not authoritative for the of this field to NoError. If a server is not authoritative for the
queried zone, the server SHOULD set the value to NotAuth. (Reminder, queried zone, the server SHOULD set the value to NotAuth. (Reminder,
consult the appropriate IANA registry [DNSVALS].) If a client consult the appropriate IANA registry [DNSVALS].) If a client
receives any other value in response, it MUST act according to the receives any other value in response, it MUST act according to the
error. For example, a malformed AXFR query or the presence of an EDNS0 error. For example, a malformed AXFR query or the presence of an EDNS0
OPT resource record sent to an old server will garner a FormErr value. OPT resource record sent to an old server will garner a FormErr value.
This value is not set as part of the AXFR response processing. The This value is not set as part of the AXFR-specific response processing.
same is true for other error-indicating values. The same is true for other error-indicating values.
Note 2.2.2.g The count of answer records MUST equal the number of Note 2.2.2.g The count of answer records MUST equal the number of
resource records in the AXFR Answer Section. When a server is aware resource records in the AXFR Answer Section. When a server is aware
that a client will only accept one resource record per response that a client will only accept one resource record per response
message, then the value MUST be 1. A server MAY be made aware of a message, 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.
Note 2.2.2.h The client MUST set this field to be the number of Note 2.2.2.h The client MUST set this field to be the number of
resource records appearing in the additional section. See Section resource records appearing in the additional section. The
2.1.5 "Additional Section" for details. considerations in Note 2.1.1.d above apply equally; see Section
2.2.6 "Additional Section" below for more details.
2.2.3 Query Section 2.2.3 Query 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
query or it MAY be empty. The content of this section MAY be used to query or it MAY be empty. The content of this section MAY be used to
determine the context of the message, that is, the name of the zone determine the context of the message, that is, the name of the zone
being transferred. being transferred.
>| [...]. In subsequent messages, this section MAY be copied from the
>| query, or it MAY be empty. [...]
2.2.4 Answer Section 2.2.4 Answer Section
MUST be populated with the zone contents. See later section on MUST be populated with the zone contents. See later section on
encoding zone contents. encoding zone contents.
2.2.5 Authority Section 2.2.5 Authority Section
MUST be empty. MUST be empty.
2.2.6 Additional Section 2.2.6 Additional Section
The contents of this section MUST follow the guidelines for EDNS0, The contents of this section MUST follow the guidelines for EDNS0,
TSIG, SIG(0), or what ever other future record is possible here. The TSIG, SIG(0), or what ever other future record is possible here. The
contents of section 2.1.5 apply here as well. contents of section 2.1.5 apply here as well.
Note that TSIG and SIG(0), if in use, will treat each individual
AXFR response message within a session as a unit of data. That is,
each message will have a TSIG or SIG(0) (if in use) and the
cryptographic check will cover just that message. The same rule
will apply to future alternatives and documents covering them ought
to consider the impact on AXFR response messages.
2.3 TCP Connection Aborts 2.3 TCP Connection Aborts
If an AXFR client sends a query on a TCP connection and the connection If an AXFR client sends a query on a TCP connection and the connection
is closed at any point, the AXFR client MUST consider the AXFR session is closed at any point, the AXFR client MUST consider the AXFR session
terminated. The message ID MAY be used again on a new connection, terminated. The message ID MAY be used again on a new connection,
even if the question and AXFR server are the same. Facing a dropped even if the question and AXFR server are the same. Facing a dropped
connection a client SHOULD try to make some determination whether the connection a client SHOULD try to make some determination whether the
connection closure was the result of network activity or a decision connection closure was the result of network activity or a decision
by the AXFR server. This determination is not an exact science. It by the AXFR server. This determination is not an exact science. It
is up to the AXFR client implementor to react, but the reaction is up to the AXFR client implementor to react, but the reaction
skipping to change at line 492 skipping to change at line 504
An AXFR server implementor SHOULD take into consideration the dilemma An AXFR server implementor SHOULD take into consideration the dilemma
described above when a connection is closed with an outstanding query described above when a connection is closed with an outstanding query
in the pipeline. For this reason, a server ought to reserve this in the pipeline. For this reason, a server ought to reserve this
course of action for situations in which it believes beyond a doubt course of action for situations in which it believes beyond a doubt
that the AXFR client is attempting abusive behavior. that the AXFR client is attempting abusive behavior.
3 Zone Contents 3 Zone Contents
The objective of the AXFR session is to request and transfer the The objective of the AXFR session is to request and transfer the
contents of a zone. The objective is to permit the client to contents of a zone. The objective is to permit the AXFR client to
reconstruct the zone as it exists at the server for the given zone reconstruct the zone as it exists at the server for the given zone
serial number. Over time the definition of a zone has evolved from a serial number. Over time the definition of a zone has evolved from
static set of records to a dynamically updated set of records to a denoting a static set of records to also cover a dynamically updated
continually regenerated set of records. set of records, and then a potentially continually regenerated set of
records as well.
3.1 Records to Include 3.1 Records to Include
In the answer section of AXFR response messages the resource records In the answer section of AXFR response messages the resource records
within a zone for the given serial number MUST appear. The definition within a zone for the given serial number MUST appear. The definition
of what belongs in a zone is described in RFC 1034, Section 4.2, "How of what belongs in a zone is described in RFC 1034, Section 4.2, "How
the database is divided into zones", and in particular, section 4.2.1, the database is divided into zones", in particular, section 4.2.1,
"Technical considerations". "Technical considerations", and it has been clarified in Section 6 of
RFC 2181.
Unless the AXFR server knows that the AXFR client expects just one Unless the AXFR server knows that the AXFR client is old and expects
resource record per AXFR response message, an AXFR server SHOULD just one resource record per AXFR response message, an AXFR server
populate an AXFR response message with as many complete resource SHOULD populate an AXFR response message with as many complete
records as will fit within a DNS message. resource record sets as will fit within a DNS message.
Zones for which it is impractical to list the entire zones for a serial Zones for which it is impractical to list the entire zones for a serial
number (because changes happen too quickly) are not suitable for AXFR number are not suitable for AXFR retrieval. A typical (but not
retrieval. A typical (but not limiting) description of such a zone limiting) description of such a zone is a zone consisting of responses
is a zone consisting of responses generated via other database lookups generated via other database lookups and/or computed based upon ever
and/or computed based upon ever changing data. In essence, if the changing data.
zone changes (on average) more frequently than and AXFR session can be
finished, the zone is not a good candidate for AXFR.
3.2 Delegation Records 3.2 Delegation Records
In RFC 1034, section 4.2.1, this text appears (keep in mind that the In RFC 1034, section 4.2.1, this text appears (keep in mind that the
"should" in the quotation predates [BCP14], cf. section 1.1) "The RRs "should" in the quotation predates [BCP14], cf. section 1.1) "The RRs
that describe cuts ... should be exactly the same as the corresponding that describe cuts ... should be exactly the same as the corresponding
RRs in the top node of the subzone." There has been some controversy RRs in the top node of the subzone." There has been some controversy
over this statement and the impact on which NS resource records are over this statement and the impact on which NS resource records are
included in a zone transfer. included in a zone transfer.
The phrase "that describe cuts" is a reference to the NS set and The phrase "that describe cuts" is a reference to the NS set and
applicable glue records. It does not mean that the cut points and the applicable glue records. It does not mean that the cut point and apex
apex resource records are identical. For example, the SOA resource resource records are identical. For example, the SOA resource record
record is only found at the apex, as well as DNSSEC resource records. is only found at the apex. The discussion here is restricted to just
The is even a DNSSEC resource record found only at the zone cut and not the NS resource record set and glue as these "describe cuts".
at the corresponding apex. There are also some DNSSEC resource record
sets that are explicitly different between the cut point and the apex. DNSSEC resource records have special specifications regarding their
The discussion here is restricted to just the NS resource record set occurrence at a zone cut and the apex of a zone. This has for the
and glue as these "describe cuts." first time been described in Sections 5.3 ff. and 6.2 of RFC 2181
(for the initial specification of DNSSEC), which now is historical.
The current DNSSEC core document set (see Note 2.2.2.e above) gives
the full details for DNSSEC(bis) resource record placement, and
Section 3.1.5 of RFC 4035 normatively specifies their treatment during
AXFR; the alternate NSEC3 resource record defined later in RFC 5155
behaves identically as the NSEC RR, for the purpose of AXFR.
Informally:
o The DS RRSet only occurs at the parental side of a zone cut and is
authoritative data in the parent zone, not the secure child zone.
o The DNSKEY RRSet only occurs at the APEX of a signed zone and is
authoritative part of the zone it serves.
o Independent RRSIG RRSets occur at the signed parent side and of a
zone cut and at the apex of a signed zone; they are authoritative
part of the respective zone; simple queries for RRSIG resource
records may return bth RRSets at once if the same server is
authoritative for the parent zone and the child zone (Section
3.1.5 of RFC 4035 describes how to distinguish these RRs); this
seeming ambiguity does not occur for AXFR, since each such RRSIG
RRset belongs to a single zone.
o Different NSEC [RFC4034] or NSEC3 [RFC5155] resource records
equally may occur at the parental siede of a zone cut and at the
apex of a zone; each such resource record belongs to exactly one
of these zones and is to be included in the AXFR of that zone.
The issue is that in operations there are times when the NS resource The issue is that in operations there are times when the NS resource
records for a zone might be different at a cut point in the parent and records for a zone might be different at a cut point in the parent and
at the apex of a zone. Sometimes this is the result of an error and at the apex of a zone. Sometimes this is the result of an error and
sometimes it is part of an ongoing change in name servers. The DNS sometimes it is part of an ongoing change in name servers. The DNS
protocol is robust enough to overcome inconsistencies up to (but not protocol is robust enough to overcome inconsistencies up to (but not
including) there being no parent indicated NS resource record including) there being no parent indicated NS resource record
referencing a server that is able to serve the child zone. This referencing a server that is able to serve the child zone. This
robustness is one quality that has fueled the success of the DNS. robustness is one quality that has fueled the success of the DNS.
Still, the inconsistency is an error state and steps need to be taken Still, the inconsistency is an error state and steps need to be taken
skipping to change at line 586 skipping to change at line 622
that is authoritative for both the cut point and the apex to a client that is authoritative for both the cut point and the apex to a client
that is not authoritative for both, the error is exposed. For example, that is not authoritative for both, the error is exposed. For example,
an authorized administrator can manually request the AXFR and inspect an authorized administrator can manually request the AXFR and inspect
the results to see the inconsistent records. (A server authoritative the results to see the inconsistent records. (A server authoritative
for both halves would otherwise always answer from the more for both halves would otherwise always answer from the more
authoritative set, concealing the error.) authoritative set, concealing the error.)
3) The inconsistent NS resource record set might indicate a problem 3) The inconsistent NS resource record set might indicate a problem
in a registration database. in a registration database.
4) Beginning with an error state of two servers for a zone having 4) This requirement is necessary to ensure that retrieving a given
inconsistent zone contents for a given zone serial number, if a client (zone,serial) pair by AXFR yields the exact same set of resource
requests and receives an IXFR transfer from one server followed by records no matter which of the zone's authoritative servers is
another IXFR transfer from the other server, the client can encounter chosen as the source of the transfer.
an IXFR protocol error state where an attempt is made to incrementally
add a record that already exists or to delete a record that does not
exist.
(Editorial note, the 4th reason was suggested, but I don't see how If an AXFR server were allowed to respond with the authoritative
it relates. A nudge for updated text on this.) NS RRset of a child zone instead of a glue NS RRset in the zone
being transferred, the set of records returned could vary depending
on whether or not the server happens to also be authoritative for
the child zone.
The property that a given (zone,serial) pair corresponds to a
single, well-defined set of records is necessary for the correct
operation of incremental transfer protocols such as IXFR
[RFC1995]. For example, a client may retrieve a zone by AXFR from
one server, and then apply an incremental change obtained by IXFR
from a different server. If the two servers have different ideas
of the zone contents, the client can end up attempting to
incrementally add records that already exist or to delete records
that do not exist.
3.3 Glue Records 3.3 Glue Records
As quoted in the previous section, section 4.2.1 of RFC 1034 provides As quoted in the previous section, section 4.2.1 of RFC 1034 provides
guidance and rationale for the inclusion of glue records as part of guidance and rationale for the inclusion of glue records as part of
an AXFR transfer. And, as also argued in the previous section of this an AXFR transfer. And, as also argued in the previous section of this
document, even when there is an inconsistency between the address in a document, even when there is an inconsistency between the address in a
glue record and the authoritative copy of the name server's address, glue record and the authoritative copy of the name server's address,
the glue resource record that is registered as part of the zone for the glue resource record that is registered as part of the zone for
that serial number is to be included. that serial number is to be included.
skipping to change at line 636 skipping to change at line 682
of name comparison in the DNS protocol and represents a new of name comparison in the DNS protocol and represents a new
requirement on AXFR servers. requirement on AXFR servers.
Rules governing name compression of RDATA in an AXFR message MUST Rules governing name compression of RDATA in an AXFR message MUST
abide by the specification in "Handling of Unknown DNS Resource Record abide by the specification in "Handling of Unknown DNS Resource Record
(RR) Types" [RFC3597], specifically, section 4 on "Domain Name (RR) Types" [RFC3597], specifically, section 4 on "Domain Name
Compression." Compression."
3.5 Occluded Names 3.5 Occluded Names
Dynamic Update [RFC2136] (and including DNAME [RFC2672]) operations can Dynamic Update [RFC2136] operations, and in particular its interaction
have a side effect of occluding names in a zone. The addition of a with DNAME [RFC2672], can have a side effect of occluding names in a
delegation point via dynamic update will render all subordinate domain zone. The addition of a delegation point via dynamic update will
names to be in a limbo, still part of the zone but not available render all subordinate domain names to be in a limbo, still part of
to the lookup process. The addition of a DNAME resource record has the the zone but not available to the lookup process. The addition of a
same impact. The subordinate names are said to be "occluded." DNAME resource record has the same impact. The subordinate names are
said to be "occluded."
Occluded names MUST be included in AXFR responses. An AXFR client MUST Occluded names MUST be included in AXFR responses. An AXFR client MUST
be able to identify and handle occluded names. The rationale for this be able to identify and handle occluded names. The rationale for this
action is based on a speedy recovery if the dynamic update operation action is based on a speedy recovery if the dynamic update operation
was in error and is to be undone. was in error and is to be undone.
4 Transport 4 Transport
AXFR sessions are currently restricted to TCP by section 4.3.5 of RFC AXFR sessions are currently restricted to TCP by section 4.3.5 of RFC
1034 that states: "Because accuracy is essential, TCP or some other 1034 that states: "Because accuracy is essential, TCP or some other
skipping to change at line 663 skipping to change at line 710
TCP is also mentioned in section 6.1.3.2. of "Requirements for Internet TCP is also mentioned in section 6.1.3.2. of "Requirements for Internet
Hosts - Application and Support" [RFC1123]. Hosts - Application and Support" [RFC1123].
The most common scenario is for an AXFR client to open a TCP connection The most common scenario is for an AXFR client to open a TCP connection
to the AXFR server, send an AXFR query, receive the AXFR response, and to the AXFR server, send an AXFR query, receive the AXFR response, and
then close the connection. There are variations on this, such as a then close the connection. There are variations on this, such as a
query for the zone's SOA resource record first, and so on. Note that query for the zone's SOA resource record first, and so on. Note that
this is documented as a most common scenario. this is documented as a most common scenario.
The assumption that a TCP connection is dedicated to the single AXFR The assumption that a TCP connection is dedicated to the single AXFR
session is incorrect, this as has led to implementation choices that session is incorrect, this has led to implementation choices that
prevent either multiple concurrent zone transfers or the use of the prevent either multiple concurrent zone transfers or the use of the
open connection for other queries. open connection for other queries.
Being able to have multiple concurrent zone transfers is considered Being able to have multiple concurrent zone transfers is considered
desirable by operators who have sets of name servers that are desirable by operators who have sets of name servers that are
authoritative for a common set of zones. It would be desirable authoritative for a common set of zones. It would be desirable
if the name server implementations did not have to wait for one if the name server implementations did not have to wait for one
zone to transfer before the next could begin. The desire here is to zone to transfer before the next could begin. The desire here is to
tighten the specification, not a change, but adding words to the tighten the specification, not a change, but adding words to the
unclear areas, to define what is needed to permit two servers to unclear areas, to define what is needed to permit two servers to
share a TCP connection among concurrent AXFR sessions. The challenge share a TCP connection among concurrent AXFR sessions. The challenge
is to design this in a way that can fall back to the old behavior if is to design this in a way that can fall back to the old behavior if
either the AXFR client or AXFR server is incapable of performing either the AXFR client or AXFR server is incapable of performing
multiple concurrent AXFR sessions. multiple concurrent AXFR sessions.
With the addition of EDNS0 and applications which require many With the addition of EDNS0 and applications which require many
small zones such as in web hosting and some ENUM scenarios, AXFR small zones such as in web hosting and some ENUM scenarios, AXFR
sessions on UDP are now possible and desirable. However, there sessions on UDP would now be possible and seem desirable. However,
are still some aspects of the AXFR session that are not easily there are still some aspects of the AXFR session that are not easily
translated to UDP. This document leaves AXFR over UDP undefined. translated to UDP. This document leaves AXFR over UDP undefined.
4.1 TCP 4.1 TCP
In the original definition there is an implicit assumption (probably In the original definition there is an implicit assumption (probably
unintentional) that a TCP connection is used for one and only one unintentional) that a TCP connection is used for one and only one
AXFR session. This is evidenced in no requirement to copy neither AXFR session. This is evidenced in no requirement to copy neither
the Query Section nor the message ID in responses, no explicit the Query Section nor the message ID in responses, no explicit
ordering information within the AXFR response messages and the lack ordering information within the AXFR response messages and the lack
of an explicit notice indicating that a zone transfer continues in the of an explicit notice indicating that a zone transfer continues in the
next message. next message.
The guidance given here is intended to enable better performance of The guidance given here is intended to enable better performance of
the AXFR exchange as well as guidelines on interactions with older the AXFR exchange as well as guidelines on interactions with older
software. Better performance includes being able to multiplex DNS software. Better performance includes being able to multiplex DNS
message exchanges including zone transfer sessions. Guidelines for message exchanges including zone transfer sessions. Guidelines for
interacting with older software are generally applicable to AXFR interacting with older software are generally applicable to new AXFR
clients as reversing the situation, older AXFR client and newer clients. In the reverse situation, older AXFR client and newer AXFR
AXFR server ought to induce the server to operate within the server ought to induce the server to operate within the specification
specification for an older server. for an older server.
4.1.1 AXFR client TCP 4.1.1 AXFR client TCP
An AXFR client MAY request an connection to an AXFR server for any An AXFR client MAY request a connection to an AXFR server for any
reason. An AXFR client SHOULD close the connection when there is reason. An AXFR client SHOULD close the connection when there is
no apparent need to use the connection for some time period. The no apparent need to use the connection for some time period. The
AXFR server ought not have to maintain idle connections, the burden AXFR server ought not have to maintain idle connections, the burden
of connection closure ought to be on the client. Apparent need for of connection closure ought to be on the client. Apparent need for
the connection is a judgment for the AXFR client and the DNS the connection is a judgment for the AXFR client and the DNS
client. If the connection is used for multiple sessions, or if it is client. If the connection is used for multiple sessions, or if it is
known sessions will be coming or if there is other query/response known sessions will be coming or if there is other query/response
traffic anticipated or currently on the open connection, then there traffic anticipated or currently on the open connection, then there
is "apparent need." is "apparent need."
An AXFR client MAY cancel delivery of a zone only by closing the An AXFR client MAY cancel delivery of a zone only by closing the
connection. However, this action will also cancel all other outstanding connection. However, this action will also cancel all other outstanding
activity using the connection. There is no other mechanism by which activity using the connection. There is no other mechanism by which
an AXFR response can be cancelled. an AXFR response can be cancelled.
When a TCP connection is closed remotely (relative to the client), When a TCP connection is closed remotely (relative to the client),
whether by the AXFR server or due to a network event, the AXFR client whether by the AXFR server or due to a network event, the AXFR client
MUST cancel all outstanding sessions. Recovery from this situation MUST cancel all outstanding sessions and non-AXFR transactions.
is not straightforward. If the disruption was a spurious event, Recovery from this situation is not straightforward. If the disruption
attempting to restart the connection would be proper. If the was a spurious event, attempting to restart the connection would be
disruption was caused by a medium or long term disruption, the AXFR proper. If the disruption was caused by a medium or long term
client would be wise to not spend too many resources trying to rebuild disruption, the AXFR client would be wise to not spend too many
the connection. Finally, if the connection was dropped because of a resources trying to rebuild the connection. Finally, if the connection
policy at the AXFR server (as can be the case with older AXFR servers), was dropped because of a policy at the AXFR server (as can be the case
the AXFR client would be wise to not retry the connection. with older AXFR servers), the AXFR client would be wise to not retry
Unfortunately, knowing which of the three cases above applies is not the connection. Unfortunately, knowing which of the three cases above
clear (momentary disruption, failure, policy). (momentary disruption, failure, policy) applies is not possible with
certainty, and can only be assessed by heuristics.
An AXFR client MAY use an already opened TCP connection to start an An AXFR client MAY use an already opened TCP connection to start an
AXFR session. Using an existing open connection is RECOMMENDED over AXFR session. Using an existing open connection is RECOMMENDED over
opening a new connection. (Non-AXFR session traffic can also use an opening a new connection. (Non-AXFR session traffic can also use an
open connection.) If in doing so the AXFR client realizes that open connection.) If in doing so the AXFR client realizes that
the responses cannot be properly differentiated (lack of matching the responses cannot be properly differentiated (lack of matching
query IDs for example) or the connection is terminated for a remote query IDs for example) or the connection is terminated for a remote
reason, then the AXFR client SHOULD NOT attempt to reuse an open reason, then the AXFR client SHOULD NOT attempt to reuse an open
connection with the specific AXFR server until the AXFR server is connection with the specific AXFR server until the AXFR server is
updated (which is of course, not an event captured in the DNS updated (which is of course, not an event captured in the DNS
protocol). protocol).
4.1.2 AXFR server TCP 4.1.2 AXFR server TCP
An AXFR server MUST be able to handle multiple AXFR sessions on a An AXFR server MUST be able to handle multiple AXFR sessions on a
single TCP connection, as well as handle other query/response sessions. single TCP connection, as well as handle other query/response
transactions.
If a TCP connection is closed remotely, the AXFR server MUST cancel If a TCP connection is closed remotely, the AXFR server MUST cancel
all AXFR sessions in place. No retry activity is necessary, that is all AXFR sessions in place. No retry activity is necessary; that is
initiated by the AXFR client. initiated by the AXFR client.
Local policy MAY dictate that a TCP connection is to be closed. Such Local policy MAY dictate that a TCP connection is to be closed. Such
as action SHOULD be in reaction to limits such as those placed on an action SHOULD be in reaction to limits such as those placed on
the number of outstanding open connections. Closing a connection in the number of outstanding open connections. Closing a connection in
response to a suspected security event SHOULD be done only in extreme response to a suspected security event SHOULD be done only in extreme
cases, when the server is certain the action is warranted. An cases, when the server is certain the action is warranted. An
isolated request for a zone not on the AXFR server SHOULD receive isolated request for a zone not on the AXFR server SHOULD receive
a response with the appropriate return code and not see the connection a response with the appropriate return code and not see the connection
broken. broken.
4.2 UDP 4.2 UDP
AXFR sessions over UDP transport are not defined. AXFR sessions over UDP transport are not defined.
skipping to change at line 799 skipping to change at line 848
controls based upon "Secret Key Transaction Authentication for DNS" controls based upon "Secret Key Transaction Authentication for DNS"
[RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )"
[RFC2931]. [RFC2931].
A general purpose implementation SHOULD allow access to be open to A general purpose implementation SHOULD allow access to be open to
all AXFR requests. I.e., an operator ought to be able to allow any all AXFR requests. I.e., an operator ought to be able to allow any
AXFR query to be granted. AXFR query to be granted.
A general purpose implementation SHOULD NOT have a default policy A general purpose implementation SHOULD NOT have a default policy
for AXFR requests to be "open to all." For example, a default could for AXFR requests to be "open to all." For example, a default could
be to restrict transfers to loopback address(es) and such. be to restrict transfers to addresses selected by the DNS
administrator(s) for zones on the server.
6 Zone Integrity 6 Zone Integrity
An AXFR client MUST ensure that only a successfully transferred An AXFR client MUST ensure that only a successfully transferred
copy of the zone data can be used to serve this zone. Previous copy of the zone data can be used to serve this zone. Previous
description and implementation practice have introduced a two-stage description and implementation practice have introduced a two-stage
model of the whole zone synchronization procedure: Upon a trigger model of the whole zone synchronization procedure: Upon a trigger
event (e.g., polling of SOA resource record detects change in the event (e.g., polling of SOA resource record detects change in the
SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session
is initiated, whereby the zone data are saved in a zone file or is initiated, whereby the zone data are saved in a zone file or
skipping to change at line 821 skipping to change at line 871
restart of the server); upon successful completion of the AXFR restart of the server); upon successful completion of the AXFR
operation and some sanity checks, this data set is 'loaded' and operation and some sanity checks, this data set is 'loaded' and
made available for serving the zone in an atomic operation, and made available for serving the zone in an atomic operation, and
flagged 'valid' for use during the next restart of the DNS server; flagged 'valid' for use during the next restart of the DNS server;
if any error is detected, this data set MUST be deleted, and the if any error is detected, this data set MUST be deleted, and the
AXFR client MUST continue to serve the previous version of the zone, AXFR client MUST continue to serve the previous version of the zone,
if it did before. The externally visible behavior of an AXFR client if it did before. The externally visible behavior of an AXFR client
implementation MUST be equivalent to that of this two-stage model. implementation MUST be equivalent to that of this two-stage model.
If a server rejects data contained in an AXFR session, the server If a server rejects data contained in an AXFR session, the server
SHOULD remember the serial number and not attempt to retrieve the SHOULD remember the serial number and MAY attempt to retrieve the
same zone version again. same zone version again. The reason the same retrieval could make
sense is that the reason for the rejection could be rooted in an
implementation detail of one AXFR server used for the zone and not
in another AXFR server used for the zone.
Ensuring that an AXFR client does not accept a forged copy of a zone is Ensuring that an AXFR client does not accept a forged copy of a zone is
important to the security of a zone. If a zone operator has the important to the security of a zone. If a zone operator has the
opportunity, protection can be afforded via dedicated links, physical opportunity, protection can be afforded via dedicated links, physical
or virtual via a VPN among the authoritative servers. But there are or virtual via a VPN among the authoritative servers. But there are
instances in which zone operators have no choice but to run AXFR instances in which zone operators have no choice but to run AXFR
sessions over the global public Internet. sessions over the global public Internet.
Besides best attempts at securing TCP sessions, DNS implementations Besides best attempts at securing TCP connections, DNS implementations
SHOULD provide means to make use of "Secret Key Transaction SHOULD provide means to make use of "Secret Key Transaction
Authentication for DNS" [RFC2845] and/or "DNS Request and Transaction Authentication for DNS" [RFC2845] and/or "DNS Request and Transaction
Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients to verify the Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients to verify the
contents. These techniques MAY also be used for authorization. contents. These techniques MAY also be used for authorization.
7 Zone Expiry Timer 7 Backwards Compatibility
Section 4.3.5 of RFC 1034 contains the following paragraph:
"The periodic polling of the secondary servers is controlled by
parameters in the SOA RR for the zone, which set the minimum acceptable
polling intervals. The parameters are called REFRESH, RETRY, and
EXPIRE. Whenever a new zone is loaded in a secondary, the secondary
waits REFRESH seconds before checking with the primary for a new serial.
If this check cannot be completed, new checks are started every RETRY
seconds. The check is a simple query to the primary for the SOA RR of
the zone. If the serial field in the secondary's zone copy is equal to
the serial returned by the primary, then no changes have occurred, and
the REFRESH interval wait is restarted. If the secondary finds it
impossible to perform a serial check for the EXPIRE interval, it must
assume that its copy of the zone is obsolete an discard it."
Perhaps what is not clear in the paragraph regarding the EXPIRE
interval timer is that it is only reset to the EXPIRE parameter when
a new zone is loaded. A new zone means a zone with a higher serial
number than the most recently loaded zone. The EXPIRE interval timer
is not reset automatically as a result of a zone transfer as a zone
could be (mistakenly) transferred with the same or lower serial number.
I.e., successively transferring a zone from server to server does not
permit the zone to avoid expiration.
8 Backwards Compatibility
Describing backwards compatibility is difficult because of the lack of Describing backwards compatibility is difficult because of the lack of
specifics in the original definition. In this section some hints at specifics in the original definition. In this section some hints at
building in backwards compatibility are given, mostly repeated from the building in backwards compatibility are given, mostly repeated from the
earlier sections. earlier sections.
Backwards compatibility is not necessary, but the greater extent of an Backwards compatibility is not necessary, but the greater the extent of
implementation's compatibility increases it's interoperability. For an implementation's compatibility the greater it's interoperability.
turnkey implementations this is not usually a concern. For general For turnkey implementations this is not usually a concern. For general
purpose implementations this takes on varying levels of importance purpose implementations this takes on varying levels of importance
depending on the implementer's desire to maintain interoperability. depending on the implementer's desire to maintain interoperability.
It is unfortunate that a need to fall back to older behavior cannot be It is unfortunate that a need to fall back to older behavior cannot be
discovered, hence needs to be noted in a configuration file. An discovered, hence needs to be noted in a configuration file. An
implementation SHOULD, in it's documentation, encourage operators to implementation SHOULD, in it's documentation, encourage operators to
periodically review AXFR clients and servers it has made notes about as periodically review AXFR clients and servers it has made notes about as
old software periodically gets updated. old software periodically gets updated.
8.1 Server 7.1 Server
An AXFR server has the luxury of being able to react to an AXFR An AXFR server has the luxury of being able to react to an AXFR
client's abilities with the exception of knowing if the client can client's abilities with the exception of knowing if the client can
accept multiple resource records per AXFR response message. The accept multiple resource records per AXFR response message. The
knowledge that a client is so restricted apparently cannot be knowledge that a client is so restricted apparently cannot be
discovered, hence it has to be set by configuration. discovered, hence it has to be set by configuration.
An implementation of an AXFR server SHOULD permit configuring, on a per An implementation of an AXFR server MAY permit configuring, on a per
AXFR client basis, a need to revert to single resource record per AXFR client basis, a need to revert to single resource record per
message. The default SHOULD be to use multiple records per message. message; in that case, the default SHOULD be to use multiple records
8.2 Client 7.2 Client
An AXFR client has the opportunity to try extensions when querying An AXFR client has the opportunity to try other features (i.e., those
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.
9 Security Considerations 8 Security Considerations
Concerns regarding authorization, traffic flooding, and message Concerns regarding authorization, traffic flooding, and message
integrity are mentioned in "Authorization" (section 5), "TCP" (section integrity are mentioned in "Authorization" (section 5), "TCP" (section
4.2) and "Zone Integrity" (section 6). 4.2) and "Zone Integrity" (section 6).
10 IANA Considerations 9 IANA Considerations
No new registries or new registrations are included in this document. No new registries or new registrations are included in this document.
11 Internationalization Considerations 10 Internationalization Considerations
It is assumed that supporting of international domain names has been The AXFR protocol is transparent to the parts of DNS zone content that
can possibly be subject to Internationalization considerations.
It is assumed that for DNS labels and domain names, the issue has been
solved via "Internationalizing Domain Names in Applications (IDNA)" solved via "Internationalizing Domain Names in Applications (IDNA)"
[RFC3490]. [RFC3490].
12 Acknowledgements 11 Acknowledgements
Earlier editions of this document have been edited by Andreas Earlier editions of this document have been edited by Andreas
Gustafsson. In his latest version, this acknowledgement appeared. Gustafsson. In his latest version, this acknowledgement appeared.
"Many people have contributed input and commentary to earlier versions "Many people have contributed input and commentary to earlier versions
of this document, including but not limited to Bob Halley, Dan of this document, including but not limited to Bob Halley, Dan
Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz, Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz,
Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam Trenholme, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam Trenholme,
and Brian Wellington." and Brian Wellington."
Comments since the -05 version have come from these individuals: Comments since the -05 version have come from these individuals:
Alfred Hoenes, Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Alfred Hoenes, Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain
Calder, Tony Finch, Ian Jackson, Andreas Gustafsson, Brian Wellington, Calder, Tony Finch, Ian Jackson, Andreas Gustafsson, Brian Wellington,
... and other participants of the DNSEXT working group.
13 References 12 References
All references prefixed by "RFC" can be obtained from the RFC Editor All references prefixed by "RFC" can be obtained from the RFC Editor
web site at the URLs: http://rfc-editor.org/rfc.html web site at the URLs: http://rfc-editor.org/rfc.html
or http://rfc-editor.org/rfcsearch.html ; or http://rfc-editor.org/rfcsearch.html ;
information regarding this organization can be found at the following information regarding this organization can be found at the following
URL: http://rfc-editor.org/ URL: http://rfc-editor.org/
13.1 Normative 12.1 Normative
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980. 1980.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996. August 1996.
[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., Ed., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC
2136, April 1997. 2136, April 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999. August 1999.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
August 1999. August 1999.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000. (TSIG)", RFC 2845, May 2000.
[RFC5395] Eastlake 3rd, "Domain Name System (DNS) IANA Considerations", [RFC5395] Eastlake 3rd, "Domain Name System (DNS) IANA Considerations",
BCP 42, RFC 5395, November 2008. BCP 42, RFC 5395, November 2008.
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
skipping to change at line 987 skipping to change at line 1017
( SIG(0)s )", RFC 2931, September 2000. ( SIG(0)s )", RFC 2931, September 2000.
[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 2002. [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 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.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC 4033, Rose, "DNS Security Introduction and Requirements", RFC 4033,
March 2005. March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Existence",
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication
Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", Code, Secure Hash Algorithm) TSIG Algorithm Identifiers",
RFC 4635, August 2006. RFC 4635, August 2006.
[DNSFLGS] http://www.iana.org/assignments/dns-header-flags [DNSFLGS] http://www.iana.org/assignments/dns-header-flags
[DNSVALS] http://www.iana.org/assignments/dns-parameters [DNSVALS] http://www.iana.org/assignments/dns-parameters
13.2 Informative 12.2 Informative
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1700] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700, [RFC1700] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700,
October 1994. October 1994.
[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 Networks", Malis, "A Framework for IP Based Virtual Private Networks",
RFC 2764, February 2000. 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)", RFC "Internationalizing Domain Names in Applications (IDNA)", RFC
3490, March 2003. 3490, March 2003.
[DRAFT1] Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY and
RRSIG Resource Records for DNSSEC",
draft-ietf-dnsext-dnssec-rsasha256-12, work in progress.
[DRAFT2] Weiler, S., and D. Blacka, "Clarifications and Implementation
Notes for DNSSECbis",
draft-ietf-dnsext-dnssec-bis-updates-08, work in progress.
14 Editor's Address 13 Editor's Address
Edward Lewis Edward Lewis
46000 Center Oak Plaza 46000 Center Oak Plaza
Sterling, VA, 22033, US Sterling, VA, 22033, US
+1-571-434-5468 +1-571-434-5468
ed.lewis@neustar.biz ed.lewis@neustar.biz
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 62 change blocks. 
158 lines changed or deleted 199 lines changed or added

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