9.16.13 overwrites master files if old format .jnl files are present

Summary

9.16.13 overwrites master files if old format .jnl files are present

BIND version used

This bug can occur in BIND versions 9.16.13, 9.16.13-S1, 9.16.14, 9.16.14-S1, 9.17.11, and 9.17.12

What exactly happens?

Under some conditions, named will overwrite a zone file that would not be overwritten otherwise. If you have not backed up your zone data you could potentially lose important meta-data.

Quick Summary (TL;DR)

I am not using ixfr-from-differences yes;, am I affected?

No, named does not produce journal files for static primary zones.

I am using dynamic zones, am I affected?

No, named already manages the zone file, so this is not anything new.

I am using ixfr-from-differences yes; and I am generating the zone file, am I affected?

Not really, this happens only once (when the journal is upgraded) and you will overwrite the zone file in the next run anyway.

Is any zone data lost?

No zone data is lost. Only comments and directives like $INCLUDE and $GENERATE would be lost. The new zone file contains a correct dump of current zone contents.

When does it happen?

When named is trying to load a zone (e.g. upon system startup, server reconfig, or zone reload) and it finds present a journal (.jnl) file from an old journal file format: that is, anything before Change 5362, meaning any release of the BIND 9.16 branch prior to 9.16.12 (i.e. 9.16.11 or lower) or any release of any branch of BIND older than the 9.16 branch (i.e. 9.0 to 9.15)

Because it can occur at system startup when an old-format journal file is present, it is a risk to people who use features that produce journal files (ixfr-from-differences yes;) and who are upgrading from a BIND version that writes old-format journals to one of the affected versions listed above.

Why does it happen?

When an affected version (see above) finds an old-format journal file present, it attempts to apply the journal file and re-write the zone data file. The intention was that this would be a transparent fix not requiring operator intervention for dynamic zones (the most common situation where a journal file would exist) but it did not properly consider the presence of zone files associated with the ixfr-from-differences yes; setting. Those files, too, can be overwritten.

I am upgrading from a version of BIND <= 9.16.12 (if 9.16 or 9.16-S) or from any prior branch (9.0 - 9.15) to one of the releases listed above. How can I prevent loss of the meta-data?

You have several options:

1. You can simply delete journal files produced by ixfr-from-differences as long as you know they do not contain pending unwritten changes to the zone, as journal files created by dynamic update might.

2. Back up your zone files before beginning your upgrade and restore from the backup if anything gets overwritten. (This is good advice in any case. If you are manually maintaining zone data files have you considered using a revision control system to improve recoverability and allow for tracking of changes?)

3. Use named-journalprint -u to upgrade the format of any journal files present so that named does not attempt the automatic recovery that can cause problems. That is:

   • stop named
   • install the upgraded BIND package
   • run named-journalprint -u [filename] on any journal files present
   • start named from the newly upgraded binary

Steps to reproduce

Upgrade to 9.16.13 from an older version, with old version .jnl files present. Bind then logs a message similar to

Mar 27 14:10:38 ns named[3989862]: zone mountain-skies.org/IN/normal: retried using old journal format

What is the current bug behavior?

In that case, the master file for the zone is re-written with the current zone contents. In my case, the master files are all maintained in ascii text format via other tools.

What is the expected correct behavior?

The master file should not be touched.