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?
Graham
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
