+++ /dev/null
-DNS Extensions Working Group Edward Lewis
-INTERNET-DRAFT NeuStar, Inc.
-Expires: Octopber 1, 2009 April 2009
-Updates: 1034, 1035 (if approved)
-Intended status: Standards Track
-
- DNS Zone Transfer Protocol (AXFR)
- draft-ietf-dnsext-axfr-clarify-11.txt
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- This Internet-Draft will expire on October 1, 2009.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with
- respect to this document.
-
-Abstract
-
-The Domain Name System standard mechanisms for maintaining coherent
-servers for a zone consist of three elements. One mechanism is the
-Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035.
-The definition of AXFR, has proven insufficient in detail, forcing
-implementations intended to be compliant to make assumptions, impeding
-interoperability. Yet today we have a satisfactory set of
-implementations that do interoperate. This document is a new
-definition of the AXFR, new in the sense that is it recording an
-accurate definition of an interoperable AXFR mechanism.
-
-1 Introduction
-
-The Domain Name System standard facilities for maintaining coherent
-servers for a zone consist of three elements. Authoritative
-Transfer (AXFR) is defined in "Domain Names - Concepts and Facilities"
-[RFC1034] (referred to in this document as RFC 1034) and "Domain Names
-- Implementation and Specification" [RFC1035] (aka RFC 1035).
-Incremental Zone Transfer (IXFR) is defined in "Incremental Zone
-Transfer in DNS" [RFC1995]. A mechanism for prompt notification of
-zone changes (NOTIFY) is defined in "A Mechanism for Prompt
-Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The goal of
-these mechanisms is to enable a set of DNS name servers to remain
-coherently authoritative for a given zone.
-
-Comments on this draft ought to be addressed to the editor or to
-namedroppers@ops.ietf.org.
-
-1.1 Definition of Terms
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in "Key words for use in
-RFCs to Indicate Requirement Levels" [BCP14].
-
-"Newer"/"New" DNS and "older"/"old" DNS refers to implementations
-written after and prior to the publication of this document.
-
-1.2 Scope
-
-In the greater context there are many ways to achieve coherency among
-a set of name servers. The AXFR, IXFR and NOTIFY mechanisms form
-just one, the one defined in the RFCs cited. For example, there are
-DNS implementations that assemble answers from data stored in
-relational databases (as opposed to master files) relying on the
-database's non-DNS means to synchronize the database instances. Some
-of these non-DNS solutions interoperate in some fashion. As far as
-it is known, AXFR, IXFR and NOTIFY are the only in-band mechanisms
-that provide an interoperable solution to the desire for coherency
-within the definition of DNS, they certainly are the only mechanisms
-documented by the IETF.
-
-This document does not cover incoherent DNS situations. There are
-applications of the DNS in which servers for a zone are designed to be
-incoherent. For these configurations, a coherency mechanism as
-described here would be unsuitable.
-
-"General purpose DNS implementation" refers to DNS software developed
-for wide-spread use. This includes resolvers and servers freely
-accessible as libraries and standalone processes. This also includes
-proprietary implementations used only in support of DNS service
-offerings.
-
-"Turnkey DNS implementation" refers to custom made, single use
-implementations of DNS. Such implementations consist of software
-that employs the DNS protocol message format yet do not conform to
-the entire range of DNS functionality.
-
-A DNS implementation is not required to support AXFR, IXFR and NOTIFY.
-A DNS implementation SHOULD have some means for maintaining name server
-coherency. A general purpose DNS implementation SHOULD include AXFR
-(and in the same vein IXFR and NOTIFY), but turnkey DNS implementations
-MAY exist without AXFR. (An editorial note to readers of this section.
-The mention of IXFR and NOTIFY is for context and illustration, this
-document does not make any normative comments on those mechanisms.)
-
-1.3 Context
-
-Besides describing the mechanisms themselves, there is the context in
-which they operate to consider. When AXFR, IXFR and NOTIFY were
-defined, there was little consideration given to security and privacy
-issues. Since the original definition of AXFR, new opinions have
-appeared on the access to an entire zone's contents. In this document,
-the basic mechanisms will be discussed separately from the permission
-to use these mechanisms.
-
-1.4 Coverage and Relationship to Original AXFR Specification
-
-This document concentrates on just the definition of AXFR. Any effort
-to update the IXFR or NOTIFY mechanisms would be done in different
-documents.
-
-The original "specification" of the AXFR sub-protocol is scattered
-through RFC 1034 and RFC 1035. Section 2.2 of RFC 1035 on page 5
-depicts the scenario for which AXFR has been designed. Section 4.3.5
-of RFC 1034 describes the zone synchronization strategies in general
-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
-AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant
-flaw in that specification. Section 3.2.3 of RFC 1035 has assigned
-the code point for the AXFR QTYPE (see section 2.1.2 below for more
-details). Section 4.2 of RFC 1035 discusses the transport layer use
-of DNS and shortly explains why UDP transport is deemed inappropriate
-for AXFR; the last paragraph of Section 4.2.2 gives details for the
-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.
-
-This document will update the specification of AXFR in fully
-specifying the record formats and processing rules for AXFR, largely
-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
-RFC 1035. Furthermore, it discusses backward compatibility issues
-and provides policy/management considerations as well as specific
-Security Considerations for AXFR. The goal of this document is to
-define AXFR as it exists, or is supposed to exist, currently.
-
-2 AXFR Messages
-
-An AXFR session consists of an AXFR query message and the sequence of
-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
-responder. (Use of terms such as master, slave, primary, secondary
-are not important to defining AXFR.) The use of the word "session"
-without qualification refers to an AXFR session.
-
-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
-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
-RFC 1035, Section 4 ("MESSAGES") [RFC1035], updated by the following:
-- "A Mechanism for Prompt Notification of Zone Changes (...)" [RFC1996]
-- "Domain Name System (DNS) IANA Considerations" [RFC5395]
-- "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136]
-- "Clarifications to the DNS Specification" [RFC2181]
-- "Extension Mechanisms for DNS (EDNS0)" [RFC2671]
-- "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845]
-- "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]
-- "Obsoleting IQUERY" [RFC3425]
-- "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]
-- "Use of SHA-256 in DNSSEC ... (DS) ... (RRs)" [RFC4509]
-- "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
-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
-unsigned, and thus causing a limit of 65535 octets. Unlike DNS
-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
-appear in the IANA registry for DNS Header Flags [DNSFLGS].
-
-2.1 AXFR query
-
-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
-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
-
-These are the DNS message header values for an AXFR query.
-
-ID See note 2.1.1.a
-QR MUST be 0 (Query)
-OPCODE MUST be 0 (Standard Query)
-AA See note 2.1.1.b
-TC See note 2.1.1.b
-RD See note 2.1.1.b
-RA See note 2.1.1.b
-Z See note 2.1.1.c
-AD See note 2.1.1.b
-CD See note 2.1.1.b
-RCODE MUST be 0 (No error)
-QDCOUNT MUST be 1
-ANCOUNT MUST be 0
-NSCOUNT MUST be 0
-ARCOUNT See note 2.1.1.d
-
-Note 2.1.1.a Set to any value that the client is not already using
-with the same server. There is no specific means for selecting the
-value in this field. (Recall that AXFR is done only via TCP
-connections.)
-
-A server MUST reply using messages that use the same message ID to
-allow a client to meaningfully have multiple AXFR queries outstanding.
-
-Note 2.1.1.b The value in this field has no meaning in the context of
-AXFR query messages. For the client, it is RECOMMENDED that the
-value be zero. The server MUST ignore this value.
-
-Note 2.1.1.c The client MUST set this bit to 0, the server MUST ignore
-it.
-
-Note 2.1.1.d The client MUST set this field to be the number of
-resource records appearing in the additional section. See Section
-2.1.5 "Additional Section" for details.
-
-The value MAY be 0, 1 or 2. If it is 2, the additional
-section MUST contain both an EDNS0 [RFC2671] OPT resource record and
-a record carrying transaction integrity and authentication data,
-currently a choice of TSIG [RFC2845] and SIG(0) [RFC2931]. If the
-value is 1, then the additional section MUST contain either only an
-EDNS0 OPT resource record or a record carrying transaction integrity
-and authentication data. If the value is 0, the additional section
-MUST be empty.
-
-2.1.2 Query Section
-
-The Query section of the AXFR query MUST conform to section 4.1.2 of
-RFC 1035, and contain the following values:
-
-QNAME the name of the zone requested
-QTYPE AXFR(= 252), the pseudo-RR type for zone transfer [DNSVALS]
-QCLASS the class of the zone requested
-
-2.1.3 Answer Section
-
-MUST be empty.
-
-2.1.4 Authority Section
-
-MUST be empty.
-
-2.1.5 Additional Section
-
-The client MAY include an EDNS0 OPT [RFC2671] resource record. If the
-server has indicated that it does not support EDNS0, the client MUST
-send this section without an EDNS0 OPT resource record if there is a
-retry. Indication that a server does not support EDNS0 is not an
-explicit element in the protocol, it is up to the client to interpret.
-Most likely, the server will return a FORMERR which might be related to
-the OPT resource record.
-
-The client MAY include a transaction integrity and authentication
-resource record, currently a choice of TSIG [RFC2845] or SIG(0)
-[RFC2931]. If the server has indicated that it does not recognize the
-resource record, and that the error is indeed caused by the resource
-record, the client probably ought not try again. Removing the security
-data in the face of an obstacle ought to only be done with full
-awareness of the implication of doing so.
-
-In general, if an AXFR client is aware that an AXFR server does not
-support a particular mechanism, the client SHOULD NOT attempt to engage
-the server using the mechanism (or at all). A client could become
-aware of a server's abilities via a configuration setting or via some
-other (as yet) undefined means.
-
-The range of permissible resource records that MAY appear in the
-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 additional section record is created, the new definitions ought
-to include a discussion on the impact upon AXFR. Although this is not
-predictable, future additional section residing records may have 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 able
-to pass these records through without disruption.
-
-2.2 AXFR response
-
-The AXFR response will consist of 0 or more messages. A "0 message"
-response is covered in section 2.2.1.
-
-An AXFR response that is transferring the zone's contents will consist
-of a series (which could be a series of length 1) of DNS messages.
-In such a series, the first message MUST begin with the SOA
-resource record of the zone, the last message MUST conclude with the
-same SOA resource record. Intermediate messages MUST NOT contain the
-SOA resource record. The first message MUST copy the Query Section
-from the corresponding AXFR query message in to the first response
-message's query section. Subsequent messages MAY do the same.
-
-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
-condition encountered - once the error condition is detected. Such
-a message MUST terminate the AXFR session; it MUST copy the Query
-Section from the AXFR query into its Query Section, but the inclusion
-of the terminating SOA resource record is not necessary.
-
-An AXFR client might receive a number of AXFR response messages
-free of an error condition before the message indicating an error
-is received.
-
-2.2.1 "0 Message" Response
-
-A legitimate "0 message" response, i.e., the client sees no response
-whatsoever, is very exceptional and controversial. Unquestionably it
-is unhealthy for there to be 0 responses in a protocol that is designed
-around a query - response paradigm over an unreliable transport. The
-lack of a response could be a sign of underlying network problems and
-cause the protocol state machine to react accordingly. However, AXFR
-uses TCP and not UDP, eliminating undetectable network errors.
-
-A "0 message response" is reserved for situations in which the server
-has a reason to suspect that the query is sent for the purpose of
-abuse. Due to the use of this being so controversial, a "0 message
-response" is not being defined as a legitimate part of the protocol
-but the use of it is being acknowledged as a warning to AXFR client
-implementations. Any earnest query has the expectation of some
-response but may not get one.
-
-2.2.2 Header Values
-
-ID See note 2.2.2.a
-QR MUST be 1 (Response)
-OPCODE MUST be 0 (Standard Query)
-AA See note 2.2.2.b
-TC MUST be 0 (Not truncated)
-RD RECOMMENDED copy request's value, MAY be set to 0
-RA See note 2.2.2.c
-Z See note 2.2.2.d
-AD See note 2.2.2.e
-CD See note 2.2.2.e
-RCODE See note 2.2.2.f
-QDCOUNT MUST be 1 in the first message; MUST be 0 or 1 in all
- following
-ANCOUNT See note 2.2.2.g
-NSCOUNT MUST be 0
-ARCOUNT See note 2.2.2.h
-
-Note 2.2.2.a Because some old implementations behave differently than
-is now desired, the requirement on this field is stated in detail.
-New DNS servers MUST set this field to the value of the AXFR query
-ID in each AXFR response message for the session. AXFR clients MUST
-be able to manage sessions resulting from the issuance of multiple
-outstanding queries, whether AXFR queries or other DNS queries. A
-client SHOULD discard responses that do not correspond (via the
-message ID) to any outstanding queries.
-
-Unless the client is sure that the server will consistently set the ID
-field to the query's ID, the client is NOT RECOMMENDED to issue any
-other queries until the end of the zone transfer. A client MAY become
-aware of a server's abilities via a configuration setting.
-
-Note 2.2.2.b If the RCODE is 0 (no error), then the AA bit MUST be 1.
-For any other value of RCODE, the AA bit MUST be set according to rules
-for that error code. If in doubt, it is RECOMMENDED that it be set
-to 1. It is RECOMMENDED that the value be ignored by the AXFR client.
-
-Note 2.2.2.c It is RECOMMENDED that the server set the value to 0,
-the client MUST ignore this value.
-
-The server MAY set this value according to the local policy regarding
-recursive service, but doing so might confuse the interpretation of the
-response as AXFR can not be retrieved recursively. A client MAY note
-the server's policy regarding recursive service from this value, but
-SHOULD NOT conclude that the AXFR response was obtained recursively
-even if the RD bit was 1 in the query.
-
-Note 2.2.2.d The server MUST set this bit to 0, the client MUST ignore
-it.
-
-Note 2.2.2.e If the implementation supports the DNS Security Extensions
-(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".
-If the implementation does not support the DNS Security Extensions,
-then this value MUST be set to 0 and MUST be ignored upon receipt.
-
-The DNS Security Extensions (DNSSEC) is defined in these base
-documents:
-- "DNS Security Introduction and Requirements" [RFC4033]
-- "Resource Records for the DNS Security Extensions" [RFC4034]
-- "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
-of this field to NoError. If a server is not authoritative for the
-queried zone, the server SHOULD set the value to NotAuth. (Reminder,
-consult the appropriate IANA registry [DNSVALS].) If a client
-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
-OPT resource record sent to an old server will garner a FormErr value.
-This value is not set as part of the AXFR-specific response processing.
-The same is true for other error-indicating values.
-
-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
-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
-client's limitations via configuration data.
-
-Note 2.2.2.h The client MUST set this field to be the number of
-resource records appearing in the additional section. The
-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
-
-In the first response message, this section MUST 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
-determine the context of the message, that is, the name of the zone
-being transferred.
-
-2.2.4 Answer Section
-
-MUST be populated with the zone contents. See later section on
-encoding zone contents.
-
-2.2.5 Authority Section
-
-MUST be empty.
-
-2.2.6 Additional Section
-
-The contents of this section MUST follow the guidelines for EDNS0,
-TSIG, SIG(0), or what ever other future record is possible here. The
-contents of section 2.1.5 apply here as well.
-
-2.3 TCP Connection Aborts
-
-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
-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
-connection a client SHOULD try to make some determination whether the
-connection closure was the result of network activity or a decision
-by the AXFR server. This determination is not an exact science. It
-is up to the AXFR client implementor to react, but the reaction
-SHOULD NOT be an endless cycle of retries nor an increasing (in
-frequency) retry rate.
-
-An AXFR server implementor SHOULD take into consideration the dilemma
-described above when a connection is closed with an outstanding query
-in the pipeline. For this reason, a server ought to reserve this
-course of action for situations in which it believes beyond a doubt
-that the AXFR client is attempting abusive behavior.
-
-3 Zone Contents
-
-The objective of the AXFR session is to request and transfer the
-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
-serial number. Over time the definition of a zone has evolved from
-denoting a static set of records to also cover a dynamically updated
-set of records, and then a potentially continually regenerated set of
-records as well.
-
-3.1 Records to Include
-
-In the answer section of AXFR response messages the resource records
-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
-the database is divided into zones", in particular, section 4.2.1,
-"Technical considerations", and it has been clarified in Section 6 of
-RFC 2181.
-
-Unless the AXFR server knows that the AXFR client is old and expects
-just one resource record per AXFR response message, an AXFR server
-SHOULD populate an AXFR response message with as many complete
-resource record sets as will fit within a DNS message.
-
-Zones for which it is impractical to list the entire zones for a serial
-number are not suitable for AXFR retrieval. A typical (but not
-limiting) description of such a zone is a zone consisting of responses
-generated via other database lookups and/or computed based upon ever
-changing data.
-
-3.2 Delegation Records
-
-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
-that describe cuts ... should be exactly the same as the corresponding
-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
-included in a zone transfer.
-
-The phrase "that describe cuts" is a reference to the NS set and
-applicable glue records. It does not mean that the cut point and apex
-resource records are identical. For example, the SOA resource record
-is only found at the apex. The discussion here is restricted to just
-the NS resource record set and glue as these "describe cuts".
-
-DNSSEC resource records have special specifications regarding their
-occurrence at a zone cut and the apex of a zone. This has for the
-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
-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
-sometimes it is part of an ongoing change in name servers. The DNS
-protocol is robust enough to overcome inconsistencies up to (but not
-including) there being no parent indicated NS resource record
-referencing a server that is able to serve the child zone. This
-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
-to make it apparent (if it is unplanned) and to make it clear once
-the inconsistency has been removed.
-
-Another issue is that the AXFR server could be authoritative for a
-different set of zones than the AXFR client. It is possible that the
-AXFR server be authoritative for both halves of an inconsistent cut
-point and that the AXFR client is authoritative for just the parent of
-the cut point.
-
-The question that arises is, when facing a situation in which a cut
-point's NS resource records do not match the authoritative set, whether
-an AXFR server responds with the NS resource record set that is in the
-zone being transferred or is at the authoritative location.
-
-The AXFR response MUST contain the cut point NS resource record set
-registered with the zone whether it agrees with the authoritative set
-or not. "Registered with" can be widely interpreted to include data
-residing in the zone file of the zone for the particular serial
-number (in zone file environments) or as any data configured to be in
-the zone (database), statically or dynamically.
-
-The reasons for this requirement are:
-
-1) The AXFR server might not be able to determine that there is an
-inconsistency given local data, hence requiring consistency would mean
-a lot more needed work and even network retrieval of data. An
-authoritative server ought not be required to perform any queries.
-
-2) By transferring the inconsistent NS resource records from a server
-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,
-an authorized administrator can manually request the AXFR and inspect
-the results to see the inconsistent records. (A server authoritative
-for both halves would otherwise always answer from the more
-authoritative set, concealing the error.)
-
-3) The inconsistent NS resource record set might indicate a problem
-in a registration database.
-
-4) This requirement is necessary to ensure that retrieving a given
-(zone,serial) pair by AXFR yields the exact same set of resource
-records no matter which of the zone's authoritative servers is
-chosen as the source of the transfer.
-
-If an AXFR server were allowed to respond with the authoritative
-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
-
-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
-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
-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
-that serial number is to be included.
-
-This applies to glue records for any address family [RFC1700].
-
-The AXFR response MUST contain the appropriate glue records as
-registered with the zone. The interpretation of "registered with"
-in the previous section applies here. Inconsistent glue records are
-an operational matter.
-
-3.4 Name Compression
-
-Compression of names in DNS messages is described in RFC 1035, section
-4.1.4, "Message compression". The issue highlighted here relates to a
-comment made in RFC 1034, section 3.1, "Name space specifications and
-terminology" which says "When you receive a domain name or label, you
-should preserve its case." ("Should" in the quote predates [BCP14].)
-
-Name compression in an AXFR message MUST preserve the case of the
-original domain name. That is, although when comparing a domain name,
-"a" equals "A", when comparing for the purposes of message compression,
-"a" is not equal to "A". Note that this is not the usual definition
-of name comparison in the DNS protocol and represents a new
-requirement on AXFR servers.
-
-Rules governing name compression of RDATA in an AXFR message MUST
-abide by the specification in "Handling of Unknown DNS Resource Record
-(RR) Types" [RFC3597], specifically, section 4 on "Domain Name
-Compression."
-
-3.5 Occluded Names
-
-Dynamic Update [RFC2136] operations, and in particular its interaction
-with DNAME [RFC2672], can have a side effect of occluding names in a
-zone. The addition of a delegation point via dynamic update will
-render all subordinate domain names to be in a limbo, still part of
-the zone but not available to the lookup process. The addition of a
-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
-be able to identify and handle occluded names. The rationale for this
-action is based on a speedy recovery if the dynamic update operation
-was in error and is to be undone.
-
-4 Transport
-
-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
-reliable protocol must be used for AXFR requests." The restriction to
-TCP is also mentioned in section 6.1.3.2. of "Requirements for Internet
-Hosts - Application and Support" [RFC1123].
-
-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
-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
-this is documented as a most common scenario.
-
-The assumption that a TCP connection is dedicated to the single AXFR
-session is incorrect, this has led to implementation choices that
-prevent either multiple concurrent zone transfers or the use of the
-open connection for other queries.
-
-Being able to have multiple concurrent zone transfers is considered
-desirable by operators who have sets of name servers that are
-authoritative for a common set of zones. It would be desirable
-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
-tighten the specification, not a change, but adding words to the
-unclear areas, to define what is needed to permit two servers to
-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
-either the AXFR client or AXFR server is incapable of performing
-multiple concurrent AXFR sessions.
-
-With the addition of EDNS0 and applications which require many
-small zones such as in web hosting and some ENUM scenarios, AXFR
-sessions on UDP would now be possible and seem desirable. However,
-there are still some aspects of the AXFR session that are not easily
-translated to UDP. This document leaves AXFR over UDP undefined.
-
-4.1 TCP
-
-In the original definition there is an implicit assumption (probably
-unintentional) that a TCP connection is used for one and only one
-AXFR session. This is evidenced in no requirement to copy neither
-the Query Section nor the message ID in responses, no explicit
-ordering information within the AXFR response messages and the lack
-of an explicit notice indicating that a zone transfer continues in the
-next message.
-
-The guidance given here is intended to enable better performance of
-the AXFR exchange as well as guidelines on interactions with older
-software. Better performance includes being able to multiplex DNS
-message exchanges including zone transfer sessions. Guidelines for
-interacting with older software are generally applicable to new AXFR
-clients. In the reverse situation, older AXFR client and newer AXFR
-server ought to induce the server to operate within the specification
-for an older server.
-
-4.1.1 AXFR client TCP
-
-An AXFR client MAY request a connection to an AXFR server for any
-reason. An AXFR client SHOULD close the connection when there is
-no apparent need to use the connection for some time period. The
-AXFR server ought not have to maintain idle connections, the burden
-of connection closure ought to be on the client. Apparent need for
-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
-known sessions will be coming or if there is other query/response
-traffic anticipated or currently on the open connection, then there
-is "apparent need."
-
-An AXFR client MAY cancel delivery of a zone only by closing the
-connection. However, this action will also cancel all other outstanding
-activity using the connection. There is no other mechanism by which
-an AXFR response can be cancelled.
-
-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
-MUST cancel all outstanding sessions and non-AXFR transactions.
-Recovery from this situation is not straightforward. If the disruption
-was a spurious event, attempting to restart the connection would be
-proper. If the disruption was caused by a medium or long term
-disruption, the AXFR client would be wise to not spend too many
-resources trying to rebuild the connection. Finally, if the connection
-was dropped because of a policy at the AXFR server (as can be the case
-with older AXFR servers), the AXFR client would be wise to not retry
-the connection. Unfortunately, knowing which of the three cases above
-(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
-AXFR session. Using an existing open connection is RECOMMENDED over
-opening a new connection. (Non-AXFR session traffic can also use an
-open connection.) If in doing so the AXFR client realizes that
-the responses cannot be properly differentiated (lack of matching
-query IDs for example) or the connection is terminated for a remote
-reason, then the AXFR client SHOULD NOT attempt to reuse an open
-connection with the specific AXFR server until the AXFR server is
-updated (which is of course, not an event captured in the DNS
-protocol).
-
-4.1.2 AXFR server TCP
-
-An AXFR server MUST be able to handle multiple AXFR sessions on a
-single TCP connection, as well as handle other query/response
-transactions.
-
-If a TCP connection is closed remotely, the AXFR server MUST cancel
-all AXFR sessions in place. No retry activity is necessary; that is
-initiated by the AXFR client.
-
-Local policy MAY dictate that a TCP connection is to be closed. Such
-an action SHOULD be in reaction to limits such as those placed on
-the number of outstanding open connections. Closing a connection in
-response to a suspected security event SHOULD be done only in extreme
-cases, when the server is certain the action is warranted. An
-isolated request for a zone not on the AXFR server SHOULD receive
-a response with the appropriate return code and not see the connection
-broken.
-
-4.2 UDP
-
-AXFR sessions over UDP transport are not defined.
-
-5 Authorization
-
-A zone administrator has the option to restrict AXFR access to a zone.
-This was not envisioned in the original design of the DNS but has
-emerged as a requirement as the DNS has evolved. Restrictions on AXFR
-could be for various reasons including a desire (or in some instances,
-having a legal requirement) to keep the bulk version of the zone
-concealed or to prevent the servers from handling the load incurred in
-serving AXFR. All reasons are arguable, but the fact remains that
-there is a requirement to provide mechanisms to restrict AXFR.
-
-A DNS implementation SHOULD provide means to restrict AXFR sessions to
-specific clients.
-
-An implementation SHOULD allow access to be granted to Internet
-Protocol addresses and ranges, regardless of whether a source address
-could be spoofed. Combining this with techniques such as Virtual
-Private Networks (VPN) [RFC2764] or Virtual LANs has proven to be
-effective.
-
-A general purpose implementation is RECOMMENDED to implement access
-controls based upon "Secret Key Transaction Authentication for DNS"
-[RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )"
-[RFC2931].
-
-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
-AXFR query to be granted.
-
-A general purpose implementation SHOULD NOT have a default policy
-for AXFR requests to be "open to all." For example, a default could
-be to restrict transfers to addresses selected by the DNS
-administrator(s) for zones on the server.
-
-6 Zone Integrity
-
-An AXFR client MUST ensure that only a successfully transferred
-copy of the zone data can be used to serve this zone. Previous
-description and implementation practice have introduced a two-stage
-model of the whole zone synchronization procedure: Upon a trigger
-event (e.g., polling of SOA resource record detects change in the
-SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session
-is initiated, whereby the zone data are saved in a zone file or
-data base (this latter step is necessary anyway to ensure proper
-restart of the server); upon successful completion of the AXFR
-operation and some sanity checks, this data set is 'loaded' and
-made available for serving the zone in an atomic operation, and
-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
-AXFR client MUST continue to serve the previous version of the zone,
-if it did before. The externally visible behavior of an AXFR client
-implementation MUST be equivalent to that of this two-stage model.
-
-If a server rejects data contained in an AXFR session, the server
-SHOULD remember the serial number and MAY attempt to retrieve the
-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
-important to the security of a zone. If a zone operator has the
-opportunity, protection can be afforded via dedicated links, physical
-or virtual via a VPN among the authoritative servers. But there are
-instances in which zone operators have no choice but to run AXFR
-sessions over the global public Internet.
-
-Besides best attempts at securing TCP connections, DNS implementations
-SHOULD provide means to make use of "Secret Key Transaction
-Authentication for DNS" [RFC2845] and/or "DNS Request and Transaction
-Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients to verify the
-contents. These techniques MAY also be used for authorization.
-
-7 Backwards Compatibility
-
-Describing backwards compatibility is difficult because of the lack of
-specifics in the original definition. In this section some hints at
-building in backwards compatibility are given, mostly repeated from the
-earlier sections.
-
-Backwards compatibility is not necessary, but the greater the extent of
-an implementation's compatibility the greater it's interoperability.
-For turnkey implementations this is not usually a concern. For general
-purpose implementations this takes on varying levels of importance
-depending on the implementer's desire to maintain interoperability.
-
-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
-implementation SHOULD, in it's documentation, encourage operators to
-periodically review AXFR clients and servers it has made notes about as
-old software periodically gets updated.
-
-7.1 Server
-
-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
-accept multiple resource records per AXFR response message. The
-knowledge that a client is so restricted apparently cannot be
-discovered, hence it has to be set by configuration.
-
-An implementation of an AXFR server MAY permit configuring, on a per
-AXFR client basis, a need to revert to single resource record per
-message; in that case, the default SHOULD be to use multiple records
-
-7.2 Client
-
-An AXFR client has the opportunity to try other features (i.e., those
-not defined by this document) when querying an AXFR server.
-
-Attempting to issue multiple DNS queries over a TCP transport for an
-AXFR session SHOULD be aborted if it interrupts the original request,
-and SHOULD take into consideration whether the AXFR server intends to
-close the connection immediately upon completion of the original
-(connection-causing) zone transfer.
-
-8 Security Considerations
-
-Concerns regarding authorization, traffic flooding, and message
-integrity are mentioned in "Authorization" (section 5), "TCP" (section
-4.2) and "Zone Integrity" (section 6).
-
-9 IANA Considerations
-
-No new registries or new registrations are included in this document.
-
-10 Internationalization Considerations
-
-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)"
-[RFC3490].
-
-
-11 Acknowledgements
-
-Earlier editions of this document have been edited by Andreas
-Gustafsson. In his latest version, this acknowledgement appeared.
-
-"Many people have contributed input and commentary to earlier versions
-of this document, including but not limited to Bob Halley, Dan
-Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz,
-Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam Trenholme,
-and Brian Wellington."
-
-Comments since the -05 version have come from these individuals:
-Alfred Hoenes, Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain
-Calder, Tony Finch, Ian Jackson, Andreas Gustafsson, Brian Wellington,
-and other participants of the DNSEXT working group.
-
-12 References
-
-All references prefixed by "RFC" can be obtained from the RFC Editor
-web site at the URLs: http://rfc-editor.org/rfc.html
-or http://rfc-editor.org/rfcsearch.html ;
-information regarding this organization can be found at the following
-URL: http://rfc-editor.org/
-
-12.1 Normative
-
-[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
- September 1981.
-[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
- 1980.
-[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-[RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
- and Support", STD 3, RFC 1123, October 1989.
-[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
- August 1996.
-[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
- Changes (DNS NOTIFY)", RFC 1996, August 1996.
-[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC
- 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,
- August 1999.
-[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
- August 1999.
-[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
- Wellington, "Secret Key Transaction Authentication for DNS
- (TSIG)", RFC 2845, May 2000.
-[RFC5395] Eastlake 3rd, "Domain Name System (DNS) IANA Considerations",
- BCP 42, RFC 5395, November 2008.
-[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
- RR)", RFC 2930, September 2000.
-[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
- ( SIG(0)s )", RFC 2931, September 2000.
-[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 2002.
-[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
- (RR) Types", RFC 3597, September 2003.
-[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
- (DS) Resource Records (RRs)", RFC 4509, May 2006
-[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
- Security (DNSSEC) Hashed Authenticated Denial of Existence",
- RFC 5155, March 2008
-[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-[RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication
- Code, Secure Hash Algorithm) TSIG Algorithm Identifiers",
- RFC 4635, August 2006.
-[DNSFLGS] http://www.iana.org/assignments/dns-header-flags
-[DNSVALS] http://www.iana.org/assignments/dns-parameters
-
-12.2 Informative
-
-[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-[RFC1700] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700,
- October 1994.
-[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
- Malis, "A Framework for IP Based Virtual Private Networks",
- RFC 2764, February 2000.
-[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
- "Internationalizing Domain Names in Applications (IDNA)", RFC
- 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.
-
-13 Editor's Address
-
-Edward Lewis
-46000 Center Oak Plaza
-Sterling, VA, 22033, US
-+1-571-434-5468
-ed.lewis@neustar.biz
--- /dev/null
+
+
+
+
+
+DNS Extensions Working Group Edward Lewis
+Internet-Draft NeuStar, Inc.
+Updates: 1034, 1035 (if approved) A. Hoenes
+Intended status: Standards Track TR-Sys
+Expires: June 6, 2010 December 6, 2009
+
+
+ DNS Zone Transfer Protocol (AXFR)
+ draft-ietf-dnsext-axfr-clarify-12
+
+Abstract
+
+ The Domain Name System standard mechanisms for maintaining coherent
+ servers for a zone consist of three elements. One mechanism is the
+ Authoritative Transfer (AXFR) defined in RFC 1034 and RFC 1035.
+ The definition of AXFR has proven insufficient in detail, thereby
+ forcing implementations intended to be compliant to make assumptions,
+ impeding interoperability. Yet today we have a satisfactory set of
+ implementations that do interoperate. This document is a new
+ definition of AXFR -- new in the sense that is it recording an
+ accurate definition of an interoperable AXFR mechanism.
+
+Status of this Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79. This document may contain material
+ from IETF Documents or IETF Contributions published or made publicly
+ available before November 10, 2008. The person(s) controlling the
+ copyright in some of this material may not have granted the IETF
+ Trust the right to allow modifications of such material outside the
+ IETF Standards Process. Without obtaining an adequate license from
+ the person(s) controlling the copyright in such materials, this
+ document may not be modified outside the IETF Standards Process, and
+ derivative works of it may not be created outside the IETF Standards
+ Process, except to format it for publication as an RFC or to
+ translate it into languages other than English.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 1]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+ This Internet-Draft will expire on June 6, 2010.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents in effect on the date of
+ publication of this document (http://trustee.ietf.org/license-info).
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 2]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4
+ 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.3. Context . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.4. Coverage and Relationship to Original AXFR Specification . 5
+ 2. AXFR Messages . . . . . . . . . . . . . . . . . . . . . . . 7
+ 2.1. AXFR query . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 2.1.1. Header Values . . . . . . . . . . . . . . . . . . . . . 9
+ 2.1.2. Question Section . . . . . . . . . . . . . . . . . . . . 10
+ 2.1.3. Answer Section . . . . . . . . . . . . . . . . . . . . . 10
+ 2.1.4. Authority Section . . . . . . . . . . . . . . . . . . . 10
+ 2.1.5. Additional Section . . . . . . . . . . . . . . . . . . . 10
+ 2.2. AXFR Response . . . . . . . . . . . . . . . . . . . . . . 11
+ 2.2.1. "0 Message" Response . . . . . . . . . . . . . . . . . . 11
+ 2.2.2. Header Values . . . . . . . . . . . . . . . . . . . . . 12
+ 2.2.3. Question Section . . . . . . . . . . . . . . . . . . . . 14
+ 2.2.4. Answer Section . . . . . . . . . . . . . . . . . . . . . 14
+ 2.2.5. Authority Section . . . . . . . . . . . . . . . . . . . 14
+ 2.2.6. Additional Section . . . . . . . . . . . . . . . . . . . 14
+ 2.3. TCP Connection Aborts . . . . . . . . . . . . . . . . . . 14
+ 3. Zone Contents . . . . . . . . . . . . . . . . . . . . . . . 15
+ 3.1. Records to Include . . . . . . . . . . . . . . . . . . . . 15
+ 3.2. Delegation Records . . . . . . . . . . . . . . . . . . . . 16
+ 3.3. Glue Records . . . . . . . . . . . . . . . . . . . . . . . 18
+ 3.4. Name Compression . . . . . . . . . . . . . . . . . . . . . 18
+ 3.5. Occluded Names . . . . . . . . . . . . . . . . . . . . . . 19
+ 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 4.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 4.1.1. AXFR client TCP . . . . . . . . . . . . . . . . . . . . 20
+ 4.1.2. AXFR server TCP . . . . . . . . . . . . . . . . . . . . 21
+ 4.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . 22
+ 6. Zone Integrity . . . . . . . . . . . . . . . . . . . . . . . 23
+ 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . 24
+ 7.1. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+ 7.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . 25
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25
+ 10. Internationalization Considerations . . . . . . . . . . . . 25
+ 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
+ 12.2. Informative References . . . . . . . . . . . . . . . . . 27
+ 13. Editor's Address . . . . . . . . . . . . . . . . . . . . . 28
+
+
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 3]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+1. Introduction
+
+ The Domain Name System standard facilities for maintaining coherent
+ servers for a zone consist of three elements. Authoritative Transfer
+ (AXFR) is defined in "Domain Names - Concepts and Facilities"
+ [RFC1034] (referred to in this document as RFC 1034) and "Domain
+ Names - Implementation and Specification" [RFC1035] (henceforth
+ RFC 1035). Incremental Zone Transfer (IXFR) is defined in
+ "Incremental Zone Transfer in DNS" [RFC1995]. A mechanism for prompt
+ notification of zone changes (NOTIFY) is defined in "A Mechanism for
+ Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The
+ goal of these mechanisms is to enable a set of DNS name servers to
+ remain coherently authoritative for a given zone.
+
+ This document re-specifies the AXFR mechanism as it is deployed in
+ the Internet at large, hopefully with the precision expected from
+ modern Internet Standards, and thereby updates RFC 1034 and RFC 1035.
+
+1.1. Definition of Terms
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in "Key words for use in
+ RFCs to Indicate Requirement Levels" [BCP14].
+
+ Use of "newer"/"new" and "older"/"old" DNS refers to implementations
+ written after and prior to the publication of this document.
+
+ "General purpose DNS implementation" refers to DNS software developed
+ for wide-spread use. This includes resolvers and servers freely
+ accessible as libraries and standalone processes. This also includes
+ proprietary implementations used only in support of DNS service
+ offerings.
+
+ "Turnkey DNS implementation" refers to custom made, single use
+ implementations of DNS. Such implementations consist of software
+ that employs the DNS protocol message format yet does not conform to
+ the entire range of DNS functionality.
+
+ The terms "AXFR session", "AXFR server" and "AXFR client" will be
+ introduced in the first paragraph of Section 2, after some more
+ context has been established.
+
+1.2. Scope
+
+ In general terms, authoritative name servers for a given zone can use
+ various means to achieve coherency of the zone contents they serve.
+ For example, there are DNS implementations that assemble answers from
+ data stored in relational databases (as opposed to master files),
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 4]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+ relying on the database's non-DNS means to synchronize the database
+ instances. Some of these non-DNS solutions interoperate in some
+ fashion. However, AXFR, IXFR, and NOTIFY are the only protocol-
+ defined in-band mechanisms to provide coherence of a set of name
+ servers, and they are the only mechanisms specified by the IETF.
+
+ This document does not cover incoherent DNS situations. There are
+ applications of the DNS in which servers for a zone are designed to
+ be incoherent. For these configurations, a coherency mechanism as
+ described here would be unsuitable.
+
+ A DNS implementation is not required to support AXFR, IXFR, and
+ NOTIFY, but it should have some means for maintaining name server
+ coherency. A general purpose DNS implementation will likely support
+ AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS
+ implementations may exist without AXFR.
+
+1.3. Context
+
+ Besides describing the mechanisms themselves, there is the context in
+ which they operate to consider. In the initial specifications of
+ AXFR (and IXFR and NOTIFY), little consideration was given to
+ security and privacy issues. Since the original definition of AXFR,
+ new opinions have appeared on the access to an entire zone's
+ contents. In this document, the basic mechanisms will be discussed
+ separately from the permission to use these mechanisms.
+
+1.4. Coverage and Relationship to Original AXFR Specification
+
+ This document concentrates on just the definition of AXFR. Any
+ effort to update the specification of the IXFR or NOTIFY mechanisms
+ is left to different documents.
+
+ The original "specification" of the AXFR sub-protocol is scattered
+ through RFC 1034 and RFC 1035. Section 2.2 of RFC 1035 (on page 5)
+ depicts the scenario for which AXFR has been designed. Section 4.3.5
+ of RFC 1034 describes the zone synchronization strategies in general
+ 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
+ AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant
+ flaw in that specification. Section 3.2.3 of RFC 1035 has assigned
+ the code point for the AXFR QTYPE (see Section 2.1.2 below for more
+ details). Section 4.2 of RFC 1035 discusses the transport layer use
+ of DNS and shortly explains why UDP transport is deemed inappropriate
+ for AXFR; the last paragraph of Section 4.2.2 gives details for the
+ 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.
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 5]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+ This document will update the specification of AXFR. To this end, it
+ 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
+ details the transport considerations for AXFR, thus amending Section
+ 4.2.2 of RFC 1035. Furthermore, it discusses backward compatibility
+ issues and provides policy/management considerations as well as
+ specific Security Considerations for AXFR. The goal of this document
+ is to define AXFR as it exists, or is supposed to exist, currently.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 6]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+2. AXFR Messages
+
+ An AXFR session consists of an AXFR query message and the sequence of
+ 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
+ responder. (Use of terms such as master, slave, primary, secondary
+ are not important to defining AXFR.) The use of the word "session"
+ without qualification refers to an AXFR session.
+
+ 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
+ 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
+ Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the
+ following documents.
+
+ o The 'Basic' DNS specification:
+
+ - "A Mechanism for Prompt Notification of Zone Changes (DNS Notify)"
+ [RFC1996]
+ - "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136]
+ - "Clarifications to the DNS Specification" [RFC2181]
+ - "Extension Mechanisms for DNS (EDNS0)" [RFC2671]
+ - "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845]
+ - "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]
+ - "Obsoleting IQUERY" [RFC3425]
+ - "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597]
+ - "HMAC SHA TSIG Algorithm Identifiers" [RFC4635]
+ - "Domain Name System (DNS) IANA Considerations" [RFC5395]
+
+ o Further additions related to the DNS Security Extensions (DNSSEC),
+ defined in these base documents:
+
+ - "DNS Security Introduction and Requirements" [RFC4033]
+ - "Resource Records for the DNS Security Extensions" [RFC4034]
+ - "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]
+ - "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource
+ Records for DNSSEC" [RFC5702]
+ - "Clarifications and Implementation Notes for DNSSECbis" [DNSSEC-U]
+
+ These documents contain information about the syntax and semantics of
+ DNS messages. They ought not interfere with AXFR but are also
+ helpful in understanding what will be carried via AXFR.
+
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 7]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+ For convenience, the synopsis of the DNS message header from
+ [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is
+ reproduced here informally:
+
+ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ID |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | QDCOUNT/ZOCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ANCOUNT/PRCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | NSCOUNT/UPCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ARCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+ This document makes use of the field names as they appear in this
+ diagram. The names of sections in the body of DNS messages are
+ capitalized in this document for clarity, e.g., "Additional section".
+
+ The DNS message size limit from [RFC1035] for DNS over UDP (and its
+ extension via the EDNS0 mechanism specified in [RFC2671]) is not
+ relevant for AXFR, as explained in Section 4. The upper limit on the
+ permissible size of a DNS message over TCP is only restricted by the
+ TCP framing defined in Section 4.2.2 of RFC 1035, which specifies a
+ two-octet message length field, understood to be unsigned, and thus
+ causing a limit of 65535 octets. 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.
+
+2.1. AXFR query
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 8]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+2.1.1. Header Values
+
+ These are the DNS message header values for an AXFR query.
+
+ ID Selected by client; see Note a)
+
+ QR MUST be 0 (Query)
+
+ OPCODE MUST be 0 (Standard Query)
+
+ Flags:
+ AA 'n/a' -- see Note b)
+ TC 'n/a' -- see Note b)
+ RD 'n/a' -- see Note b)
+ RA 'n/a' -- see Note b)
+ Z 'mbz' -- see Note c)
+ AD 'n/a' -- see Note b)
+ CD 'n/a' -- see Note b)
+
+ RCODE MUST be 0 (No error)
+
+ QDCOUNT Number of entries in Question section; MUST be 1
+
+ ANCOUNT Number of entries in Answer section; MUST be 0
+
+ NSCOUNT Number of entries in Authority section; MUST be 0
+
+ ARCOUNT Number of entries in Additional section -- see Note d)
+
+ Notes:
+
+ a) Set to any value that the client is not already using with the
+ same server. There is no specific means for selecting the value
+ in this field. (Recall that AXFR is done only via TCP connections
+ -- see Section 4 "Transport".)
+
+ A server MUST reply using messages that use the same message ID to
+ allow a client to have multiple queries outstanding concurrently
+ over the same TCP connection -- see Note a) in Section 2.2.2 for
+ more details.
+
+ 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
+ value be zero. The server MUST ignore this value.
+
+ c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore
+ it.
+
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 9]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+ d) The client MUST set this field to the number of resource records
+ appearing in the Additional section. See Section 2.1.5
+ "Additional Section" for details.
+
+ The value MAY be 0, 1 or 2. If it is 2, the Additional section
+ MUST contain both an EDNS0 [RFC2671] OPT resource record and a
+ record carrying transaction integrity and authentication data,
+ currently a choice of TSIG [RFC2845] and SIG(0) [RFC2931]. If the
+ value is 1, then the Additional section MUST contain either only
+ an EDNS0 OPT resource record or a record carrying transaction
+ integrity and authentication data. If the value is 0, the
+ Additional section MUST be empty.
+
+2.1.2. Question Section
+
+ The Query section of the AXFR query MUST conform to Section 4.1.2 of
+ RFC 1035, and contain a single resource record with the following
+ values:
+
+ QNAME the name of the zone requested
+
+ QTYPE AXFR (= 252), the pseudo-RR type for zone transfer
+ [DNSVALS]
+
+ QCLASS the class of the zone requested [DNSVALS]
+
+2.1.3. Answer Section
+
+ The Answer section MUST be empty.
+
+2.1.4. Authority Section
+
+ The Authority section MUST be empty.
+
+2.1.5. Additional Section
+
+ The client MAY include an EDNS0 OPT [RFC2671] resource record. If
+ the server does not support EDNS0, the client MUST send this section
+ without an EDNS0 OPT resource record if there is a retry. However,
+ the protocol does not define an explicit indication that the server
+ 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
+ the OPT resource record.
+
+ The client MAY include a transaction integrity and authentication
+ resource record, currently a choice of TSIG [RFC2845] or SIG(0)
+ [RFC2931]. If the server has indicated that it does not recognize
+ the resource record, and that the error is indeed caused by the
+ resource record, the client probably should not try again. Removing
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 10]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+ the security data in the face of an obstacle ought to only be done
+ with full awareness of the implication of doing so.
+
+ In general, if an AXFR client is aware that an AXFR server does not
+ support a particular mechanism, the client SHOULD NOT attempt to
+ engage the server using the mechanism (or at all). A client could
+ become aware of a server's abilities via a configuration setting or
+ via some other (as yet) undefined means.
+
+ The range of permissible resource records that MAY appear in the
+ 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
+ Additional section record is created, the new definitions ought to
+ include a discussion on the impact upon AXFR. Future resource
+ records residing in the Additional section might have 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 able to pass
+ these records through without disruption.
+
+2.2. AXFR Response
+
+ The AXFR response will consist of 0 or more messages. A "0 message"
+ response is covered in Section 2.2.1.
+
+ An AXFR response that is transferring the zone's contents will
+ consist of a series (which could be a series of length 1) of DNS
+ messages. In such a series, the first message MUST begin with the
+ SOA resource record of the zone, the last message MUST conclude with
+ the same SOA resource record. Intermediate messages MUST NOT contain
+ the SOA resource record. The AXFR server MUST copy the Question
+ section from the corresponding AXFR query message in to the first
+ response message's Question section. Subsequent messages MAY do the
+ same or contain an empty Question section.
+
+ An AXFR response indicates an error via a single DNS message with the
+ return code set to the appropriate value for the condition
+ encountered, sent once the error condition is detected. Such a
+ message terminates the AXFR session; it MUST copy the Query Section
+ from the AXFR query into its Query Section, but the inclusion of the
+ terminating SOA resource record is not necessary.
+
+ An AXFR server may send a number of AXFR response messages free of an
+ error condition before it sends the message indicating an error.
+
+2.2.1. "0 Message" Response
+
+ A legitimate "0 message" response, i.e., the client sees no response
+ whatsoever, is very exceptional and controversial. Unquestionably it
+ is unhealthy for there to be 0 responses in a protocol that is
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 11]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+ designed around a query - response paradigm over an unreliable
+ transport. The lack of a response could be a sign of underlying
+ network problems and cause the protocol state machine to react
+ accordingly. However, AXFR uses TCP and not UDP, eliminating
+ undetectable network errors.
+
+ A "0 message response" is reserved for situations in which the server
+ has a reason to suspect that the query is sent for the purpose of
+ abuse. Due to the use of this being so controversial, a "0 message
+ response" is not being defined as a legitimate part of the protocol
+ but the use of it is being acknowledged as a warning to AXFR client
+ implementations. Any earnest query has the expectation of some
+ response but nevertheless may not get one.
+
+2.2.2. Header Values
+
+ These are the DNS message header values for AXFR responses.
+
+ ID MUST be copied from request -- see Note a)
+
+ QR MUST be 1 (Response)
+
+ OPCODE MUST be 0 (Standard Query)
+
+ Flags:
+ AA normally 1 -- see Note b)
+ TC MUST be 0 (Not truncated)
+ RD RECOMMENDED: copy request's value, MAY be set to 0
+ RA SHOULD be 0 -- see Note c)
+ Z 'mbz' -- see Note d)
+ AD covered by DNSSEC rules -- see Note e)
+ CD covered by DNSSEC rules -- see Note e)
+
+ RCODE See Note f)
+
+ QDCOUNT MUST be 1 in the first message;
+ MUST be 0 or 1 in all following messages;
+ MUST be 1 if RCODE indicates an error
+
+ ANCOUNT See Note g)
+
+ NSCOUNT MUST be 0
+
+ ARCOUNT See Note h)
+
+
+
+
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 12]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+ Notes:
+
+ a) Because some old implementations behave differently than is now
+ desired, the requirement on this field is stated in detail. New
+ DNS servers MUST set this field to the value of the AXFR query ID
+ in each AXFR response message for the session. AXFR clients MUST
+ be able to manage sessions resulting from the issuance of multiple
+ outstanding queries, whether AXFR queries or other DNS queries.
+ A client SHOULD discard responses that do not correspond (via the
+ message ID) to any outstanding queries.
+
+ Unless the client is sure that the server will consistently set
+ the ID field to the query's ID, the client is NOT RECOMMENDED to
+ issue any other queries until the end of the zone transfer.
+ A client MAY become aware of a server's abilities via a
+ configuration setting.
+
+ b) If the RCODE is 0 (no error), then the AA bit MUST be 1.
+ For any other value of RCODE, the AA bit MUST be set according to
+ the rules for that error code. If in doubt, it is RECOMMENDED
+ that it be set to 1. It is RECOMMENDED that the value be ignored
+ by the AXFR client.
+
+ c) It is RECOMMENDED that the server set the value to 0, the client
+ MUST ignore this value.
+
+ The server MAY set this value according to the local policy
+ regarding recursive service, but doing so might confuse the
+ interpretation of the response as AXFR can not be retrieved
+ recursively. A client MAY note the server's policy regarding
+ recursive service from this value, but SHOULD NOT conclude that
+ the AXFR response was obtained recursively even if the RD bit was
+ 1 in the query.
+
+ d) 'mbz' -- The server MUST set this bit to 0, the client MUST ignore
+ it.
+
+ e) If the implementation supports the DNS Security Extensions (DNSSEC
+ -- see Section 2), 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". If the implementation does not support
+ the DNS Security Extensions, then this value MUST be set to 0 and
+ MUST be ignored upon receipt.
+
+ f) 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
+ queried zone, the server SHOULD set the value to NotAuth(9).
+ (Reminder, consult the appropriate IANA registry [DNSVALS].) If a
+ client receives any other value in response, it MUST act according
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 13]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+ to the 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(1) value. This value is not set as part of the AXFR-
+ specific response processing. The same is true for other values
+ indicating an error.
+
+ g) The count of answer records MUST equal the number of resource
+ records in the AXFR Answer Section. When a server is aware 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
+ client's limitations via configuration data.
+
+ h) The client MUST set this field to the number of resource records
+ appearing in the Additional section. The considerations of Note
+ d) in Section 2.1.1 apply equally; see Section 2.2.6 "Additional
+ Section" below for more details.
+
+2.2.3. Question Section
+
+ In the first response message, this section MUST be copied from the
+ query. In subsequent messages, this section MAY be copied from the
+ query or it MAY be empty. However, in an error response message (see
+ Section 2.2), this section MUST be copied as well. The content of
+ this section MAY be used to determine the context of the message,
+ that is, the name of the zone being transferred.
+
+2.2.4. Answer Section
+
+ MUST be populated with the zone contents. See Section 3 below on
+ encoding zone contents.
+
+2.2.5. Authority Section
+
+ The Authority section MUST be empty.
+
+2.2.6. Additional Section
+
+ The contents of this section MUST follow the guidelines for EDNS0 and
+ TSIG, SIG(0), or whatever other future record is possible here. The
+ contents of Section 2.1.5 apply analogously as well.
+
+2.3. TCP Connection Aborts
+
+ 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 terminated. The message ID MAY be used again on a new
+ connection, even if the question and AXFR server are the same.
+
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 14]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+ Facing a dropped connection, a client SHOULD try to make some
+ determination whether the connection closure was the result of
+ network activity or a decision by the AXFR server. This
+ determination is not an exact science. It is up to the AXFR client
+ implementor to react, but the reaction SHOULD NOT be an endless cycle
+ of retries nor an increasing (in frequency) retry rate.
+
+ An AXFR server implementor SHOULD take into consideration the dilemma
+ described above when a connection is closed with an outstanding query
+ in the pipeline. For this reason, a server ought to reserve this
+ course of action for situations in which it believes beyond a doubt
+ that the AXFR client is attempting abusive behavior.
+
+
+3. Zone Contents
+
+ The objective of the AXFR session is to request and transfer the
+ 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
+ serial number. Over time the definition of a zone has evolved from
+ denoting a static set of records to also cover a dynamically updated
+ set of records, and then a potentially continually regenerated set of
+ records (e.g., RRs synthesized "on the fly" from rule sets or
+ database lookup results in other forms than RR format) as well.
+
+3.1. Records to Include
+
+ In the Answer section of AXFR response messages the resource records
+ 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 the database is divided into zones" (in particular
+ Section 4.2.1, "Technical considerations"), and it has been clarified
+ in Section 6 of RFC 2181.
+
+ Unless the AXFR server knows that the AXFR client is old and expects
+ just one resource record per AXFR response message, an AXFR server
+ SHOULD populate an AXFR response message with as many complete
+ resource record sets as will fit within a DNS message.
+
+ Zones for which it is impractical to list the entire zone for a
+ serial number are not suitable for AXFR retrieval. A typical (but
+ not limiting) description of such a zone is a zone consisting of
+ responses generated via other database lookups and/or computed based
+ upon ever changing data.
+
+
+
+
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 15]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+3.2. Delegation Records
+
+ In Section 4.2.1 of RFC 1034, this text appears (keep in mind that
+ the "should" in the quotation predates [BCP14], cf. Section 1.1):
+
+ "The RRs that describe cuts ... should be exactly the same as the
+ corresponding 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 included in a zone transfer.
+
+ The phrase "that describe cuts" is a reference to the NS set and
+ applicable glue records. It does not mean that the cut point and
+ apex resource records are identical. For example, the SOA resource
+ record is only found at the apex. The discussion here is restricted
+ to just the NS resource record set and glue as these "describe cuts".
+
+ DNSSEC resource records have special specifications regarding their
+ occurrence at a zone cut and the apex of a zone. This was first
+ described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial
+ specification of DNSSEC), which parts of RFC 2181 now in fact are
+ historical. The current DNSSEC core document set (see Note e) in
+ Section 2.2.2 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
+ part of the authoritative data of the zone it serves.
+
+ o Independent RRSIG RRSets occur at the signed parent side of a zone
+ cut and at the apex of a signed zone; they are authoritative data
+ in the respective zone; simple queries for RRSIG resource records
+ may return both 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 side 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.
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 16]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+ One 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 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 protocol is robust enough to overcome inconsistencies up to (but
+ not including) there being no parent indicated NS resource record
+ referencing a server that is able to serve the child zone. This
+ 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
+ to make it apparent (if it is unplanned) and to make it clear once
+ the inconsistency has been removed.
+
+ Another issue is that the AXFR server could be authoritative for a
+ different set of zones than the AXFR client. It is possible that the
+ AXFR server be authoritative for both halves of an inconsistent cut
+ point and that the AXFR client is authoritative for just the parent
+ side of the cut point.
+
+ When facing a situation in which a cut point's NS resource records do
+ not match the authoritative set, the question arises whether an AXFR
+ server responds with the NS resource record set that is in the zone
+ being transferred or the one that is at the authoritative location.
+
+ The AXFR response MUST contain the cut point NS resource record set
+ registered with the zone whether it agrees with the authoritative set
+ or not. "Registered with" can be widely interpreted to include data
+ residing in the zone file of the zone for the particular serial
+ number (in zone file environments) or as any data configured to be in
+ the zone (database), statically or dynamically.
+
+ The reasons for this requirement are:
+
+ 1) The AXFR server might not be able to determine that there is an
+ inconsistency given local data, hence requiring consistency would
+ mean a lot more needed work and even network retrieval of data. An
+ authoritative server ought not be required to perform any queries.
+
+ 2) By transferring the inconsistent NS resource records from a server
+ 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, an authorized administrator can manually request the AXFR
+ and inspect the results to see the inconsistent records. (A server
+ authoritative for both halves would otherwise always answer from the
+ more authoritative set, concealing the error.)
+
+ 3) The inconsistent NS resource record set might indicate a problem
+ in a registration database.
+
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 17]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+ 4) This requirement is necessary to ensure that retrieving a given
+ (zone,serial) pair by AXFR yields the exact same set of resource
+ records no matter which of the zone's authoritative servers is chosen
+ as the source of the transfer.
+
+ If an AXFR server were allowed to respond with the authoritative 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 be authoritative for the child
+ zone as well.
+
+ 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
+
+ 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
+ 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 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 that serial number is to be included.
+
+ This applies to glue records for any address family [IANA-AF].
+
+ The AXFR response MUST contain the appropriate glue records as
+ registered with the zone. The interpretation of "registered with" in
+ the previous section applies here. Inconsistent glue records are an
+ operational matter.
+
+3.4. Name Compression
+
+ Compression of names in DNS messages is described in RFC 1035,
+ Section 4.1.4, "Message compression". The issue highlighted here
+ relates to a comment made in RFC 1034, Section 3.1, "Name space
+ specifications and terminology" which says "When you receive a domain
+ name or label, you should preserve its case." ("Should" in the quote
+ predates [BCP14].)
+
+ Name compression in an AXFR message MUST preserve the case of the
+ original domain name. That is, although when comparing a domain
+ name, "a" equals "A", when comparing for the purposes of message
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 18]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+ compression, "a" is not equal to "A". Note that this is not the
+ usual definition of name comparison in the DNS protocol and
+ represents a new requirement on AXFR servers.
+
+ Rules governing name compression of RDATA in an AXFR message MUST
+ abide by the specification in "Handling of Unknown DNS Resource
+ Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name
+ Compression".
+
+3.5. Occluded Names
+
+ Dynamic Update [RFC2136] operations, and in particular its
+ interaction with DNAME [RFC2672], can have a side effect of occluding
+ names in a zone. The addition of a delegation point via dynamic
+ update will render all subordinate domain names to be in a limbo,
+ still part of the zone but not available to the lookup process. The
+ addition of a 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 be able to identify and handle occluded names. The rationale
+ for this action is based on a speedy recovery if the dynamic update
+ operation was in error and is to be undone.
+
+
+4. Transport
+
+ 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
+ reliable protocol must be used for AXFR requests." The restriction
+ to TCP is also mentioned in Section 6.1.3.2. of "Requirements for
+ Internet Hosts - Application and Support" [RFC1123].
+
+ 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 then close the connection. But variations of that
+ most simple scenario are legitimate and likely, in particular sending
+ a query for the zone's SOA resource record first over the same TCP
+ connection, and reusing an existing TCP connection for other queries.
+
+ Therefore, the assumption that a TCP connection is dedicated to a
+ single AXFR session is incorrect. This wrong assumption has led to
+ implementation choices that prevent either multiple concurrent zone
+ transfers or the use of an open connection for other queries.
+
+ Since the early days of the DNS, operators who have sets of name
+ servers that are authoritative for a common set of zones found it
+ desirable to be able to have multiple concurrent zone transfers in
+ progress; this way a name server does not have to wait for one zone
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 19]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+ transfer to complete before the next could begin. RFC 1035 did not
+ exclude this possibility, but legacy implementations missed to
+ support this functionality. The remaining presence of such legacy
+ implementations makes it necessary that new general purpose server
+ implementation still provide options for gracefull fallback to the
+ old behavior in their support of concurrent DNS transactions and AXFR
+ sessions on a single TCP connection.
+
+4.1. TCP
+
+ In the original definition there arguably is an implicit assumption
+ (probably unintentional) that a TCP connection is used for one and
+ only one AXFR session. This is evidenced in the lack of an explicit
+ requirement to copy the Query section and/or the message ID into
+ responses, no explicit ordering information within the AXFR response
+ messages, and the lack of an explicit notice indicating that a zone
+ transfer continues in the next message.
+
+ The guidance given below is intended to enable better performance of
+ the AXFR exchange as well as provide guidelines on interactions with
+ older software. Better performance includes being able to multiplex
+ DNS message exchanges including zone transfer sessions. Guidelines
+ for interacting with older software are generally applicable to new
+ AXFR clients. In the reverse situation, older AXFR client and newer
+ AXFR server, the server ought to operate within the specification for
+ an older server.
+
+4.1.1. AXFR client TCP
+
+ An AXFR client MAY request a connection to an AXFR server for any
+ reason. An AXFR client SHOULD close the connection when there is no
+ apparent need to use the connection for some time period. The AXFR
+ server ought not have to maintain idle connections, the burden of
+ connection closure ought to be on the client. "Apparent need" for
+ 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 known
+ sessions will be coming, or if there is other query/response traffic
+ anticipated or currently on the open connection, then there is
+ "apparent need".
+
+ An AXFR client can cancel the delivery of a zone only by closing the
+ connection. However, this action will also cancel all other
+ outstanding activity using the connection. There is no other
+ mechanism by which an AXFR response can be cancelled.
+
+ 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
+ MUST cancel all outstanding sessions and non-AXFR transactions.
+ Recovery from this situation is not straightforward. If the
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 20]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+ disruption was a spurious event, attempting to restart the connection
+ would be proper. If the disruption was caused by a failure that
+ proved to be persistent, the AXFR client would be wise to not spend
+ too many resources trying to rebuild the connection. Finally, if the
+ connection was dropped because of a policy at the AXFR server (as can
+ be the case with older AXFR servers), the AXFR client would be wise
+ to not retry the connection. Unfortunately, knowing which of the
+ three cases above (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
+ AXFR session. Using an existing open connection is RECOMMENDED over
+ opening a new connection. (Non-AXFR session traffic can also use an
+ open connection.) If in doing so the AXFR client realizes that the
+ responses cannot be properly differentiated (lack of matching query
+ IDs for example) or the connection is terminated for a remote reason,
+ then the AXFR client SHOULD NOT attempt to reuse an open connection
+ with the specific AXFR server until the AXFR server is updated (which
+ is, of course, not an event captured in the DNS protocol).
+
+4.1.2. AXFR server TCP
+
+ An AXFR server MUST be able to handle multiple AXFR sessions on a
+ single TCP connection, as well as handle other query/response
+ transactions over it.
+
+ If a TCP connection is closed remotely, the AXFR server MUST cancel
+ all AXFR sessions in place. No retry activity is necessary; that is
+ initiated by the AXFR client.
+
+ Local policy MAY dictate that a TCP connection is to be closed. Such
+ an action SHOULD be in reaction to limits such as those placed on the
+ number of outstanding open connections. Closing a connection in
+ response to a suspected security event SHOULD be done only in extreme
+ cases, when the server is certain the action is warranted. An
+ isolated request for a zone not on the AXFR server SHOULD receive a
+ response with the appropriate return code and not see the connection
+ broken.
+
+4.2. UDP
+
+ With the addition of EDNS0 and applications which require many small
+ zones such as in web hosting and some ENUM scenarios, AXFR sessions
+ on UDP would now seem desirable. However, there are still some
+ aspects of AXFR sessions that are not easily translated to UDP.
+
+ Therefore, this document does not update RFC 1035 in this respect:
+ AXFR sessions over UDP transport are not defined.
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 21]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+5. Authorization
+
+ A zone administrator has the option to restrict AXFR access to a
+ zone. This was not envisioned in the original design of the DNS but
+ has emerged as a requirement as the DNS has evolved. Restrictions on
+ AXFR could be for various reasons including a desire (or in some
+ instances, having a legal requirement) to keep the bulk version of
+ the zone concealed or to prevent the servers from handling the load
+ incurred in serving AXFR. It has been argued that these reasons are
+ questionable, but this document, driven by the desire to leverage the
+ interoperable practice that has evolved since RFC 1035, acknowledges
+ the factual requirement to provide mechanisms to restrict AXFR.
+
+ A DNS implementation SHOULD provide means to restrict AXFR sessions
+ to specific clients.
+
+ An implementation SHOULD allow access to be granted to Internet
+ Protocol addresses and ranges, regardless of whether a source address
+ could be spoofed. Combining this with techniques such as Virtual
+ Private Networks (VPN) [RFC2764] or Virtual LANs has proven to be
+ effective.
+
+ A general purpose implementation is RECOMMENDED to implement access
+ controls based upon "Secret Key Transaction Authentication for DNS"
+ [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )"
+ [RFC2931].
+
+ 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
+ AXFR query to be granted.
+
+ A general purpose implementation SHOULD NOT have a default policy for
+ AXFR requests to be "open to all". For example, a default could be
+ to restrict transfers to addresses selected by the DNS
+ administrator(s) for zones on the server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 22]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+6. Zone Integrity
+
+ An AXFR client MUST ensure that only a successfully transferred copy
+ of the zone data can be used to serve this zone. Previous
+ description and implementation practice have introduced a two-stage
+ model of the whole zone synchronization procedure: Upon a trigger
+ event (e.g., polling of a SOA resource record detects change in the
+ SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session is
+ initiated, whereby the zone data are saved in a zone file or data
+ base (this latter step is necessary anyway to ensure proper restart
+ of the server); upon successful completion of the AXFR operation and
+ some sanity checks, this data set is 'loaded' and made available for
+ serving the zone in an atomic operation, and 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 AXFR client MUST continue to
+ serve the previous version of the zone, if it did before. The
+ externally visible behavior of an AXFR client implementation MUST be
+ equivalent to that of this two-stage model.
+
+ If an AXFR client rejects data contained in an AXFR session, it
+ SHOULD remember the serial number and MAY attempt to retrieve the
+ 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
+ present in another AXFR server used for the zone.
+
+ 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
+ opportunity, protection can be afforded via dedicated links, physical
+ or virtual via a VPN among the authoritative servers. But there are
+ instances in which zone operators have no choice but to run AXFR
+ sessions over the global public Internet.
+
+ Besides best attempts at securing TCP connections, DNS
+ implementations SHOULD provide means to make use of "Secret Key
+ Transaction Authentication for DNS" [RFC2845] and/or "DNS Request and
+ Transaction Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients
+ to verify the contents. These techniques MAY also be used for
+ authorization.
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 23]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+7. Backwards Compatibility
+
+ Describing backwards compatibility is difficult because of the lack
+ of specifics in the original definition. In this section some hints
+ at building in backwards compatibility are given, mostly repeated
+ from the relevant earlier sections.
+
+ Backwards compatibility is not necessary, but the greater the extent
+ of an implementation's compatibility the greater its
+ interoperability. For turnkey implementations this is not usually a
+ concern. For general purpose implementations this takes on varying
+ levels of importance depending on the implementer's desire to
+ maintain interoperability.
+
+ 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
+ implementation SHOULD, in its documentation, encourage operators to
+ periodically review AXFR clients and servers it has made notes about
+ repeatedly, as old software gets updated from time to time.
+
+7.1. Server
+
+ An AXFR server has the luxury of being able to react to an AXFR
+ client's abilities with the exception of knowing whether the client
+ can accept multiple resource records per AXFR response message. The
+ knowledge that a client is so restricted cannot be discovered, hence
+ it has to be set by configuration.
+
+ An implementation of an AXFR server MAY permit configuring, on a per
+ AXFR client basis, the necessity to revert to single resource record
+ per message; in that case, the default SHOULD be to use multiple
+ records per message.
+
+7.2. Client
+
+ An AXFR client has the opportunity to try other features (i.e., those
+ not defined by this document) when querying an AXFR server.
+
+ Attempting to issue multiple DNS queries over a TCP transport for an
+ AXFR session SHOULD be aborted if it interrupts the original request,
+ and SHOULD take into consideration whether the AXFR server intends to
+ close the connection immediately upon completion of the original
+ (connection-causing) zone transfer.
+
+
+
+
+
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 24]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+8. Security Considerations
+
+ Concerns regarding authorization, traffic flooding, and message
+ integrity are mentioned in "Authorization" (Section 5), "TCP"
+ (Section 4.2) and "Zone Integrity" (Section 6).
+
+
+9. IANA Considerations
+
+ [[ Note to RFC-Ed: this section may be deleted before publication. ]]
+
+ No new registries or new registrations are included in this document.
+
+
+10. Internationalization Considerations
+
+ 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)" [RFC3490] or its successor(s).
+
+
+11. Acknowledgments
+
+ Earlier editions of this document have been edited by Andreas
+ Gustafsson. In his latest version, this acknowledgment appeared:
+
+ "Many people have contributed input and commentary to earlier
+ versions of this document, including but not limited to Bob Halley,
+ Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert
+ Elz, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
+ Trenholme, and Brian Wellington."
+
+ Comments since the -05 version have come from these individuals:
+ Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch,
+ Ian Jackson, Andreas Gustafsson, Brian Wellington, and other
+ participants of the DNSEXT working group.
+
+ Edward Lewis served as a patiently listening sole document editor for
+ two years.
+
+12. References
+
+ All "RFC" references by can be obtained from the RFC Editor web site
+ at the URLs: http://rfc-editor.org/rfc.html
+ or http://rfc-editor.org/rfcsearch.html ;
+ information regarding this organization can be found at the following
+ URL: http://rfc-editor.org/
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 25]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+12.1. Normative References
+
+ [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
+ RFC 793, September 1981.
+
+ [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
+ and Support", STD 3, RFC 1123, October 1989.
+
+ [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+ August 1996.
+
+ [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
+ Changes (DNS NOTIFY)", RFC 1996, August 1996.
+
+ [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+ RFC 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, August 1999.
+
+ [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
+ RFC 2672, August 1999.
+
+ [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+ Wellington, "Secret Key Transaction Authentication for DNS
+ (TSIG)", RFC 2845, May 2000.
+
+ [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
+ RR)", RFC 2930, September 2000.
+
+ [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
+ ( SIG(0)s )", RFC 2931, September 2000.
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 26]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+ [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425,
+ November 2002.
+
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
+ (RR) Types", RFC 3597, September 2003.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, March 2005.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, March 2005.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+ (DS) Resource Records (RRs)", RFC 4509, May 2006
+
+ [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication
+ Code, Secure Hash Algorithm) TSIG Algorithm Identifiers",
+ RFC 4635, August 2006.
+
+ [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+ Security (DNSSEC) Hashed Authenticated Denial of
+ Existence", RFC 5155, March 2008
+
+ [RFC5395] Eastlake 3rd, "Domain Name System (DNS) IANA
+ Considerations", BCP 42, RFC 5395, November 2008.
+
+ [RFC5702] Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY
+ and RRSIG Resource Records for DNSSEC", RFC 5702,
+ October 2009.
+
+12.2. Informative References
+
+ [DNSVALS] IANA Registry "Domain Name System (DNS) Parameters",
+ http://www.iana.org/assignments/dns-parameters
+
+ [IANA-AF] IANA Registry "Address Family Numbers",
+ http://www.iana.org/assignments/Address-family-numbers/ .
+
+ [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
+ Malis, "A Framework for IP Based Virtual Private
+ Networks", RFC 2764, February 2000.
+
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 27]
+\f
+Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009
+
+
+ [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
+ "Internationalizing Domain Names in Applications (IDNA)",
+ RFC 3490, March 2003.
+
+ [DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and
+ Implementation Notes for DNSSECbis",
+ draft-ietf-dnsext-dnssec-bis-updates-09 (work in
+ progress), September 2009.
+
+
+13. Editors' Addresses
+
+ Edward Lewis
+ 46000 Center Oak Plaza
+ Sterling, VA, 22033, US
+
+ Email: ed.lewis@neustar.biz
+
+
+ Alfred Hoenes
+ TR-Sys
+ Gerlinger Str. 12
+ Ditzingen D-71254
+ Germany
+
+ Email: ah@TR-Sys.de
+
+
+Editorial Note: Discussion [[ to be removed by RFC-Editor ]]
+
+ Comments on this draft ought to be addressed to the editors and/or to
+ namedroppers@ops.ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes Expires June 6, 2010 [Page 28]
+\f
projects / thirdparty / bind9.git / commitdiff
