Incremental Zone Transfer in DNS (RFC1995)
Original Publication Date: 1996-Aug-01
Included in the Prior Art Database: 2019-Feb-14
Internet Society Requests For Comment (RFCs)
This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism. [STANDARDS-TRACK]
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.
This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism.
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 cli...