RFC 1995 (rfc1995) - Page 3 of 8


Incremental Zone Transfer in DNS



Alternative Format: Original Text Document

< Previous
Next >


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
   of the deleted RRs is the older SOA RR and the first RR of the added
   RRs is the newer SOA RR.

   Modification of an RR is performed first by removing the original RR
   and then adding the modified one.

   The sequences of differential information are ordered oldest first
   newest last.  Thus, the differential sequences are the history of
   changes made since the version known by the IXFR client up to the
   server's current version.

   RRs in the incremental transfer messages may be partial.  That is, if
   a single RR of multiple RRs of the same RR type changes, only the
   changed RR is transferred.

   An IXFR client, should only replace an older version with a newer
   version after all the differences have been successfully processed.

   An incremental response is different from that of a non-incremental
   response in that it begins with two SOA RRs, the server's current SOA
   followed by the SOA of the client's version which is about to be
   replaced.

   5. Purging Strategy

   An IXFR server can not be required to hold all previous versions
   forever and may delete them anytime. In general, there is a trade-off
   between the size of storage space and the possibility of using IXFR.

   Information about older versions should be purged if the total length
   of an IXFR response would be longer than that of an AXFR response.
   Given that the purpose of IXFR is to reduce AXFR overhead, this
   strategy is quite reasonable.  The strategy assures that the amount
   of storage required is at most twice that of the current zone
   information.



Ohta                        Standards Track


< Previous
Next >


Web Standards & Support:

Link to and support eLook.org Powered by LoadedWeb Web Hosting
Valid XHTML 1.0! Valid CSS! eLook.org FireFox Extensions