Choosing the right value for max-journal-size

BIND has several features that permit authoritative zones to be updated incrementally.  These include primary-to-secondary incremental updates (IXFR), primary zone dynamic updates, and in-line signing. In all of these situations, named maintains a journal (.jnl) file for the zone.  There are two reasons for this:

1. The in-memory (operational) version of the zone is being updated directly in these operations will not immediately be backed up to disk.  If there is an interruption, when named is restarted it will be able to reconstruct and load the most current version of the zone from the older disk copy, with the more recent updates reapplied from the journal file.

2. The updated zone is available for incremental transfer to other servers that request and are allowed to transfer them.

A primary zone that is updated by editing the zone file and reloading it can also have an associated journal file. One will be generated and maintained automatically if the option ixfr-from-differences is set to yes either globally, or for that specific zone.

The configuration option max-journal-size is used to restrict the size of named's journal files:

Limiting the size of journal (.jnl) files with max-journal-size

The question then arises, what is a good value for max-journal-size?

A good rule of thumb is to choose a small (single-digit) multiple of the size of the primary file. IXFR is designed to speed up zone transfers but if an IXFR is bigger than the zone itself then that defeats its primary purpose.

Note however that setting max-journal-size does not prevent a zone's journal file from exceeding the limit that has been configured.

named checks the .jnl file size each time it stores a zone from memory to the backup disk file, but it might be that there have been significant numbers of or sizes of updates since the last write, so max-journal-size could be exceeded because of the number and size of updates made since the last write of the zone file to disk.

How often the zone file is written to disk depends on how active the zone is. If there's not already a zone backup scheduled, then after receiving a zone update, named will schedule one for 15 minutes hence.  Therefore, although there may be more zone updates and incremental updates to the .jnl file between the scheduling and the actual backup, the frequency of zone backups to disk is rate-limited so that they don't occur more often than once every 15 minutes.

After the backup, named will 'prune' the .jnl file per max-journal-size, but it will not remove any entries that have not yet been committed to the disk backup version, even if this means that the resulting file exceeds max-journal-size (so here is another reason why max-journal-size is not an absolute cap).

The "pruning" is done by writing an appropriately trimmed version of the .jnl file to a temporary file on disk and then renaming to replace the original.

Considerations for local .jnl files:

In terms of performance, both the zone write to disk and the pruning of the .jnl file are going to slow a server if being executed too frequently.  On the other hand, oversized .jnl files are also very bad ("walking" the file during its use when it is over-sized can really slow things down).

You can't "hurt" named's zone integrity by setting the limit too low, however, because it will always ignore the limit when pruning or when adding new entries, if they're necessary for the zone to be recoverable on a restart. named is never going to delete any entries that it would need to recover in case of a crash - i.e. that have been added to the .jnl since the last write to disk of the zone file.

Considerations for .jnl files used for outbound IXFRs:

A zone's journal file is also used for responding to outbound transfer requests, so administrators will want to tune the server so that most of the time, IXFRs are being sent for small zone updates, but AXFRs are being sent for larger ones.

Servers requesting a zone transfer will (according to their own configuration and current zone status) request either AXFR (the full zone) or IXFR. An IXFR request asks for all the incremental updates needed to bring a zone from a starting SOA serial number to the latest/current serial number of the providing authoritative server. If the journal file no longer has the transactions necessary to fulfill the request (the starting SOA serial number is no longer in the journal file because it has been reduced in size past that historic point), then it will send an AXFR instead of the IXFR that was requested.

In this way, the value of max-journal-size can also restrict the size of outbound zone transfers. And of course, whether or not zone notifies are reaching a server, as well as the refresh time on the SOA record, will also control how often a zone refresh and transfer is being requested by specific secondaries.