Updating inline-signed masterfile whilst named is stopped causes 'journal rollforward failed'
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:
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