INTERNET-DRAFT                                      Andreas Gustafsson
draft-ietf-dnsext-axfr-clarify-02.txt                     Nominum Inc.
                                                         November 2000
                                                             June 2001

               DNS Zone Transfer Protocol Clarifications

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at


   In the Domain Name System, zone data is replicated among
   authoritative DNS servers by means of the "zone transfer" protocol,
   also known as the "AXFR" protocol.  This memo clarifies, updates, and
   adds missing detail to the original AXFR protocol specification in

1. Introduction

   The original definition of the DNS zone transfer protocol consists of
   a single paragraph in [RFC1034] section 4.3.5 and some additional
   notes in [RFC1035] section 6.3.  It is not sufficiently detailed to
   serve as the sole basis for constructing interoperable
   implementations.  This document is an attempt to provide a more
   complete definition of the protocol.  Where the text in RFC1034
   conflicts with existing practice, the existing practice has been
   codified in the interest of interoperability.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC 2119].

2. The zone transfer request

   To initiate a zone transfer, the slave server sends a zone transfer
   request to the master server over a reliable transport such as TCP.
   The form of this request is specified in sufficient detail in RFC1034
   and needs no further clarification.

   Implementers are advised that one server implementation in widespread
   use sends AXFR requests where the TCP message envelope size exceeds
   the DNS request message size by two octets.

3. The zone transfer response

   If the master server is unable or unwilling to provide a zone
   transfer, it MUST respond with a single DNS message containing an
   appropriate RCODE other than NOERROR.

   Slave servers should note that some master server implementations
   will simply close the connection when denying the slave access to the
   zone.  Therefore, slaves MAY interpret an immediate graceful close of
   the TCP connection as equivalent to a "Refused" response (RCODE 5).

   If a zone transfer can be provided, the master server sends one or
   more DNS messages containing the zone data as described below.

3.1. Multiple answers per message

   The zone data in a zone transfer response is a sequence of answer
   RRs.  These RRs are transmitted in the answer section(s) of one or
   more DNS response messages.

   The AXFR protocol definition in RFC1034 does not make a clear
   distinction between response messages and answer RRs.  Historically,
   DNS servers always transmitted a single answer RR per message.  This
   encoding is wasteful due to the overhead of repeatedly sending DNS
   message headers and the loss of domain name compression
   opportunities.  To improve efficiency, some newer servers support a
   mode where multiple RRs are transmitted in a single DNS response

   A master MAY transmit multiple answer RRs per response message up to
   the largest number that will fit within the 65535 byte limit on TCP
   DNS message size.  In the case of a small zone, this can cause the
   entire transfer to be transmitted in a single response message.

   Slaves MUST accept messages containing any number of answer RRs.  For
   compatibility with old slaves, masters that support sending multiple
   answers per message SHOULD be configurable to revert to the
   historical mode of one answer per message, and the configuration
   SHOULD be settable on a per-slave basis.

3.2. DNS message header contents

   RFC1034 does not specify the contents of the DNS message header of
   the zone transfer response messages.  The header of each message MUST
   be as follows:

       ID      Copy from request
       QR      1
       AA      1 (but      1, but MAY be 0 when RCODE is nonzero) not NOERROR
       TC      0
       RD      Copy from request request, or 0
       RA      Set according to availability of recursion S recursion, or 0
       Z       0
       AD      0
       CD      0
       RCODE   0 or   NOERROR on success, error code otherwise

   The slave MUST check the RCODE in each message and abort the transfer
   if it is
   nonzero. not NOERROR.  It SHOULD check the ID of the first message
   received and abort the transfer if it does not match the ID of the
   request.  The ID SHOULD be ignored in subsequent messages, and fields
   other than RCODE and ID SHOULD be ignored in all messages, to ensure
   interoperability with certain older implementations which transmit
   incorrect or arbitrary values in these fields.

3.3. Additional section and SIG processing

   Zone transfer responses are not subject to any kind of additional
   section processing or automatic inclusion of SIG records.  SIG RRs in
   the zone data are treated exactly the same as any other RR type.

3.4. The question section

   RFC1034 does not specify whether zone transfer response messages have
   a question section or not.  The initial message of a zone transfer
   response SHOULD have a question section identical to that in the
   request.  Subsequent messages SHOULD NOT have a question section,
   though the final message MAY.  The receiving slave server MUST accept
   any combination of messages with and without a question section.

3.5. The authority section
   The master server MUST transmit messages with an empty authority
   section.  Slaves MUST ignore any authority section contents they may
   receive from masters that do not comply with this requirement.

3.6. The additional section

   The additional section MAY contain additional RRs such as transaction
   signatures.  The slave MUST ignore any unexpected RRs in the
   additional section.

4. Glue

   A master transmitting a Zone data

   The purpose of the zone transfer MUST include mechanism is to exactly replicate at
   each slave the full set of RRs associated with a particular zone data it at its
   primary master.  An RR is associated with a zone by being loaded from
   the zone's master file, from an incoming file of that zone transfer, at the primary master server, or other similar means of by some
   other, equivalent method for configuring zone data.

   includes any nonauthoritative replication shall be complete and unaltered, regardless of how
   many and which intermediate masters/slaves are involved, and
   regardless of what other zones those intermediate masters/slaves do
   or do not serve, and regardless of what data ("glue") may be cached in
   resolvers associated with the zone
   by being present intermediate masters/slaves.

   Therefore, in a zone transfer the zone's master file or the incoming transfer
   along MUST send exactly those
   records that are associated with the authoritative data.  This glue data includes any
   configured zone data obscured by zone cuts zone, whether or otherwise outside the
   zone in case; it is not limited to RRs pointed their owner
   names would be considered to by NS records.

   The glue RRs are transmitted in the answer section along with be "in" the
   authoritative data.  This is unlike ordinary DNS responses where zone for purposes of
   resolution, and whether or not they would be eligible for use as glue
   is transmitted
   in the authority or additional section.

   Zone transfers responses.  The transfer MUST NOT contain include any RRs from that are not
   associated with the authoritative data of zone, such as RRs associated with zones other
   than the one being transferred or from present in the cache of the cache, local
   resolver, even
   when such RRs if their owner names are in the zone being transferred
   or are pointed to by NS records in the zone being transferred.


   The slave receiving a zone transfer MUST accept glue data and recognize
   it as such; glue MUST NOT be treated as authoritative data nor
   entered into the cache.  Note that classifying an RR as glue or non-
   glue may not be possible until associate the entire zone has been RRs received so
   that the in a zone cuts defined by the zone's NS records can be
   determined.  Glue data that is not below transfer with the
   specific zone origin ("cross-zone
   glue") MAY be discarded by the slave. being transferred, and maintain that association for
   purposes of acting as a master in outgoing transfers.

5. Transmission order

   RFC1034 states that "The first and last messages must contain the
   data for the top authoritative node of the zone".  This is not
   consistent with existing practice.  All known master implementations
   send, and slave implementations expect to receive, the zone's SOA RR
   as the first and last record of the transfer.  Any other RRs at the
   zone's apex are transmitted only once.

   Therefore, the quoted sentence is hereby changed to read "The first
   and last RR transmitted must be the SOA record of the zone".

   The initial and final SOA record MUST be identical, with the possible
   exception of case and compression.  In particular, they MUST have the
   same serial number.

   The transmission order of all other RRs in the zone, including glue
   records, zone is undefined.
   Each of them MUST be transmitted exactly once.  As some older masters
   do not comply with this requirement, slaves SHOULD silently ignore
   duplicate RRs for interoperability.

6. Security Considerations

   The zone transfer protocol as defined in [RFC1034] and clarified by
   this memo does not have any built-in mechanisms for the slave to
   securely verify the identity of the master server and the integrity
   of the transferred zone data.  The use of TSIG [RFC2845] a cryptographic mechanism
   for this
   purpose ensuring authenticity and integrity, such as TSIG [RFC2845],

   The zone transfer protocol allows read-only public access to the
   complete zone data.  Since data in the DNS is public by definition,
   this is generally acceptable.  Sites that wish to avoid disclosing
   their full zone data MAY restrict zone transfer access to authorized

   These clarifications are not believed to themselves introduce any new
   security problems, nor to solve any existing ones.


   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, Levon Esibov,
   Mark Andrews, Michael Patton, Peter Koch, and Sam Trenholme.


   [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
   November 1987.

   [RFC1035] - Domain Names - Implementation and Specifications, P.
   Mockapetris, November 1987.

   [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
   S. Bradner, BCP 14, March 1997.

   [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG).  P.

   Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.

Author's Address

   Andreas Gustafsson
   Nominum Inc.
   950 Charter Street
   Redwood City, CA 94063

   Phone: +1 650 779 381 6004


Full Copyright Statement

   Copyright (C) The Internet Society (2000). (2000, 2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an