Incremental Zone Transfer in DNS
updated by
- rfc-9103 — DNS Zone Transfer over TLS
updates
- rfc-1035 — Domain names - implementation and specification
Extracted elements (20)
A server may optionally condense multiple difference sequences into one, dropping intermediate version history. This is useful when many transient updates (e.g., round-robin IP cycling) would otherwise inflate stored history without value.
AXFR transfers the entire zone file regardless of how small the change is, making it inefficient for propagating small updates. IXFR transfers only the changed portions, reducing bandwidth and latency for secondary server synchronization.
RRs in incremental transfer messages may be partial: if only one RR among multiple RRs of the same type changes, only the changed RR is transferred, minimizing response size.
The purging strategy for old difference data is to delete versions when the total IXFR response size would exceed that of an AXFR response. This caps storage overhead at at most twice the current zone size while preserving the efficiency benefit of IXFR.
Optional condensation can break clients that have received an intermediate version from one server but query a second server that has condensed that version away. The second server cannot provide incremental data from the unknown version and must fall back to a full zone transfer.
When a UDP IXFR response overflows a single DNS packet, the server replies with a single SOA record only (no zone data). The client must detect this and re-issue the query over TCP.
A client should first issue an IXFR query via UDP. If the entire response fits in one DNS packet it is delivered; if not, the server returns a single SOA indicating the client must retry over TCP.
An IXFR client should only replace an older zone version with a newer version after all difference sequences have been successfully processed, ensuring atomic application of incremental updates.
If an IXFR query arrives with a serial number equal to or newer than the server's current version, the server replies with a single SOA record of the server's current version, as in AXFR.
If an IXFR query type is not recognized by the server, the client should fall back to AXFR (preceded by a UDP SOA query), ensuring backward compatibility with servers that do not implement IXFR.
IXFR servers should not flag an error when receiving a request with an unknown version number; instead they should attempt a full zone transfer, preserving interoperability when condensation has dropped intermediate versions.
Servers should use UDP checksums for all UDP responses. A cautious client that receives a UDP packet with a checksum value of zero should ignore the result and retry using TCP IXFR.
When a zone is updated, it should be saved to stable storage before the new version is used to respond to IXFR or AXFR queries. Failure to do so risks distributing data that becomes unavailable after a server crash, causing persistent database inconsistencies.
An IXFR client is a secondary name server that requests incremental zone transfer; an IXFR server is a primary or secondary name server that responds to such requests. The server should keep the newest zone version and differences between that and several older versions.
Each difference sequence represents one SOA serial increment: deleted RRs are listed first (starting with the old SOA), then added RRs (starting with the new SOA). Modification of an RR is performed by first removing the original and then adding the modified one.
The IXFR query packet uses the same format as a normal DNS query, with QTYPE=IXFR (251). The authority section MUST contain the SOA record reflecting the client's current (presumably outdated) version of the zone.
The query type value IXFR is assigned by IANA as 251.
Though DNS is related to several security problems, RFC 1995 makes no attempt to fix them. The document is believed to introduce no additional security problems to the existing DNS protocol.
An incremental IXFR response begins with two SOA RRs: the server's current SOA followed by the SOA of the client's version being replaced. Each difference sequence then consists of deleted RRs (starting with the older SOA) followed by added RRs (starting with the newer SOA), ordered oldest-first.
If incremental transfer is unavailable, the response is a full zone transfer: the first and last RR are the server's current SOA, with the full zone contents in between — identical to AXFR except QTYPE=IXFR.