Browse Prior Art Database

Incremental Zone Transfer in DNS (RFC1995) Disclosure Number: IPCOM000004205D
Original Publication Date: 1996-Aug-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 6 page(s) / 16K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People



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

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 18% of the total text.

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.

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


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.

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 ...