Incremental Zone Transfer in DNS
RFC 1995

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

Network Working Group                                            M. Ohta
Request for Comments: 1995                 Tokyo Institute of Technology
Updates: 1035                                                August 1996
Category: Standards Track

                    Incremental Zone Transfer in DNS

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document proposes extensions to the DNS protocols to provide an
   incremental zone transfer (IXFR) mechanism.

1. Introduction

   For rapid propagation of changes to a DNS database [STD13], it is
   necessary to reduce latency by actively notifying servers of the
   change.  This is accomplished by the NOTIFY extension of the DNS
   [NOTIFY].

   The current full zone transfer mechanism (AXFR) is not an efficient
   means to propagate changes to a small part of a zone, as it transfers
   the entire zone file.

   Incremental transfer (IXFR) as proposed is a more efficient
   mechanism, as it transfers only the changed portion(s) of a zone.

   In this document, a secondary name server which requests IXFR is
   called an IXFR client and a primary or secondary name server which
   responds to the request is called an IXFR server.

2. Brief Description of the Protocol

   If an IXFR client, which likely has an older version of a zone,
   thinks it needs new information about the zone (typically through SOA
   refresh timeout or the NOTIFY mechanism), it sends an IXFR message
   containing the SOA serial number of its, presumably outdated, copy of
   the zone.

Ohta                        Standards Track                     [Page 1]
RFC 1995            Incremental Zone Transfer in DNS         August 1996

   An IXFR server should keep record of the newest version of the zone
   and the differences between that copy and several older versions.
   When an IXFR request with an older version number is received, the
   IXFR server needs to send only the differences required to make that
   version current.  Alternatively, the server may choose to transfer
   the entire zone just as in a normal full zone transfer.

   When a zone has been updated, it should be saved in stable storage
   before the new version is used to respond to IXFR (or AXFR) queries.
   Otherwise, if the server crashes, data which is no longer available
   may have been distributed to secondary servers, which can cause
   persistent database inconsistencies.

   If an IXFR query with the same or newer version number than that of
   the server is received, it is replied to with a single SOA record of
   the server's current version, just as in AXFR.

   Transport of a query may be by either UDP or TCP.  If an IXFR query
   is via UDP, the IXFR server may attempt to reply using UDP if the
   entire response can be contained in a single DNS packet.  If the UDP
   reply does not fit, the query is responded to with a single SOA
   record of the server's current version to inform the client that a
   TCP query should be initiated.

   Thus, a client should first make an IXFR query using UDP.  If the
   query type is not recognized by the server, an AXFR (preceded by a
   UDP SOA query) should be tried, ensuring backward compatibility.  If
   the query response is a single packet with the entire new zone, or if
   the server does not have a newer version than the client, everything
   is done.  Otherwise, a TCP IXFR query should be tried.

   To ensure integrity, servers should use UDP checksums for all UDP
   responses.  A cautious client which receives a UDP packet with a
   checksum value of zero should ignore the result and try a TCP IXFR
   instead.

   The query type value of IXFR assigned by IANA is 251.

3. Query Format

   The IXFR query packet format is the same as that of a normal DNS
   query, but with the query type being IXFR and the authority section
   containing the SOA record of client's version of the zone.

Ohta                        Standards Track                     [Page 2]
RFC 1995            Incremental Zone Transfer in DNS         August 1996

4. Response Format

   If incremental zone transfer is not available, the entire zone is
   returned.  The first and the last RR of the response is the SOA
   record of the zone.  I.e. the behavior is the same as an AXFR
   response except the query type is IXFR.

   If incremental zone transfer is available, one or more difference
   sequences is returned.  The list of difference sequences is preceded
   and followed by a copy of the server's current version of the SOA.

   Each difference sequence represents one update to the zone (one SOA
   serial change) consisting of deleted RRs and added RRs.  The first RR