ixfr-from-differences - pitfalls and genuine use cases
  • 17 May 2022
  • 3 Minutes to read
  • Contributors
  • Dark
  • PDF

ixfr-from-differences - pitfalls and genuine use cases

  • Dark
  • PDF

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.

From the BIND 9.16.28 ARM

When yes and the server loads a new version of a primary zone from its zone file or receives a new version of a secondary file via zone transfer, it compares the new version to the previous one and calculates a set of differences. The differences are then logged in the zone’s journal file so that the changes can be transmitted to downstream secondaries as an incremental zone transfer.

By allowing incremental zone transfers to be used for non-dynamic zones, this option saves bandwidth at the expense of increased CPU and memory consumption at the primary server. In particular, if the new version of a zone is completely different from the previous one, the set of differences is of a size comparable to the combined size of the old and new zone versions, and the server needs to temporarily allocate memory to hold this complete difference set.

ixfr-from-differences also accepts primary and secondary at the view and options levels, which causes ixfr-from-differences to be enabled for all primary or secondary zones, respectively. It is off for all zones by default.

Note: if inline signing is enabled for a zone, the user-provided ixfr-from-differences setting is ignored for that zone.

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.

We recommend that you do not enable ixfr-from-differences unless you have a good use-case for doing so.

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.

A secondary server receiving an AXFR will delete its .jnl file

This is not a problem, because on the next inbound incremental transfer (IXFR) the .jnl file will be recreated automatically

  1. 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.
You might also be interested in BIND option max-ixfr-ratio

This sets the size threshold (expressed as a percentage of the size of the full zone) beyond which named chooses to use an AXFR response rather than IXFR when answering zone transfer requests.

The minimum value is 1%. The keyword unlimited disables ratio checking and allows IXFRs of any size. The default is unlimited.

See the BIND Administrator Reference Manual (ARM) for more information about IXFRs