DNS Extensions Working Group                                Edward Lewis
INTERNET-DRAFT
Internet-Draft                                             NeuStar, Inc.
Expires: Octopber 1, 2009                                  April 2009
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-11.txt
                    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." 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. 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. document (http://trustee.ietf.org/license-info).
   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

Table of three elements.  One mechanism is the
Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035.
The definition Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.1.  Definition of AXFR, has proven insufficient in detail, forcing
implementations intended to be compliant Terms  . . . . . . . . . . . . . . . . . . .  4
   1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3.  Context  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   1.4.  Coverage and Relationship 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 Original AXFR mechanism.

1 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

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 (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.

Comments on this draft ought to be addressed to

   This document re-specifies the editor or to
namedroppers@ops.ietf.org.

1.1 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].

"Newer"/"New" DNS

   Use of "newer"/"new" and "older"/"old" DNS refers to implementations
   written after and prior to the publication of this document.

1.2 Scope

In

   "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 greater context there are many ways DNS protocol message format yet does not conform to achieve coherency among
a set
   the entire range of name servers. DNS functionality.

   The AXFR, IXFR terms "AXFR session", "AXFR server" and NOTIFY mechanisms form
just one, the one defined "AXFR client" will be
   introduced in the RFCs cited. 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) 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,  However, AXFR, IXFR IXFR, and NOTIFY are the only protocol-
   defined in-band mechanisms
that provide an interoperable solution to the desire for coherency
within the definition provide coherence of DNS, a set of name
   servers, and they certainly are the only mechanisms
documented 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.

"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 DNS situations.  There are
   applications of the DNS functionality. 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 IXFR, and NOTIFY.
A DNS implementation SHOULD
   NOTIFY, but it should have some means for maintaining name server
   coherency.  A general purpose DNS implementation SHOULD include will likely support
   AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS
   implementations
MAY 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

1.3.  Context

   Besides describing the mechanisms themselves, there is the context in
   which they operate to consider.  When AXFR,  In the initial specifications of
   AXFR (and IXFR and NOTIFY were
defined, there was 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

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 would be done in
   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 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 AXFR.  To this end, it
   fully
specifying specifies the record formats and processing rules for AXFR,
   largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and detailing 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.

2

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") of RFC 1035 [RFC1035], updated by the following:
   following documents.

   o  The 'Basic' DNS specification:

   -  "A Mechanism for Prompt Notification of Zone Changes (...)" (DNS Notify)"
       [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]
   -  "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 ... (DS) ... (RRs)" Delegation Signer RRs" [RFC4509]
   - "HMAC SHA TSIG Algorithm Identifiers" [RFC4635]
- "... (DNSSEC)  "DNS Security Hashed Authenticated Denial of Existence" [RFC5155]

For completeness, 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.

   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 following, field names as they appear in this
   diagram.  The names of sections in process, documents contain
information about the body of DNS message.  These documents ought not interfere
with AXFR but these documents messages are helpful
   capitalized in understanding what will
be carried this document for clarity, e.g., "Additional section".

   The DNS message size limit from [RFC1035] for DNS over UDP (and its
   extension via AXFR.

- "Use of SHA-2 algorithms with RSA the EDNS0 mechanism specified in DNSKEY and RRSIG Resource
  Records for DNSSEC" [DRAFT1]
- "Clarifications and Implementation Notes [RFC2671]) is not
   relevant for DNSSECbis" [DRAFT2] 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, 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  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

2.1.  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 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

2.1.1.  Header Values

   These are the DNS message header values for an AXFR query.

      ID          See note 2.1.1.a          Selected by client; see Note a)

      QR          MUST be 0 (Query)

      OPCODE      MUST be 0 (Standard Query)

      Flags:
         AA          See note 2.1.1.b       'n/a' -- see Note b)
         TC          See note 2.1.1.b       'n/a' -- see Note b)
         RD          See note 2.1.1.b       'n/a' -- see Note b)
         RA          See note 2.1.1.b       'n/a' -- see Note b)
         Z           See note 2.1.1.c        'mbz' -- see Note c)
         AD          See note 2.1.1.b       'n/a' -- see Note b)
         CD          See note 2.1.1.b       '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     See note 2.1.1.d     Number of entries in Additional section -- see Note 2.1.1.a 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.) connections
      -- see Section 4 "Transport".)

      A server MUST reply using messages that use the same message ID to
      allow a client to meaningfully have multiple AXFR queries outstanding. outstanding concurrently
      over the same TCP connection -- see Note 2.1.1.b 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.

Note 2.1.1.c

   c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore
      it.

Note 2.1.1.d

   d) The client MUST set this field to be the number of resource records
      appearing in the additional 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 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 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
      Additional section MUST be empty.

2.1.2 Query

2.1.2.  Question Section

   The Query section of the AXFR query MUST conform to section 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(=       AXFR (= 252), the pseudo-RR type for zone transfer
                  [DNSVALS]

      QCLASS      the class of the zone requested

2.1.3 [DNSVALS]

2.1.3.  Answer Section

   The Answer section MUST be empty.

2.1.4

2.1.4.  Authority Section

   The Authority section MUST be empty.

2.1.5

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  However,
   the protocol does not support EDNS0 is not define an explicit element in indication that the protocol, it is up server
   does not support EDNS0; that needs to be inferred by the client to interpret.
Most likely, client.
   Often, the server will return a FORMERR 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 ought should 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
   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
   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  Future resource
   records may 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

2.2.  AXFR response Response

   The AXFR response will consist of 0 or more messages.  A "0 message"
   response is covered in section 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 AXFR server MUST copy the Query Section Question
   section from the corresponding AXFR query message in to the first
   response message's query Question section.  Subsequent messages MAY do the same.
   same or contain an empty Question section.

   An AXFR response that is indicating indicates an error MUST consist of via a single DNS message with the
   return code set to the appropriate value for the condition encountered -
   encountered, sent once the error condition is detected.  Such a
   message MUST terminate 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 client might receive server may send a number of AXFR response messages free of an
   error condition before it sends the message indicating an error
is received.

2.2.1 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
   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

2.2.2.  Header Values

   These are the DNS message header values for AXFR responses.

      ID          See note 2.2.2.a          MUST be copied from request -- see Note a)

      QR          MUST be 1 (Response)

      OPCODE      MUST be 0 (Standard Query)

      Flags:
         AA          See note 2.2.2.b       normally 1 -- see Note b)
         TC       MUST be 0 (Not truncated)
         RD          RECOMMENDED       RECOMMENDED: copy request's value, MAY be set to 0
         RA          See note 2.2.2.c       SHOULD be 0 -- see Note c)
         Z           See note 2.2.2.d        'mbz' -- see Note d)
         AD          See note 2.2.2.e       covered by DNSSEC rules -- see Note e)
         CD          See note 2.2.2.e       covered by DNSSEC rules -- see Note e)

      RCODE       See note 2.2.2.f 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 2.2.2.g Note g)

      NSCOUNT     MUST be 0

      ARCOUNT     See note 2.2.2.h Note 2.2.2.a h)

   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.

Note 2.2.2.b

   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.

Note 2.2.2.c

   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

   d) 'mbz' -- The server MUST set this bit to 0, the client MUST ignore
      it.

Note 2.2.2.e

   e) If the implementation supports the DNS Security Extensions
(see below) (DNSSEC
      -- see Section 2), then this value MUST be set according to the
      rules in RFC 4035, section 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

   f) In the absence of an error, the server MUST set the value of this
      field to NoError. NoError(0).  If a server is not authoritative for the
      queried zone, the server SHOULD set the value to NotAuth. NotAuth(9).
      (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 FormErr(1) value.  This value is not set as part of the AXFR-specific AXFR-
      specific response processing.  The same is true for other error-indicating values.

Note 2.2.2.g 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.

Note 2.2.2.h

   h) The client MUST set this field to be the number of resource records
      appearing in the additional Additional section.  The considerations in of Note 2.1.1.d above
      d) in Section 2.1.1 apply equally; see Section 2.2.6 "Additional
      Section" below for more details.

2.2.3 Query

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

2.2.4.  Answer Section

   MUST be populated with the zone contents.  See later section Section 3 below on
   encoding zone contents.

2.2.5

2.2.5.  Authority Section

   The Authority section MUST be empty.

2.2.6

2.2.6.  Additional Section

   The contents of this section MUST follow the guidelines for EDNS0, EDNS0 and
   TSIG, SIG(0), or what ever whatever other future record is possible here.  The
   contents of section Section 2.1.5 apply here analogously as well.

2.3

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 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

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

3.1.  Records to Include

   In the answer 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 zones" (in particular
   Section 4.2.1, "Technical considerations", 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 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.

3.2

3.2.  Delegation Records

   In Section 4.2.1 of RFC 1034, section 4.2.1, this text appears (keep in mind that
   the "should" in the quotation predates [BCP14], cf. section 1.1) 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 was first time been
   described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial
   specification of DNSSEC), which parts of RFC 2181 now is in fact are
   historical.  The current DNSSEC core document set (see Note 2.2.2.e 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
   authoritative
      part of the authoritative data 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 data
      in the respective zone; simple queries for RRSIG resource records
      may return bth 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 (or NSEC3 [RFC5155] [RFC5155]) resource records
      equally may occur at the parental siede 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.

The

   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.

The question that arises is, when

   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.

   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.
   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

3.3.  Glue Records

   As quoted in the previous section, 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]. [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

3.4.  Name Compression

   Compression of names in DNS messages is described in RFC 1035, section
   Section 4.1.4, "Message compression".  The issue highlighted here
   relates to a comment made in RFC 1034, section 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 Section 4 on "Domain Name
Compression."

3.5
   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".

   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

4.  Transport

   AXFR sessions are currently restricted to TCP by section 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 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  But variations on this, such as of that
   most simple scenario are legitimate and likely, in particular sending
   a query for the zone's SOA resource record first, first over the same TCP
   connection, and so on.  Note that
this is documented as a most common scenario.

The reusing an existing TCP connection for other queries.

   Therefore, the assumption that a TCP connection is dedicated to the a
   single AXFR session is incorrect, this incorrect.  This wrong assumption has led to
   implementation choices that prevent either multiple concurrent zone
   transfers or the use of the an open connection for other queries.

Being able to have multiple concurrent zone transfers is considered
desirable by

   Since the early days of the DNS, operators who have sets of name
   servers that are authoritative for a common set of zones.  It would be zones found it
   desirable
if the to be able to have multiple concurrent zone transfers in
   progress; this way a name server implementations did does 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 zone
   transfer to
share a TCP connection among concurrent AXFR sessions.  The challenge
is complete before the next could begin.  RFC 1035 did not
   exclude this possibility, but legacy implementations missed to design
   support this in a way functionality.  The remaining presence of such legacy
   implementations makes it necessary that can fall back new general purpose server
   implementation still provide options for gracefull fallback to the
   old behavior if
either the AXFR client or AXFR server is incapable in their support of performing
multiple concurrent AXFR sessions.

With the addition of EDNS0 and applications which require many
small zones such as in web hosting DNS transactions 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 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 no the lack of an explicit
   requirement to copy neither the Query Section nor section and/or the message ID in into
   responses, no explicit ordering information within the AXFR response messages
   messages, and the lack of an explicit notice indicating that a zone
   transfer continues in the next message.

   The guidance given here 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 ought to induce server, the server ought to operate within the specification for
   an older server.

4.1.1

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  "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 coming, or if there is other query/response traffic
   anticipated or currently on the open connection, then there is
   "apparent need." need".

   An AXFR client MAY 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
   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, 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
   is, of course, not an event captured in the DNS protocol).

4.1.2

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.
   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

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.

5

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  It has been argued that these reasons are arguable,
   questionable, but this document, driven by the fact remains desire to leverage the
   interoperable practice that
there is a 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." all".  For example, a default could be
   to restrict transfers to addresses selected by the DNS
   administrator(s) for zones on the server.

6

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 a server an AXFR client rejects data contained in an AXFR session, the server 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.

7

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 it's 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 it's its documentation, encourage operators to
   periodically review AXFR clients and servers it has made notes about
   repeatedly, as old software periodically gets updated.

7.1 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 if whether 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 the necessity to revert to single resource record
   per message; in that case, the default SHOULD be to use multiple
   records

7.2 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.

8

8.  Security Considerations

   Concerns regarding authorization, traffic flooding, and message
   integrity are mentioned in "Authorization" (section (Section 5), "TCP" (section
   (Section 4.2) and "Zone Integrity" (section (Section 6).

9

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

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 [RFC3490] or its successor(s).

11.  Acknowledgments

   Earlier editions of this document have been edited by Andreas
   Gustafsson.  In his latest version, this acknowledgement appeared. 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:
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

   Edward Lewis served as a patiently listening sole document editor for
   two years.

12.  References

   All "RFC" 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

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.
[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.

   [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.
[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,

   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
              Security (DNSSEC) Hashed Authenticated Denial of
              Existence", RFC 2119, 5155, March 1997.
[RFC1700] J. Reynolds 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 J. Postel, "Assigned Numbers", RRSIG Resource Records for DNSSEC", RFC 1700, 5702,
              October 1994. 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.

   [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]

   [DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and
              Implementation Notes for DNSSECbis",
          draft-ietf-dnsext-dnssec-bis-updates-08, work
              draft-ietf-dnsext-dnssec-bis-updates-09 (work in progress.

13 Editor's Address
              progress), September 2009.

13.  Editors' Addresses

   Edward Lewis
   46000 Center Oak Plaza
   Sterling, VA, 22033, US
+1-571-434-5468

   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.