1 Internet Engineering Task Force (IETF)                          E. Lewis   
    2 Request for Comments: 5936                                 NeuStar, Inc.   
    3 Updates: 1034, 1035                                       A. Hoenes, Ed.   
    4 Category: Standards Track                                         TR-Sys   
    5 ISSN: 2070-1721                                                June 2010   
    8                    DNS Zone Transfer Protocol (AXFR)                       
   10 Abstract                                                                   
   12    The standard means within the Domain Name System protocol for           
   13    maintaining coherence among a zone's authoritative name servers         
   14    consists of three mechanisms.  Authoritative Transfer (AXFR) is one     
   15    of the mechanisms and is defined in RFC 1034 and RFC 1035.              
   17    The definition of AXFR has proven insufficient in detail, thereby       
   18    forcing implementations intended to be compliant to make assumptions,   
   19    impeding interoperability.  Yet today we have a satisfactory set of     
   20    implementations that do interoperate.  This document is a new           
   21    definition of AXFR -- new in the sense that it records an accurate      
   22    definition of an interoperable AXFR mechanism.                          
   24 Status of This Memo                                                        
   26    This is an Internet Standards Track document.                           
   28    This document is a product of the Internet Engineering Task Force       
   29    (IETF).  It represents the consensus of the IETF community.  It has     
   30    received public review and has been approved for publication by the     
   31    Internet Engineering Steering Group (IESG).  Further information on     
   32    Internet Standards is available in Section 2 of RFC 5741.               
   34    Information about the current status of this document, any errata,      
   35    and how to provide feedback on it may be obtained at                    
   36    http://www.rfc-editor.org/info/rfc5936.                                 
   52 Lewis & Hoenes               Standards Track                    [Page 1]   

   53 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
   56 Copyright Notice                                                           
   58    Copyright (c) 2010 IETF Trust and the persons identified as the         
   59    document authors.  All rights reserved.                                 
   61    This document is subject to BCP 78 and the IETF Trust's Legal           
   62    Provisions Relating to IETF Documents                                   
   63    (http://trustee.ietf.org/license-info) in effect on the date of         
   64    publication of this document.  Please review these documents            
   65    carefully, as they describe your rights and restrictions with respect   
   66    to this document.  Code Components extracted from this document must    
   67    include Simplified BSD License text as described in Section 4.e of      
   68    the Trust Legal Provisions and are provided without warranty as         
   69    described in the Simplified BSD License.                                
   71    This document may contain material from IETF Documents or IETF          
   72    Contributions published or made publicly available before November      
   73    10, 2008.  The person(s) controlling the copyright in some of this      
   74    material may not have granted the IETF Trust the right to allow         
   75    modifications of such material outside the IETF Standards Process.      
   76    Without obtaining an adequate license from the person(s) controlling    
   77    the copyright in such materials, this document may not be modified      
   78    outside the IETF Standards Process, and derivative works of it may      
   79    not be created outside the IETF Standards Process, except to format     
   80    it for publication as an RFC or to translate it into languages other    
   81    than English.                                                           
  107 Lewis & Hoenes               Standards Track                    [Page 2]   

  108 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
  111 Table of Contents                                                          
  113    1. Introduction ....................................................4   
  114       1.1. Definition of Terms ........................................4   
  115       1.2. Scope ......................................................5   
  116       1.3. Context ....................................................5   
  117       1.4. Coverage and Relationship to Original AXFR Specification ...5   
  118    2. AXFR Messages ...................................................6   
  119       2.1. AXFR Query .................................................8   
  120            2.1.1. Header Values .......................................8   
  121            2.1.2. Question Section ...................................10   
  122            2.1.3. Answer Section .....................................10   
  123            2.1.4. Authority Section ..................................10   
  124            2.1.5. Additional Section .................................10   
  125       2.2. AXFR Response .............................................11   
  126            2.2.1. Header Values ......................................12   
  127            2.2.2. Question Section ...................................14   
  128            2.2.3. Answer Section .....................................14   
  129            2.2.4. Authority Section ..................................14   
  130            2.2.5. Additional Section .................................14   
  131       2.3. TCP Connection Aborts .....................................15   
  132    3. Zone Contents ..................................................15   
  133       3.1. Records to Include ........................................15   
  134       3.2. Delegation Records ........................................16   
  135       3.3. Glue Records ..............................................18   
  136       3.4. Name Compression ..........................................19   
  137       3.5. Occluded Names ............................................19   
  138    4. Transport ......................................................20   
  139       4.1. TCP .......................................................20   
  140            4.1.1. AXFR Client TCP ....................................21   
  141            4.1.2. AXFR Server TCP ....................................22   
  142       4.2. UDP .......................................................22   
  143    5. Authorization ..................................................22   
  144    6. Zone Integrity .................................................23   
  145    7. Backwards Compatibility ........................................24   
  146       7.1. Server ....................................................24   
  147       7.2. Client ....................................................25   
  148    8. Security Considerations ........................................25   
  149    9. IANA Considerations ............................................25   
  150    10. Internationalization Considerations ...........................25   
  151    11. Acknowledgments ...............................................25   
  152    12. References ....................................................26   
  153       12.1. Normative References .....................................26   
  154       12.2. Informative References ...................................28   
  162 Lewis & Hoenes               Standards Track                    [Page 3]   

  163 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
  166 1.  Introduction                                                           
  168    The Domain Name System standard facilities for maintaining coherent     
  169    servers for a zone consist of three elements.  Authoritative Transfer   
  170    (AXFR) is defined in "Domain Names - Concepts and Facilities"           
  171    [RFC1034] (referred to in this document as RFC 1034) and "Domain        
  172    Names - Implementation and Specification" [RFC1035] (henceforth RFC     
  173    1035).  Incremental Zone Transfer (IXFR) is defined in "Incremental     
  174    Zone Transfer in DNS" [RFC1995].  A mechanism for prompt notification   
  175    of zone changes (NOTIFY) is defined in "A Mechanism for Prompt          
  176    Notification of Zone Changes (DNS NOTIFY)" [RFC1996].  The goal of      
  177    these mechanisms is to enable a set of DNS name servers to remain       
  178    coherently authoritative for a given zone.                              
  180    This document re-specifies the AXFR mechanism as it is deployed in      
  181    the Internet at large, hopefully with the precision expected from       
  182    modern Internet Standards, and thereby updates RFC 1034 and RFC 1035.   
  184 1.1.  Definition of Terms                                                  
  186    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  187    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this    
  188    document are to be interpreted as described in "Key words for use in    
  189    RFCs to Indicate Requirement Levels" [BCP14].                           
  191    Use of "newer"/"new" and "older"/"old" DNS refers to implementations    
  192    written after and prior to the publication of this document.            
  194    "General-purpose DNS implementation" refers to DNS software developed   
  195    for widespread use.  This includes resolvers and servers freely         
  196    accessible as libraries and standalone processes.  This also includes   
  197    proprietary implementations used only in support of DNS service         
  198    offerings.                                                              
  200    "Turnkey DNS implementation" refers to custom-made, single-use          
  201    implementations of DNS.  Such implementations consist of software       
  202    that employs the DNS protocol message format yet does not conform to    
  203    the entire range of DNS functionality.                                  
  205    The terms "AXFR session", "AXFR server", and "AXFR client" will be      
  206    introduced in the first paragraph of Section 2, after some more         
  207    context has been established.                                           
  217 Lewis & Hoenes               Standards Track                    [Page 4]   

  218 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
  221 1.2.  Scope                                                                
  223    In general terms, authoritative name servers for a given zone can use   
  224    various means to achieve coherency of the zone contents they serve.     
  225    For example, there are DNS implementations that assemble answers from   
  226    data stored in relational databases (as opposed to master files),       
  227    relying on the database's non-DNS means to synchronize the database     
  228    instances.  Some of these non-DNS solutions interoperate in some        
  229    fashion.  However, AXFR, IXFR, and NOTIFY are the only protocol-        
  230    defined in-band mechanisms to provide coherence of a set of name        
  231    servers, and they are the only mechanisms specified by the IETF.        
  233    This document does not cover incoherent DNS situations.  There are      
  234    applications of the DNS in which servers for a zone are designed to     
  235    be incoherent.  For these configurations, a coherency mechanism as      
  236    described here would be unsuitable.                                     
  238    A DNS implementation is not required to support AXFR, IXFR, and         
  239    NOTIFY, but it should have some means for maintaining name server       
  240    coherency.  A general-purpose DNS implementation will likely support    
  241    AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS            
  242    implementations may exist without AXFR.                                 
  244 1.3.  Context                                                              
  246    Besides describing the mechanisms themselves, there is the context in   
  247    which they operate to consider.  In the initial specifications of       
  248    AXFR (and IXFR and NOTIFY), little consideration was given to           
  249    security and privacy issues.  Since the original definition of AXFR,    
  250    new opinions have appeared on the access to an entire zone's            
  251    contents.  In this document, the basic mechanisms will be discussed     
  252    separately from the permission to use these mechanisms.                 
  254 1.4.  Coverage and Relationship to Original AXFR Specification             
  256    This document concentrates on just the definition of AXFR.  Any         
  257    effort to update the specification of the IXFR or NOTIFY mechanisms     
  258    is left to different documents.                                         
  260    The original "specification" of the AXFR sub-protocol is scattered      
  261    through RFC 1034 and RFC 1035.  Section 2.2 of RFC 1035 (on page 5)     
  262    depicts the scenario for which AXFR has been designed.  Section 4.3.5   
  263    of RFC 1034 describes the zone synchronization strategies in general    
  264    and rules for the invocation of a full zone transfer via AXFR; the      
  265    fifth paragraph of that section contains a very short sketch of the     
  266    AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant      
  267    flaw in that specification.  Section 3.2.3 of RFC 1035 has assigned     
  268    the code point for the AXFR QTYPE (see Section 2.1.2 below for more     
  272 Lewis & Hoenes               Standards Track                    [Page 5]   

  273 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
  276    details).  Section 4.2 of RFC 1035 discusses how the DNS uses the       
  277    transport layer and briefly explains why UDP transport is deemed        
  278    inappropriate for AXFR; the last paragraph of Section 4.2.2 gives       
  279    details regarding TCP connection management for AXFR.  Finally, the     
  280    second paragraph of Section 6.3 in RFC 1035 mandates server behavior    
  281    when zone data changes occur during an ongoing zone transfer using      
  282    AXFR.                                                                   
  284    This document will update the specification of AXFR.  To this end, it   
  285    fully specifies the record formats and processing rules for AXFR,       
  286    largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and it   
  287    details the transport considerations for AXFR, thus amending Section    
  288    4.2.2 of RFC 1035.  Furthermore, it discusses backward-compatibility    
  289    issues and provides policy/management considerations, as well as        
  290    specific security considerations for AXFR.  The goal of this document   
  291    is to define AXFR as it is understood by the DNS community to exist     
  292    today.                                                                  
  294 2.  AXFR Messages                                                          
  296    An AXFR session consists of an AXFR query message and the sequence of   
  297    AXFR response messages returned for it.  In this document, the AXFR     
  298    client is the sender of the AXFR query, and the AXFR server is the      
  299    responder.  (Use of terms such as master, slave, primary, and           
  300    secondary are not important for defining AXFR.)  The use of the word    
  301    "session" without qualification refers to an AXFR session.              
  303    An important aspect to keep in mind is that the definition of AXFR is   
  304    restricted to TCP [RFC0793] (see Section 4 for details).  The design    
  305    of the AXFR process has certain inherent features that are not easily   
  306    ported to UDP [RFC0768].                                                
  308    The basic format of an AXFR message is the DNS message as defined in    
  309    Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the            
  310    following documents.                                                    
  312    o  The "Basic" DNS specification:                                       
  314       -  "A Mechanism for Prompt Notification of Zone Changes              
  315           (DNS NOTIFY)" [RFC1996]                                          
  317       -  "Dynamic Updates in the Domain Name System (DNS UPDATE)"          
  318           [RFC2136]                                                        
  320       -  "Clarifications to the DNS Specification" [RFC2181]               
  322       -  "Extension Mechanisms for DNS (EDNS0)" [RFC2671]                  
  327 Lewis & Hoenes               Standards Track                    [Page 6]   

  328 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
  331       -  "Secret Key Transaction Authentication for DNS (TSIG)"            
  332           [RFC2845]                                                        
  334       -  "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]            
  336       -  "Obsoleting IQUERY" [RFC3425]                                     
  338       -  "Handling of Unknown DNS Resource Record (RR) Types"              
  339           [RFC3597]                                                        
  341       -  "HMAC SHA (Hashed Message Authentication Code, Secure Hash        
  342           Algorithm) TSIG Algorithm Identifiers" [RFC4635]                 
  344       -  "Domain Name System (DNS) IANA Considerations" [RFC5395]          
  346    o  Further additions related to the DNS Security Extensions (DNSSEC),   
  347       defined in these base documents:                                     
  349       -  "DNS Security Introduction and Requirements" [RFC4033]            
  351       -  "Resource Records for the DNS Security Extensions"                
  352           [RFC4034]                                                        
  354       -  "Protocol Modifications for the DNS Security Extensions"          
  355           [RFC4035]                                                        
  357       -  "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource         
  358           Records (RRs)" [RFC4509]                                         
  360       -  "DNS Security (DNSSEC) Hashed Authenticated Denial of             
  361           Existence" [RFC5155]                                             
  363       -  "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG             
  364           Resource Records for DNSSEC" [RFC5702]                           
  366       -  "Clarifications and Implementation Notes for DNSSECbis"           
  367           [DNSSEC-U]                                                       
  369    These documents contain information about the syntax and semantics of   
  370    DNS messages.  They do not interfere with AXFR but are also helpful     
  371    in understanding what will be carried via AXFR.                         
  373    For convenience, the synopsis of the DNS message header from            
  374    [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is       
  375    reproduced here informally:                                             
  382 Lewis & Hoenes               Standards Track                    [Page 7]   

  383 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
  386              0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15                
  387            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+               
  388            |                      ID                       |               
  389            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+               
  390            |QR|   OpCode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |               
  391            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+               
  392            |                QDCOUNT/ZOCOUNT                |               
  393            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+               
  394            |                ANCOUNT/PRCOUNT                |               
  395            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+               
  396            |                NSCOUNT/UPCOUNT                |               
  397            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+               
  398            |                    ARCOUNT                    |               
  399            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+               
  401    This document makes use of the field names as they appear in this       
  402    diagram.  The names of sections in the body of DNS messages are         
  403    capitalized in this document for clarity, e.g., "Additional section".   
  405    The DNS message size limit from [RFC1035] for DNS over UDP (and its     
  406    extension via the EDNS0 mechanism specified in [RFC2671]) is not        
  407    relevant for AXFR, as explained in Section 4.  The upper limit on the   
  408    permissible size of a DNS message over TCP is only restricted by the    
  409    TCP framing defined in Section 4.2.2 of RFC 1035, which specifies a     
  410    two-octet message length field, understood to be unsigned, and thus     
  411    causing a limit of 65535 octets.  This limit is not changed by EDNS0.   
  413    Note that the TC (truncation) bit is never set by an AXFR server nor    
  414    considered/read by an AXFR client.                                      
  416 2.1.  AXFR Query                                                           
  418    An AXFR query is sent by a client whenever there is a reason to ask.    
  419    This might be because of scheduled or triggered zone maintenance        
  420    activities (see Section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996],     
  421    respectively) or as a result of a command line request, say for         
  422    debugging.                                                              
  424 2.1.1.  Header Values                                                      
  426    These are the DNS message header values for an AXFR query.              
  428       ID          Selected by client; see Note a)                          
  430       QR          MUST be 0 (Query)                                        
  432       OPCODE      MUST be 0 (Standard Query)                               
  437 Lewis & Hoenes               Standards Track                    [Page 8]   

  438 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
  441       Flags:                                                               
  442          AA       "n/a" -- see Note b)                                     
  443          TC       "n/a" -- see Note b)                                     
  444          RD       "n/a" -- see Note b)                                     
  445          RA       "n/a" -- see Note b)                                     
  446          Z        "mbz" -- see Note c)                                     
  447          AD       "n/a" -- see Note b)                                     
  448          CD       "n/a" -- see Note b)                                     
  450       RCODE       MUST be 0 (No error)                                     
  452       QDCOUNT     Number of entries in Question section;   MUST be 1       
  454       ANCOUNT     Number of entries in Answer section;     MUST be 0       
  456       NSCOUNT     Number of entries in Authority section;  MUST be 0       
  458       ARCOUNT     Number of entries in Additional section -- see Note d)   
  460    Notes:                                                                  
  462    a) Set to any value that the client is not already using with the       
  463       same server.  There is no specific means for selecting the value     
  464       in this field.  (Recall that AXFR is done only via TCP connections   
  465       -- see Section 4, "Transport".)                                      
  467       A server MUST reply using messages that use the same message ID to   
  468       allow a client to have multiple queries outstanding concurrently     
  469       over the same TCP connection -- see Note a) in Section 2.2.1 for     
  470       more details.                                                        
  472    b) "n/a" -- The value in this field has no meaning in the context of    
  473       AXFR query messages.  For the client, it is RECOMMENDED that the     
  474       value be zero.  The server MUST ignore this value.                   
  476    c) "mbz" -- The client MUST set this bit to 0; the server MUST ignore   
  477       it.                                                                  
  479    d) The client MUST set this field to the number of resource records     
  480       it places into the Additional section.  In the absence of explicit   
  481       specification of new RRs to be carried in the Additional section     
  482       of AXFR queries, the value MAY be 0, 1, or 2.  See Section 2.1.5,    
  483       "Additional Section", for details on the currently applicable RRs.   
  492 Lewis & Hoenes               Standards Track                    [Page 9]   

  493 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
  496 2.1.2.  Question Section                                                   
  498    The Question section of the AXFR query MUST conform to Section 4.1.2    
  499    of RFC 1035, and contain a single resource record with the following    
  500    values:                                                                 
  502       QNAME       the name of the zone requested                           
  504       QTYPE       AXFR (= 252), the pseudo-RR type for zone transfer       
  505                   [DNSVALS]                                                
  507       QCLASS      the class of the zone requested [DNSVALS]                
  509 2.1.3.  Answer Section                                                     
  511    The Answer section MUST be empty.                                       
  513 2.1.4.  Authority Section                                                  
  515    The Authority section MUST be empty.                                    
  517 2.1.5.  Additional Section                                                 
  519    Currently, two kinds of resource records are defined that can appear    
  520    in the Additional section of AXFR queries and responses: EDNS and DNS   
  521    transaction security.  Future specifications defining RRs that can be   
  522    carried in the Additional section of normal DNS transactions need to    
  523    explicitly describe their use with AXFR, should that be desired.        
  525    The client MAY include one OPT resource record [RFC2671].  If the       
  526    server does not support EDNS0, the client MUST send this section        
  527    without an OPT resource record if there is a retry.  However, the       
  528    protocol does not define an explicit indication that the server does    
  529    not support EDNS0; that needs to be inferred by the client.  Often,     
  530    the server will return a FormErr(1) that might be related to the OPT    
  531    resource record.  Note that, at the time of this writing, only the      
  532    EXTENDED-RCODE field of the OPT RR is meaningful in the context of      
  533    AXFR; future specifications of EDNS flags and/or EDNS options must      
  534    describe their usage in the context of AXFR, if applicable.             
  536    The client MAY include one transaction integrity and authentication     
  537    resource record, currently a choice of TSIG [RFC2845] or SIG(0)         
  538    [RFC2931].  If the server has indicated that it does not recognize      
  539    the resource record, and that the error is indeed caused by the         
  540    resource record, the client probably should not try again.  Removing    
  541    the security data in the face of an obstacle ought to only be done      
  542    with full awareness of the implication of doing so.                     
  547 Lewis & Hoenes               Standards Track                   [Page 10]   

  548 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
  551    In general, if an AXFR client is aware that an AXFR server does not     
  552    support a particular mechanism, the client SHOULD NOT attempt to        
  553    engage the server using the mechanism (or engage the server at all).    
  554    A client could become aware of a server's abilities via a               
  555    configuration setting or via some other (as yet) undefined means.       
  557    The range of permissible resource records that MAY appear in the        
  558    Additional section might change over time.  If either a change to an    
  559    existing resource record (like the OPT RR for EDNS) is made or a new    
  560    Additional section record is created, the new definitions ought to      
  561    include a discussion on the applicability and impact upon AXFR.         
  562    Future resource records residing in the Additional section might have   
  563    an effect that is orthogonal to AXFR, and so can ride through the       
  564    session as opaque data.  In this case, a "wise" implementation ought    
  565    to be able to pass these records through without disruption.            
  567 2.2.  AXFR Response                                                        
  569    The AXFR response will consist of one or more messages.  The special    
  570    case of a server closing the TCP connection without sending an AXFR     
  571    response is covered in Section 2.3.                                     
  573    An AXFR response that is transferring the zone's contents will          
  574    consist of a series (which could be a series of length 1) of DNS        
  575    messages.  In such a series, the first message MUST begin with the      
  576    SOA resource record of the zone, and the last message MUST conclude     
  577    with the same SOA resource record.  Intermediate messages MUST NOT      
  578    contain the SOA resource record.  The AXFR server MUST copy the         
  579    Question section from the corresponding AXFR query message into the     
  580    first response message's Question section.  For subsequent messages,    
  581    it MAY do the same or leave the Question section empty.                 
  583    The AXFR protocol treats the zone contents as an unordered collection   
  584    (or to use the mathematical term, a "set") of RRs.  Except for the      
  585    requirement that the transfer must begin and end with the SOA RR,       
  586    there is no requirement to send the RRs in any particular order or      
  587    grouped into response messages in any particular way.  Although         
  588    servers typically do attempt to send related RRs (such as the RRs       
  589    forming an RRset, and the RRsets of a name) as a contiguous group or,   
  590    when message space allows, in the same response message, they are not   
  591    required to do so, and clients MUST accept any ordering and grouping    
  592    of the non-SOA RRs.  Each RR SHOULD be transmitted only once, and       
  593    AXFR clients MUST ignore any duplicate RRs received.                    
  595    Each AXFR response message SHOULD contain a sufficient number of RRs    
  596    to reasonably amortize the per-message overhead, up to the largest      
  597    number that will fit within a DNS message (taking the required          
  598    content of the other sections into account, as described below).        
  602 Lewis & Hoenes               Standards Track                   [Page 11]   

  603 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
  606    Some old AXFR clients expect each response message to contain only a    
  607    single RR.  To interoperate with such clients, the server MAY           
  608    restrict response messages to a single RR.  As there is no standard     
  609    way to automatically detect such clients, this typically requires       
  610    manual configuration at the server.                                     
  612    To indicate an error in an AXFR response, the AXFR server sends a       
  613    single DNS message when the error condition is detected, with the       
  614    response code set to the appropriate value for the condition            
  615    encountered.  Such a message terminates the AXFR session; it MUST       
  616    contain a copy of the Question section from the AXFR query in its       
  617    Question section, but the inclusion of the terminating SOA resource     
  618    record is not necessary.                                                
  620    An AXFR server may send a number of AXFR response messages free of an   
  621    error condition before it sends the message indicating an error.        
  623 2.2.1.  Header Values                                                      
  625    These are the DNS message header values for AXFR responses.             
  627       ID          MUST be copied from request -- see Note a)               
  629       QR          MUST be 1 (Response)                                     
  631       OPCODE      MUST be 0 (Standard Query)                               
  633       Flags:                                                               
  634          AA       normally 1 -- see Note b)                                
  635          TC       MUST be 0 (Not truncated)                                
  636          RD       RECOMMENDED: copy request's value; MAY be set to 0       
  637          RA       SHOULD be 0 -- see Note c)                               
  638          Z        "mbz" -- see Note d)                                     
  639          AD       "mbz" -- see Note d)                                     
  640          CD       "mbz" -- see Note d)                                     
  642       RCODE       See Note e)                                              
  644       QDCOUNT     MUST be 1 in the first message;                          
  645                   MUST be 0 or 1 in all following messages;                
  646                   MUST be 1 if RCODE indicates an error                    
  648       ANCOUNT     See Note f)                                              
  650       NSCOUNT     MUST be 0                                                
  652       ARCOUNT     See Note g)                                              
  657 Lewis & Hoenes               Standards Track                   [Page 12]   

  658 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
  661    Notes:                                                                  
  663    a) Because some old implementations behave differently than is now      
  664       desired, the requirement on this field is stated in detail.  New     
  665       DNS servers MUST set this field to the value of the AXFR query ID    
  666       in each AXFR response message for the session.  AXFR clients MUST    
  667       be able to manage sessions resulting from the issuance of multiple   
  668       outstanding queries, whether AXFR queries or other DNS queries.  A   
  669       client SHOULD discard responses that do not correspond (via the      
  670       message ID) to any outstanding queries.                              
  672       Unless the client is sure that the server will consistently set      
  673       the ID field to the query's ID, the client is NOT RECOMMENDED to     
  674       issue any other queries until the end of the zone transfer.  A       
  675       client MAY become aware of a server's abilities via a                
  676       configuration setting.                                               
  678    b) If the RCODE is 0 (no error), then the AA bit MUST be 1.  For any    
  679       other value of RCODE, the AA bit MUST be set according to the        
  680       rules for that error code.  If in doubt, it is RECOMMENDED that it   
  681       be set to 1.  It is RECOMMENDED that the value be ignored by the     
  682       AXFR client.                                                         
  684    c) It is RECOMMENDED that the server set the value to 0; the client     
  685       MUST ignore this value.                                              
  687       The server MAY set this value according to the local policy          
  688       regarding recursive service, but doing so might confuse the          
  689       interpretation of the response, as AXFR cannot be retrieved          
  690       recursively.  A client MAY note the server's policy regarding        
  691       recursive service from this value, but SHOULD NOT conclude that      
  692       the AXFR response was obtained recursively, even if the RD bit was   
  693       1 in the query.                                                      
  695    d) "mbz" -- The server MUST set this bit to 0; the client MUST ignore   
  696       it.                                                                  
  698    e) In the absence of an error, the server MUST set the value of this    
  699       field to NoError(0).  If a server is not authoritative for the       
  700       queried zone, the server SHOULD set the value to NotAuth(9).         
  701       (Reminder: Consult the appropriate IANA registry [DNSVALS].)  If a   
  702       client receives any other value in response, it MUST act according   
  703       to the error.  For example, a malformed AXFR query or the presence   
  704       of an OPT resource record sent to an old server will result in a     
  705       FormErr(1) value.  This value is not set as part of the AXFR-        
  706       specific response processing.  The same is true for other values     
  707       indicating an error.                                                 
  712 Lewis & Hoenes               Standards Track                   [Page 13]   

  713 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
  716    f) The count of answer records MUST equal the number of resource        
  717       records in the AXFR Answer section.  When a server is aware that a   
  718       client will only accept response messages with a single resource     
  719       record, then the value MUST be 1.  A server MAY be made aware of a   
  720       client's limitations via configuration data.                         
  722    g) The server MUST set this field to the number of resource records     
  723       it places into the Additional section.  In the absence of explicit   
  724       specification of new RRs to be carried in the Additional section     
  725       of AXFR response messages, the value MAY be 0, 1, or 2.  See         
  726       Section 2.1.5 above for details on the currently applicable RRs      
  727       and Section 2.2.5 for additional considerations specific to AXFR     
  728       servers.                                                             
  730 2.2.2.  Question Section                                                   
  732    In the first response message, this section MUST be copied from the     
  733    query.  In subsequent messages, this section MAY be copied from the     
  734    query, or it MAY be empty.  However, in an error response message       
  735    (see Section 2.2), this section MUST be copied as well.  The content    
  736    of this section MAY be used to determine the context of the message,    
  737    that is, the name of the zone being transferred.                        
  739 2.2.3.  Answer Section                                                     
  741    The Answer section MUST be populated with the zone contents.  See       
  742    Section 3 below on encoding zone contents.                              
  744 2.2.4.  Authority Section                                                  
  746    The Authority section MUST be empty.                                    
  748 2.2.5.  Additional Section                                                 
  750    The contents of this section MUST follow the guidelines for the OPT,    
  751    TSIG, and SIG(0) RRs, or whatever other future record is possible       
  752    here.  The contents of Section 2.1.5 apply analogously as well.         
  754    The following considerations specifically apply to AXFR responses:      
  756    If the client has supplied an EDNS OPT RR in the AXFR query and if      
  757    the server supports EDNS as well, it SHOULD include one OPT RR in the   
  758    first response message and MAY do so in subsequent response messages    
  759    (see Section 2.2); the specifications of EDNS options to be carried     
  760    in the OPT RR may impose stronger requirements.                         
  767 Lewis & Hoenes               Standards Track                   [Page 14]   

  768 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
  771    If the client has supplied a transaction security resource record       
  772    (currently a choice of TSIG and SIG(0)) and the server supports the     
  773    method chosen by the client, it MUST place the corresponding resource   
  774    record into the AXFR response message(s), according to the rules        
  775    specified for that method.                                              
  777 2.3.  TCP Connection Aborts                                                
  779    If an AXFR client sends a query on a TCP connection and the             
  780    connection is closed at any point, the AXFR client MUST consider the    
  781    AXFR session terminated.  The message ID MAY be used again on a new     
  782    connection, even if the question and AXFR server are the same.          
  784    Facing a dropped connection, a client SHOULD try to make some           
  785    determination as to whether the connection closure was the result of    
  786    network activity or due to a decision by the AXFR server.  This         
  787    determination is not an exact science.  It is up to the AXFR client     
  788    to react, but the implemented reaction SHOULD NOT be either an          
  789    endless cycle of retries or an increasing (in frequency) retry rate.    
  791    An AXFR server implementer should take into consideration the dilemma   
  792    described above when a connection is closed with an outstanding query   
  793    in the pipeline.  For this reason, a server ought to reserve this       
  794    course of action for situations in which it believes beyond a doubt     
  795    that the AXFR client is attempting abusive behavior.                    
  797 3.  Zone Contents                                                          
  799    The objective of the AXFR session is to request and transfer the        
  800    contents of a zone, in order to permit the AXFR client to faithfully    
  801    reconstruct the zone as it exists at the primary server for the given   
  802    zone serial number.  The word "exists" here designates the externally   
  803    visible behavior, i.e., the zone content that is being served (handed   
  804    out to clients) -- not its persistent representation in a zone file     
  805    or database used by the server -- and that for consistency should be    
  806    served subsequently by the AXFR client in an identical manner.          
  808    Over time the definition of a zone has evolved from denoting a static   
  809    set of records to also cover a dynamically updated set of records,      
  810    and then a potentially continually regenerated set of records (e.g.,    
  811    RRs synthesized "on the fly" from rule sets or database lookup          
  812    results in other forms than RR format) as well.                         
  814 3.1.  Records to Include                                                   
  816    In the Answer section of AXFR response messages, the resource records   
  817    within a zone for the given serial number MUST appear.  The             
  818    definition of what belongs in a zone is described in RFC 1034,          
  822 Lewis & Hoenes               Standards Track                   [Page 15]   

  823 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
  826    Section 4.2, "How the database is divided into zones" (in particular    
  827    Section 4.2.1, "Technical considerations"), and it has been clarified   
  828    in Section 6 of RFC 2181.                                               
  830    Zones for which it is impractical to list the entire zone for a         
  831    serial number are not suitable for AXFR retrieval.  A typical (but      
  832    not limiting) description of such a zone is a zone consisting of        
  833    responses generated via other database lookups and/or computed based    
  834    upon ever-changing data.                                                
  836 3.2.  Delegation Records                                                   
  838    In Section 4.2.1 of RFC 1034, this text appears (keep in mind that      
  839    the "should" in the quotation predates [BCP14], cf. Section 1.1):       
  841       The RRs that describe cuts ... should be exactly the same as the     
  842       corresponding RRs in the top node of the subzone.                    
  844    There has been some controversy over this statement and the impact on   
  845    which NS resource records are included in a zone transfer.              
  847    The phrase "that describe cuts" is a reference to the NS set and        
  848    applicable glue records.  It does not mean that the cut point and       
  849    apex resource records are identical.  For example, the SOA resource     
  850    record is only found at the apex.  The discussion here is restricted    
  851    to just the NS resource record set and glue, as these "describe         
  852    cuts".                                                                  
  854    DNSSEC resource records have special specifications regarding their     
  855    occurrence at a zone cut and the apex of a zone.  This was first        
  856    described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial      
  857    specification of DNSSEC), which parts of RFC 2181 now in fact are       
  858    historical.  The current DNSSEC core document set (see second bullet    
  859    in Section 2 above) gives the full details for DNSSEC(bis) resource     
  860    record placement, and Section 3.1.5 of RFC 4035 normatively specifies   
  861    their treatment during AXFR; the alternate NSEC3 resource record        
  862    defined later in RFC 5155 behaves identically to the NSEC RR, for the   
  863    purpose of AXFR.                                                        
  865    Informally:                                                             
  867    o  The DS RRSet only occurs at the parental side of a zone cut and is   
  868       authoritative data in the parent zone, not the secure child zone.    
  870    o  The DNSKEY RRSet only occurs at the apex of a signed zone and is     
  871       part of the authoritative data of the zone it serves.                
  877 Lewis & Hoenes               Standards Track                   [Page 16]   

  878 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
  881    o  Independent RRSIG RRSets occur at the signed parent side of a zone   
  882       cut and at the apex of a signed zone; they are authoritative data    
  883       in the respective zone; simple queries for RRSIG resource records    
  884       may return both RRSets at once if the same server is authoritative   
  885       for the parent zone and the child zone (Section 3.1.5 of RFC 4035    
  886       describes how to distinguish these RRs); this seeming ambiguity      
  887       does not occur for AXFR, since each such RRSIG RRset belongs to a    
  888       single zone.                                                         
  890    o  Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records       
  891       equally may occur at the parental side of a zone cut and at the      
  892       apex of a zone; each such resource record belongs to exactly one     
  893       of these zones and is to be included in the AXFR of that zone.       
  895    One issue is that in operations there are times when the NS resource    
  896    records for a zone might be different at a cut point in the parent      
  897    and at the apex of a zone.  Sometimes this is the result of an error,   
  898    and sometimes it is part of an ongoing change in name servers.  The     
  899    DNS protocol is robust enough to overcome inconsistencies up to (but    
  900    not including) there being no parent-indicated NS resource record       
  901    referencing a server that is able to serve the child zone.  This        
  902    robustness is one quality that has fueled the success of the DNS.       
  903    Still, the inconsistency is an error state, and steps need to be        
  904    taken to make it apparent (if it is unplanned).                         
  906    Another issue is that the AXFR server could be authoritative for a      
  907    different set of zones than the AXFR client.  It is possible that the   
  908    AXFR server be authoritative for both halves of an inconsistent cut     
  909    point and that the AXFR client is authoritative for just the parent     
  910    side of the cut point.                                                  
  912    When facing a situation in which a cut point's NS resource records do   
  913    not match the authoritative set, the question arises whether an AXFR    
  914    server responds with the NS resource record set that is in the zone     
  915    being transferred or the one that is at the authoritative location.     
  917    The AXFR response MUST contain the cut point NS resource record set     
  918    registered with the zone whether it agrees with the authoritative set   
  919    or not.  "Registered with" can be widely interpreted to include data    
  920    residing in the zone file of the zone for the particular serial         
  921    number (in zone file environments) or as any data configured to be in   
  922    the zone (database), statically or dynamically.                         
  932 Lewis & Hoenes               Standards Track                   [Page 17]   

  933 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
  936    The reasons for this requirement are:                                   
  938    1) The AXFR server might not be able to determine that there is an      
  939       inconsistency given local data; hence, requiring consistency would   
  940       mean a lot more needed work and even network retrieval of data.      
  941       An authoritative server ought not be required to perform any         
  942       queries.                                                             
  944    2) By transferring the inconsistent NS resource records from a server   
  945       that is authoritative for both the cut point and the apex to a       
  946       client that is not authoritative for both, the error is exposed.     
  947       For example, an authorized administrator can manually request the    
  948       AXFR and inspect the results to see the inconsistent records.  (A    
  949       server authoritative for both halves would otherwise always answer   
  950       from the more authoritative set, concealing the error.)              
  952    3) The inconsistent NS resource record set might indicate a problem     
  953       in a registration database.                                          
  955    4) This requirement is necessary to ensure that retrieving a given      
  956       (zone, serial) pair by AXFR yields the exact same set of resource    
  957       records, no matter which of the zone's authoritative servers is      
  958       chosen as the source of the transfer.                                
  960    If an AXFR server were allowed to respond with the authoritative NS     
  961    RRset of a child zone instead of a parent-side NS RRset in the zone     
  962    being transferred, the set of records returned could vary depending     
  963    on whether or not the server happened to be authoritative for the       
  964    child zone as well.                                                     
  966    The property that a given (zone, serial) pair corresponds to a          
  967    single, well-defined set of records is necessary for the correct        
  968    operation of incremental transfer protocols such as IXFR [RFC1995].     
  969    For example, a client may retrieve a zone by AXFR from one server,      
  970    and then apply an incremental change obtained by IXFR from a            
  971    different server.  If the two servers have different ideas of the       
  972    zone contents, the client can end up attempting to incrementally add    
  973    records that already exist or to delete records that do not exist.      
  975 3.3.  Glue Records                                                         
  977    As quoted in the previous section, Section 4.2.1 of RFC 1034 provides   
  978    guidance and rationale for the inclusion of glue records as part of     
  979    an AXFR response.  And, as also argued in the previous section of       
  980    this document, even when there is an inconsistency between the          
  981    address in a glue record and the authoritative copy of the name         
  982    server's address, the glue resource record that is registered as part   
  983    of the zone for that serial number is to be included.                   
  987 Lewis & Hoenes               Standards Track                   [Page 18]   

  988 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
  991    This applies to glue records for any address family [IANA-AF].          
  993    The AXFR response MUST contain the appropriate glue records as          
  994    registered with the zone.  The interpretation of "registered with" in   
  995    the previous section applies here.  Inconsistent glue records are an    
  996    operational matter.                                                     
  998 3.4.  Name Compression                                                     
 1000    Compression of names in DNS messages is described in RFC 1035,          
 1001    Section 4.1.4, "Message compression".  The issue highlighted here       
 1002    relates to a comment made in RFC 1034, Section 3.1, "Name space         
 1003    specifications and terminology", which says:                            
 1005       When you receive a domain name or label, you should preserve its     
 1006       case.                                                                
 1008    ("Should" in the quote predates [BCP14].)                               
 1010    Since the primary objective of AXFR is to enable the client to serve    
 1011    the same zone content as the server, unlike such normal DNS responses   
 1012    that are expected to preserve the case in the query, the actual zone    
 1013    transfer needs to retain the case of the labels in the zone content.    
 1014    Hence, name compression in an AXFR message SHOULD be performed in a     
 1015    case-preserving manner, unlike how it is done for "normal" DNS          
 1016    responses.  That is, although when comparing a domain name for          
 1017    matching, "a" equals "A", when comparing for the purposes of message    
 1018    compression for AXFR, "a" is not equal to "A".  Note that this is not   
 1019    the usual definition of name comparison in the DNS protocol and         
 1020    represents a new understanding of the requirement on AXFR servers.      
 1022    Rules governing name compression of RDATA in an AXFR message MUST       
 1023    abide by the specification in "Handling of Unknown DNS Resource         
 1024    Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name   
 1025    Compression".                                                           
 1027 3.5.  Occluded Names                                                       
 1029    Dynamic Update [RFC2136] operations, and in particular their            
 1030    interaction with DNAME [RFC2672], can have a side effect of occluding   
 1031    names in a zone.  The addition of a delegation point via dynamic        
 1032    update will render all subordinate domain names to be in a limbo,       
 1033    still part of the zone but not available to the lookup process.  The    
 1034    addition of a DNAME resource record has the same impact.  The           
 1035    subordinate names are said to be "occluded".                            
 1042 Lewis & Hoenes               Standards Track                   [Page 19]   

 1043 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
 1046    Occluded names MUST be included in AXFR responses.  An AXFR client      
 1047    MUST be able to identify and handle occluded names.  The rationale      
 1048    for this action is based on a speedy recovery if the dynamic update     
 1049    operation was in error and is to be undone.                             
 1051 4.  Transport                                                              
 1053    AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC   
 1054    1034, which states:                                                     
 1056       Because accuracy is essential, TCP or some other reliable protocol   
 1057       must be used for AXFR requests.                                      
 1059    The restriction to TCP is also mentioned in Section of          
 1060    "Requirements for Internet Hosts - Application and Support"             
 1061    [RFC1123].                                                              
 1063    The most common scenario is for an AXFR client to open a TCP            
 1064    connection to the AXFR server, send an AXFR query, receive the AXFR     
 1065    response, and then close the connection.  But variations of that most   
 1066    simple scenario are legitimate and likely: in particular, sending a     
 1067    query for the zone's SOA resource record first over the same TCP        
 1068    connection, and reusing an existing TCP connection for other queries.   
 1070    Therefore, the assumption that a TCP connection is dedicated to a       
 1071    single AXFR session is incorrect.  This wrong assumption has led to     
 1072    implementation choices that prevent either multiple concurrent zone     
 1073    transfers or the use of an open connection for other queries.           
 1075    Since the early days of the DNS, operators who have sets of name        
 1076    servers that are authoritative for a common set of zones have found     
 1077    it desirable to be able to have multiple concurrent zone transfers in   
 1078    progress; this way, a name server does not have to wait for one zone    
 1079    transfer to complete before the next can begin.  RFC 1035 did not       
 1080    exclude this possibility, but legacy implementations failed to          
 1081    support this functionality efficiently, over a single TCP connection.   
 1082    The remaining presence of such legacy implementations makes it          
 1083    necessary that new general-purpose client implementations still         
 1084    provide options for graceful fallback to the old behavior in their      
 1085    support of concurrent DNS transactions and AXFR sessions on a single    
 1086    TCP connection.                                                         

The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.

This RFC is included in the DNS RFCs annotation project whose home page is here.

GLOBAL V. Risk, ISC.orgBIND 9 implementation note2022-08-15

This RFC is implemented in BIND 9.18 (all versions).

GLOBAL P. Hoffman, ICANNRFC 9103

Many parts of RFC9103, particularly Section 6, update the requirements here for efficient use of TCP.

 1088 4.1.  TCP                                                                  
 1090    In the original definition, there arguably is an implicit assumption    
 1091    (probably unintentional) that a TCP connection is used for one and      
 1092    only one AXFR session.  This is evidenced in the lack of an explicit    
 1093    requirement to copy the Question section and/or the message ID into     
 1097 Lewis & Hoenes               Standards Track                   [Page 20]   

 1098 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
 1101    responses, no explicit ordering information within the AXFR response    
 1102    messages, and the lack of an explicit notice indicating that a zone     
 1103    transfer continues in the next message.                                 
 1105    The guidance given below is intended to enable better performance of    
 1106    the AXFR exchange as well as provide guidelines on interactions with    
 1107    older software.  Better performance includes being able to multiplex    
 1108    DNS message exchanges including zone transfer sessions.  Guidelines     
 1109    for interacting with older software are generally applicable to new     
 1110    AXFR clients.  In the reverse situation -- older AXFR client and        
 1111    newer AXFR server -- the server ought to operate within the             
 1112    specification for an older server.                                      
 1114 4.1.1.  AXFR Client TCP                                                    
 1116    An AXFR client MAY request a connection to an AXFR server for any       
 1117    reason.  An AXFR client SHOULD close the connection when there is no    
 1118    apparent need to use the connection for some time period.  The AXFR     
 1119    server ought not have to maintain idle connections; the burden of       
 1120    connection closure ought to be on the client.  "Apparent need" for      
 1121    the connection is a judgment for the AXFR client and the DNS client.    
 1122    If the connection is used for multiple sessions, or if it is known      
 1123    that sessions will be coming, or if there is other query/response       
 1124    traffic anticipated or currently on the open connection, then there     
 1125    is "apparent need".                                                     
 1127    An AXFR client can cancel the delivery of a zone only by closing the    
 1128    connection.  However, this action will also cancel all other            
 1129    outstanding activity using the connection.  There is no other           
 1130    mechanism by which an AXFR response can be cancelled.                   
 1132    When a TCP connection is closed remotely (relative to the client),      
 1133    whether by the AXFR server or due to a network event, the AXFR client   
 1134    MUST cancel all outstanding sessions and non-AXFR transactions.         
 1135    Recovery from this situation is not straightforward.  If the            
 1136    disruption was a spurious event, attempting to restart the connection   
 1137    would be proper.  If the disruption was caused by a failure that        
 1138    proved to be persistent, the AXFR client would be wise not to spend     
 1139    too many resources trying to rebuild the connection.  Finally, if the   
 1140    connection was dropped because of a policy at the AXFR server (as can   
 1141    be the case with older AXFR servers), the AXFR client would be wise     
 1142    not to retry the connection.  Unfortunately, knowing which of the       
 1143    three cases above (momentary disruption, failure, policy) applies is    
 1144    not possible with certainty, and can only be assessed by heuristics.    
 1145    This exemplifies the general complications for clients in connection-   
 1146    oriented protocols not receiving meaningful error responses.            
 1152 Lewis & Hoenes               Standards Track                   [Page 21]   

 1153 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
 1156    An AXFR client MAY use an already opened TCP connection to start an     
 1157    AXFR session.  Using an existing open connection is RECOMMENDED over    
 1158    opening a new connection.  (Non-AXFR session traffic can also use an    
 1159    open connection.)  If in doing so the AXFR client realizes that the     
 1160    responses cannot be properly differentiated (lack of matching query     
 1161    IDs, for example) or the connection is terminated for a remote          
 1162    reason, then the AXFR client SHOULD NOT attempt to reuse an open        
 1163    connection with the specific AXFR server until the AXFR server is       
 1164    updated (which is, of course, not an event captured in the DNS          
 1165    protocol).                                                              
 1167 4.1.2.  AXFR Server TCP                                                    
 1169    An AXFR server MUST be able to handle multiple AXFR sessions on a       
 1170    single TCP connection, as well as to handle other query/response        
 1171    transactions over it.                                                   
 1173    If a TCP connection is closed remotely, the AXFR server MUST cancel     
 1174    all AXFR sessions in place.  No retry activity is necessary; that is    
 1175    initiated by the AXFR client.                                           
 1177    Local policy MAY dictate that a TCP connection is to be closed.  Such   
 1178    an action SHOULD be in reaction to limits such as those placed on the   
 1179    number of outstanding open connections.  Closing a connection in        
 1180    response to a suspected security event SHOULD be done only in extreme   
 1181    cases, when the server is certain the action is warranted.  An          
 1182    isolated request for a zone not on the AXFR server SHOULD receive a     
 1183    response with the appropriate response code and not see the             
 1184    connection broken.                                                      
 1186 4.2.  UDP                                                                  
 1188    With the addition of EDNS0 and applications that require many small     
 1189    zones, such as in web hosting and some ENUM scenarios, AXFR sessions    
 1190    on UDP would now seem desirable.  However, there are still some         
 1191    aspects of AXFR sessions that are not easily translated to UDP.         
 1193    Therefore, this document does not update RFC 1035 in this respect:      
 1194    AXFR sessions over UDP transport are not defined.                       
 1196 5.  Authorization                                                          
 1198    A zone administrator has the option to restrict AXFR access to a        
 1199    zone.  This was not envisioned in the original design of the DNS but    
 1200    has emerged as a requirement as the DNS has evolved.  Restrictions on   
 1201    AXFR could be for various reasons including a desire (or in some        
 1202    instances, having a legal requirement) to keep the bulk version of      
 1203    the zone concealed or to prevent the servers from handling the load     
 1207 Lewis & Hoenes               Standards Track                   [Page 22]   

 1208 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
 1211    incurred in serving AXFR.  It has been argued that these reasons are    
 1212    questionable, but this document, driven by the desire to leverage the   
 1213    interoperable practice that has evolved since RFC 1035, acknowledges    
 1214    the factual requirement to provide mechanisms to restrict AXFR.         
 1216    A DNS implementation SHOULD provide means to restrict AXFR sessions     
 1217    to specific clients.                                                    
 1219    An implementation SHOULD allow access to be granted to Internet         
 1220    Protocol addresses and ranges, regardless of whether a source address   
 1221    could be spoofed.  Combining this with techniques such as Virtual       
 1222    Private Networks (VPNs) [RFC2764] or Virtual LANs has proven to be      
 1223    effective.                                                              
 1225    A general-purpose implementation is RECOMMENDED to implement access     
 1226    controls based upon "Secret Key Transaction Authentication for DNS      
 1227    (TSIG)" [RFC2845] and/or "DNS Request and Transaction Signatures        
 1228    ( SIG(0)s )" [RFC2931].                                                 
 1230    A general-purpose implementation SHOULD allow access to be open to      
 1231    all AXFR requests.  That is, an operator ought to be able to allow      
 1232    any AXFR query to be granted.                                           
 1234    A general-purpose implementation SHOULD NOT have a default policy for   
 1235    AXFR requests to be "open to all".  For example, a default could be     
 1236    to restrict transfers to addresses selected by the DNS                  
 1237    administrator(s) for zones on the server.                               
 1239 6.  Zone Integrity                                                         
 1241    An AXFR client MUST ensure that only a successfully transferred copy    
 1242    of the zone data can be used to serve this zone.  Previous              
 1243    description and implementation practice has introduced a two-stage      
 1244    model of the whole zone synchronization procedure:  Upon a trigger      
 1245    event (e.g., when polling of a SOA resource record detects a change     
 1246    in the SOA serial number, or when a DNS NOTIFY request [RFC1996] is     
 1247    received), the AXFR session is initiated, whereby the zone data are     
 1248    saved in a zone file or database (this latter step is necessary         
 1249    anyway to ensure proper restart of the server); upon successful         
 1250    completion of the AXFR operation and some sanity checks, this data      
 1251    set is "loaded" and made available for serving the zone in an atomic    
 1252    operation, and flagged "valid" for use during the next restart of the   
 1253    DNS server; if any error is detected, this data set MUST be deleted,    
 1254    and the AXFR client MUST continue to serve the previous version of      
 1255    the zone, if it did before.  The externally visible behavior of an      
 1256    AXFR client implementation MUST be equivalent to that of this two-      
 1257    stage model.                                                            
 1262 Lewis & Hoenes               Standards Track                   [Page 23]   

 1263 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
 1266    If an AXFR client rejects data obtained in an AXFR session, it SHOULD   
 1267    remember the serial number and MAY attempt to retrieve the same zone    
 1268    version again.  The reason the same retrieval could make sense is       
 1269    that the reason for the rejection could be rooted in an                 
 1270    implementation detail of one AXFR server used for the zone and not      
 1271    present in another AXFR server used for the zone.                       
 1273    Ensuring that an AXFR client does not accept a forged copy of a zone    
 1274    is important to the security of a zone.  If a zone operator has the     
 1275    opportunity, protection can be afforded via dedicated links, physical   
 1276    or virtual via a VPN among the authoritative servers.  But there are    
 1277    instances in which zone operators have no choice but to run AXFR        
 1278    sessions over the global public Internet.                               
 1280    Besides best attempts at securing TCP connections, DNS                  
 1281    implementations SHOULD provide means to make use of "Secret Key         
 1282    Transaction Authentication for DNS (TSIG)" [RFC2845] and/or "DNS        
 1283    Request and Transaction Signatures ( SIG(0)s )" [RFC2931] to allow      
 1284    AXFR clients to verify the contents.  These techniques MAY also be      
 1285    used for authorization.                                                 
 1287 7.  Backwards Compatibility                                                
 1289    Describing backwards compatibility is difficult because of the lack     
 1290    of specifics in the original definition.  In this section, some hints   
 1291    at building in backwards compatibility are given, mostly repeated       
 1292    from the relevant earlier sections.                                     
 1294    Backwards compatibility is not necessary, but the greater the extent    
 1295    of an implementation's compatibility, the greater its                   
 1296    interoperability.  For turnkey implementations, this is not usually a   
 1297    concern.  For general-purpose implementations, this takes on varying    
 1298    levels of importance, depending on the implementer's desire to          
 1299    maintain interoperability.                                              
 1301    It is unfortunate that a need to fall back to older behavior cannot     
 1302    be discovered, and thus has to be noted in a configuration file.  An    
 1303    implementation SHOULD, in its documentation, encourage operators to     
 1304    periodically review AXFR clients and servers it has made notes about    
 1305    repeatedly, as old software gets updated from time to time.             
 1307 7.1.  Server                                                               
 1309    An AXFR server has the luxury of being able to react to an AXFR         
 1310    client's abilities, with the exception of knowing whether the client    
 1311    can accept multiple resource records per AXFR response message.  The    
 1312    knowledge that a client is so restricted cannot be discovered; hence,   
 1313    it has to be set by configuration.                                      
 1317 Lewis & Hoenes               Standards Track                   [Page 24]   

 1318 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
 1321    An implementation of an AXFR server MAY permit configuring, on a per    
 1322    AXFR client basis, the necessity to revert to a single resource         
 1323    record per message; in that case, the default SHOULD be to use          
 1324    multiple records per message.                                           
 1326 7.2.  Client                                                               
 1328    An AXFR client has the opportunity to try other features (i.e., those   
 1329    not defined by this document) when querying an AXFR server.             
 1331    Attempting to issue multiple DNS queries over a TCP transport for an    
 1332    AXFR session SHOULD be aborted if it interrupts the original request,   
 1333    and SHOULD take into consideration whether the AXFR server intends to   
 1334    close the connection immediately upon completion of the original        
 1335    (connection-causing) zone transfer.                                     
 1337 8.  Security Considerations                                                
 1339    This document is a clarification of a mechanism outlined in RFCs 1034   
 1340    and 1035 and as such does not add any new security considerations.      
 1341    RFC 3833 [RFC3833] is devoted entirely to security considerations for   
 1342    the DNS; its Section 4.3 delineates zone transfer security aspects      
 1343    from the security threats addressed by DNSSEC.                          
 1345    Concerns regarding authorization, traffic flooding, and message         
 1346    integrity are mentioned in "Authorization" (Section 5), "TCP"           
 1347    (Section 4.1), and "Zone Integrity" (Section 6).                        
 1349 9.  IANA Considerations                                                    
 1351    IANA has added a reference to this RFC in the AXFR (252) row of the     
 1352    "Resource Record (RR) TYPEs" subregistry of the "Domain Name System     
 1353    (DNS) Parameters" registry.                                             
 1355 10.  Internationalization Considerations                                   
 1357    The AXFR protocol is transparent to the parts of DNS zone content       
 1358    that can possibly be subject to Internationalization considerations.    
 1359    It is assumed that for DNS labels and domain names, the issue has       
 1360    been solved via "Internationalizing Domain Names in Applications        
 1361    (IDNA)" [RFC3490] or its successor(s).                                  
 1363 11.  Acknowledgments                                                       
 1365    Earlier draft versions of this document have been edited by Andreas     
 1366    Gustafsson.  In his latest draft version, this acknowledgment           
 1367    appeared:                                                               
 1372 Lewis & Hoenes               Standards Track                   [Page 25]   

 1373 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
 1376       Many people have contributed input and commentary to earlier         
 1377       versions of this document, including but not limited to Bob          
 1378       Halley, Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin         
 1379       Darcy, Robert Elz, Levon Esibov, Mark Andrews, Michael Patton,       
 1380       Peter Koch, Sam Trenholme, and Brian Wellington.                     
 1382    Comments on later draft versions have come from these individuals:      
 1383    Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch,   
 1384    Ian Jackson, Andreas Gustafsson, Brian Wellington, Niall O'Reilly,      
 1385    Bill Manning, and other participants of the DNSEXT working group.       
 1386    Significant comments from the IETF at large have been received from     
 1387    Subramanian Moonesamy, Chris Lonvick, and Vijay K. Gurbani.             
 1389    Edward Lewis served as a patiently listening sole document editor for   
 1390    two years.                                                              
 1392 12.  References                                                            
 1394    All "RFC" references below -- like all RFCs -- and information about    
 1395    the RFC series can be obtained from the RFC Editor web site at          
 1396    http://www.rfc-editor.org.                                              
 1398 12.1.  Normative References                                                
 1400    [BCP14]     Bradner, S., "Key words for use in RFCs to Indicate         
 1401                Requirement Levels", BCP 14, RFC 2119, March 1997.          
 1403    [RFC0793]   Postel, J., "Transmission Control Protocol", STD 7, RFC     
 1404                793, September 1981.                                        
 1406    [RFC0768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,       
 1407                August 1980.                                                
 1409    [RFC1034]   Mockapetris, P., "Domain names - concepts and               
 1410                facilities", STD 13, RFC 1034, November 1987.               
 1412    [RFC1035]   Mockapetris, P., "Domain names - implementation and         
 1413                specification", STD 13, RFC 1035, November 1987.            
 1415    [RFC1123]   Braden, R., Ed., "Requirements for Internet Hosts -         
 1416                Application and Support", STD 3, RFC 1123, October 1989.    
 1418    [RFC1995]   Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,     
 1419                August 1996.                                                
 1421    [RFC1996]   Vixie, P., "A Mechanism for Prompt Notification of Zone     
 1422                Changes (DNS NOTIFY)", RFC 1996, August 1996.               
 1427 Lewis & Hoenes               Standards Track                   [Page 26]   

 1428 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
 1431    [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,     
 1432                "Dynamic Updates in the Domain Name System (DNS UPDATE)",   
 1433                RFC 2136, April 1997.                                       
 1435    [RFC2181]   Elz, R. and R. Bush, "Clarifications to the DNS             
 1436                Specification", RFC 2181, July 1997.                        
 1438    [RFC2671]   Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC      
 1439                2671, August 1999.                                          
 1441    [RFC2672]   Crawford, M., "Non-Terminal DNS Name Redirection", RFC      
 1442                2672, August 1999.                                          
 1444    [RFC2845]   Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.        
 1445                Wellington, "Secret Key Transaction Authentication for      
 1446                DNS (TSIG)", RFC 2845, May 2000.                            
 1448    [RFC2930]   Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY   
 1449                RR)", RFC 2930, September 2000.                             
 1451    [RFC2931]   Eastlake 3rd, D., "DNS Request and Transaction Signatures   
 1452                ( SIG(0)s )", RFC 2931, September 2000.                     
 1454    [RFC3425]   Lawrence, D., "Obsoleting IQUERY", RFC 3425, November       
 1455                2002.                                                       
 1457    [RFC3597]   Gustafsson, A., "Handling of Unknown DNS Resource Record    
 1458                (RR) Types", RFC 3597, September 2003.                      
 1460    [RFC4033]   Arends, R., Austein, R., Larson, M., Massey, D., and S.     
 1461                Rose, "DNS Security Introduction and Requirements", RFC     
 1462                4033, March 2005.                                           
 1464    [RFC4034]   Arends, R., Austein, R., Larson, M., Massey, D., and S.     
 1465                Rose, "Resource Records for the DNS Security Extensions",   
 1466                RFC 4034, March 2005.                                       
 1468    [RFC4035]   Arends, R., Austein, R., Larson, M., Massey, D., and S.     
 1469                Rose, "Protocol Modifications for the DNS Security          
 1470                Extensions", RFC 4035, March 2005.                          
 1472    [RFC4509]   Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer   
 1473                (DS) Resource Records (RRs)", RFC 4509, May 2006.           
 1475    [RFC4635]   Eastlake 3rd, D., "HMAC SHA (Hashed Message                 
 1476                Authentication Code, Secure Hash Algorithm) TSIG            
 1477                Algorithm Identifiers", RFC 4635, August 2006.              
 1482 Lewis & Hoenes               Standards Track                   [Page 27]   

 1483 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
 1486    [RFC5155]   Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS     
 1487                Security (DNSSEC) Hashed Authenticated Denial of            
 1488                Existence", RFC 5155, March 2008.                           
 1490    [RFC5395]   Eastlake 3rd, D., "Domain Name System (DNS) IANA            
 1491                Considerations", BCP 42, RFC 5395, November 2008.           
 1493    [RFC5702]   Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY     
 1494                and RRSIG Resource Records for DNSSEC", RFC 5702, October   
 1495                2009.                                                       
 1497 12.2.  Informative References                                              
 1499    [DNSVALS]   IANA Registry "Domain Name System (DNS) Parameters",        
 1500                http://www.iana.org/.                                       
 1502    [IANA-AF]   IANA Registry "Address Family Numbers",                     
 1503                http://www.iana.org/.                                       
 1505    [RFC2764]   Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.    
 1506                Malis, "A Framework for IP Based Virtual Private            
 1507                Networks", RFC 2764, February 2000.                         
 1509    [RFC3490]   Faltstrom, P., Hoffman, P., and A. Costello,                
 1510                "Internationalizing Domain Names in Applications (IDNA)",   
 1511                RFC 3490, March 2003.                                       
 1513    [RFC3833]   Atkins, D. and R. Austein, "Threat Analysis of the Domain   
 1514                Name System (DNS)", RFC 3833, August 2004.                  
 1516    [DNSSEC-U]  Weiler, S. and D. Blacka, "Clarifications and               
 1517                Implementation Notes for DNSSECbis", Work in Progress,      
 1518                March 2010.                                                 
 1537 Lewis & Hoenes               Standards Track                   [Page 28]   

 1538 RFC 5936            DNS Zone Transfer Protocol (AXFR)          June 2010   
 1541 Authors' Addresses                                                         
 1543    Edward Lewis                                                            
 1544    46000 Center Oak Plaza                                                  
 1545    Sterling, VA  20166                                                     
 1546    US                                                                      
 1548    EMail: ed.lewis@neustar.biz                                             
 1551    Alfred Hoenes, Editor                                                   
 1552    TR-Sys                                                                  
 1553    Gerlinger Str. 12                                                       
 1554    Ditzingen  D-71254                                                      
 1555    Germany                                                                 
 1557    EMail: ah@TR-Sys.de                                                     
 1592 Lewis & Hoenes               Standards Track                   [Page 29]   
section-4.1 P. Hoffman, ICANNRFC 9103

Many parts of RFC9103, particularly Section 6, update the requirements here for efficient use of TCP.