journal files in bind9

[Stefan Puiu]

Hello,

it might depend on which of the 9.2 BIND servers you are using, I can 
only give you information about 9.2.3. The BIND 9 ARM (Administrator's 
Reference manual, I think) available with the BIND distribution says 
that 'rndc stop' should also first write the in-memory zone (which 
includes updates that are in the journal, but didn't make it yet to the 
zone file) to disk - that is, in the zone file. On the other hand, 'rndc 
halt' also halts the BIND server, but without saving the zone. 
Theoretically, when you restart BIND, the nameserver checks the journals 
for each zone (it can't possibly know how it was stopped) and compares 
the SOA serial in the zone file to the end journal serial; if the 
highest SOA serial in the journal is higher than the one in the zone 
file, the updates that are stored in the journal between the two serial 
numbers are "rolled forward" (you might see messages like "zone 
rollforward: ..." in your BIND logs every now and then).

If this sounds elliptic, you might want to read the section about DDNS 
updates in the ARM (the part about DDNS in "DNS & BIND", 4th edition 
from O'Reilly would be helpful, too). The best documentation for the 
BIND journal structure is the source, that is, lib/dns/journal.c and 
lib/dns/include/dns/journal.h under the BIND source distribution - you 
don't need to know C, the structure is explained in comments. Basically, 
updates are stored like IXFR packets, in chunks like this:

<OLD SOA>
<deleted RRs>
<NEW SOA>
<added RRs>

At least that's what the journal reading API gives you, the actual 
low-level structure also includes some markers, indexes, etc that you 
don't need to worry about.

You should remove the journal files if you change the zone SOA serial 
number manually, and then restart BIND. BIND just compares the two SOA 
serial numbers, and it might be mislead in thinking it needs to roll 
forward the zone, when it actually shouldn't. On Windows at least I've 
seen that if BIND fails to roll forward a zone, it doesn't properly 
serve the zone afterwards. If you leave the zone as it is between 'rndc 
stop' and restarting BIND, the journal files shouldn't be harmful; it's 
just that BIND would try each time to check whether they contain updates 
that need to be flushed in the zone, but I don't think that's time 
consuming.

The only problem I see with journal files is size: they seem to grow 
indefinitely in BIND 9.2 (9.3 has an option for limiting that), so if 
you get lots of DDNS updates you might want to periodically remove the 
journal files. They stay the same even after the zone is updated, no 
entries are removed, only some are invalidated, not sure exactly based 
on what criteria.

Jeff wrote:

>BIND 9.2 DDNS and journal (<db-file>.jnl) file update question:
>
>When 'rndc stop' is issued, and dbfile.jnl entries are flushed to the actual
>dbfile, what happens to the jnl file? ... are the entries that were just
>flushed still in the *.jnl? or are they removed? ... if the newly flushed
>entries remain in the jnl, how does named know not to overwrite the dbfile
>next flush (after named is started back up of course)? serial number entries
>in the jnl file? other?
>
>I am trouble-shooting an odd problem where my DB files arent always updated
>with an 'rndc stop' and am wondering if leaving the journal files in place,
>even after an rndc stop, is ok.  Or removing them (as we always do) is
>adding to the problem ... I know most people remove them for good house
>keeping, but I could find nothing on the web documented saying that it was
>NOT okay to leave them in place ... my sysadmin is under the impression that
>you "must" remove them ... i dont know where he got this idea and was trying
>to figure out a definitive (documented) answer ..
>
>
>
>  
>