Updating inline-signed masterfile whilst named is stopped causes 'journal rollforward failed'

Graham Clinch g.clinch at lancaster.ac.uk
Tue Mar 4 13:32:23 UTC 2014

I'm trialling inline-signing with our provisioning system which 
generates master files (rather than performing dynamic updates).

The configuration directives in use are:

         inline-signing yes;
         key-directory "/etc/bind/dnssec_keys/test1.local";
         auto-dnssec maintain;

There is 1 KSK and 1 ZSK, and an NSEC3 chain (configured via rndc 
signing -nsec3param ...), and the initial signing process has completed.

If I modify the original zonefile and reload the zone, a zonefile.jnl is 
created/updated, correctly identifying the modification I made in the 
original.  My changes are also applied across to zonefile.signed(.jnl) 
with the additional RRSIG bits.  This is all working ok.  If I restart 
named, everything is fine.

If I stop named, modify the original zonefile, and restart named, the 
zone refuses to load:

general: error: zone test1.local/IN (unsigned): journal rollforward 
failed: journal out of sync with zone
general: error: zone test1.local/IN (unsigned): not loaded due to errors.

If I stop named, modify the original zonefile, *remove the 
zonefile.jnl*, and restart named, the zone loads ok:

04-Mar-2014 13:05:41.816 general: info: zone test1.local/IN (unsigned): 
loaded serial 2014030415
04-Mar-2014 13:05:42.646 general: info: zone test1.local/IN (signed): 
loaded serial 2014083141 (DNSSEC signed)

And the modifications I made are correctly reflected in 
zonefile.signed(.jnl), so the zonefile.jnl doesn't appear to be used.

And so, to my actual question: Is it safe for the provisioning system to 
remove zonefile.jnl when it writes a new zonefile?

If zonefile.jnl doesn't serve any purpose (for non-dynamic, 
inline-signed zones - I can't see one), could named not create it at all 
(something for bugs@?)

This feels similar but not identical to Chris Thompson's mail from the 
19th of February.  I wonder whether there was also a playground.test.jnl?


More information about the bind-users mailing list