ixfr-from-differences - pitfalls and genuine use cases

Operators of authoritative BIND DNS servers may be aware of the option ixfr-from-differences that can be used to generate and maintain a journal (.jnl) file of incremental differences, tracking the changes that have been made to the zone content over time. A .jnl file can be used to recover/roll-forward an out of date copy of a zone on disk when named is restarted. It is also used to serve incremental zone updates (IXFRs) to secondary servers.

A typical and sensible use case for ixfr-from-differences is one where zone maintenance is carried out offline, which then results in a new version of the zone file on disk to be loaded (with named continuing to run) by the primary or provisioning server, from whence the new zone content is propagated to client-facing authoritative DNS servers using IXFR.

DNS server operators need to be aware that the process of generating a set of differences (journal file) from two versions of the zone is not without significant overhead and also some pitfalls. Along with the notes about this option/feature as documented in the Administrator Reference Manual, here are a few other considerations:

1. The overhead of creating the set of differences between two versions of a zone is resource-intensive and this can cause delays in responding to client queries for names in this zone. Those delays (even in a multi-threaded BIND server implementation) can create further delays in processing queries for other unrelated names if all of the query-handling threads are waiting for access to the zone currently undergoing ixfr-from-differences handling. We therefore do not recommend enabling ixfr-from-differences on authoritative servers that also handle client queries.

2. The time and resource requirements for applying an incremental update to a zone increase exponentially with the size of set of differences (as bounded by the 'before' and 'after' serial number in the zone's SOA record). Therefore, if there are significant differences to propagate from a primary or provisioning server to its secondaries, using a full zone content replacement transfer (AXFR) will usually be more efficient. Most zone operators are aware of this and will respond to IXFR requests with an AXFR when they have made many changes to their zone (for example, DNSSEC re-signing or regeneration of NSEC3 chains). Enabling ixfr-from-differences on intermediate servers involved in zone propagation overrides this optimisation choice.

3. There is no practical advantage to maintaining .jnl files unnecessarily on servers that are secondaries for a zone but which themselves do not provide outbound IXFRs to other servers. The .jnl files will be created anyway with received inbound IXFRs (this is normal and necessary) but it is not a problem that an occasional AXFR removes the pre-existing .jnl file for this zone; see the note in the blue information box, above.