Converting an inline-signed zone to unsigned
g.clinch at lancaster.ac.uk
Thu Mar 6 20:24:05 UTC 2014
> Thanks - I have now tried that (set the deletion date to "now" with
> dnssec-settime), and it does work. You end up with a [zone-file].signed
> which is not actually signed being served, but being maintained from
> [zone-file] in an incremental way.
> I suppose this is indeed the way to go with the flow of inline signing.
> You don't even have to have any keys for the zone in the key directory
> initially. It's the transition between having "inline-signing yes" and
> "inline-signing no" in the zone definition that seems to expose rough
> edge cases.
Is [zone-file].signed really being maintained? When I took an unsigned
zone and enabled inline-signing without generating any keys, the zone
content became 'frozen in time' until keys were generated (at least with
In short, these messages are logged:
info: zone test1.local/IN (unsigned): loaded serial 2014030615
info: zone test1.local/IN (signed): serial 2014030615 (unsigned 2014030615)
error: zone test1.local/IN (signed): could not get zone keys for secure
error: zone test1.local/IN (signed): receive_secure_serial: not found
But despite showing unsigned and signed zone both with serial
2014030615, the 'signed' one actually still has 2014030610 - the serial
at the point of enabling inline-signing.
> I still have to investigate the problem that Graham Clinch reported,
> and see whether that might be a show-stopper for the application of
> inline signing that I have in mind.
> More generally: it's a pity that there isn't any real documentation
> of inline signing in the ARM, just the examples in ISC's KB articles.
> Some clearer explanation of which options "inline-signing yes" is
> (in)compatible with would be helpful. For example, it obviously turns
> on some sort of moral equivalent of "ixfr-from-differences yes" on
> the unsigned version of the zone, but would turning inline signing
> on (or off) work better if this were specified explicitly? And the
> examples have "auto-dnssec maintain", but would "auto-dnssec allow"
An 'rndc sync -clear test1.local' clears both zonefile.jnl and
zonefile.signed.jnl. It doesn't seem to modify the zonefile (because
it's only recording past differences as a side effect of inline-signing
enabling ixfr-from-differences??), but it does mean that the signed zone
doesn't have IXFR data anymore, which probably leads me back to just
blowing away zonefile.jnl (or hoping that named doesn't stop/isn't
stopped - although I'm obviously hoping that anyway...).
More information about the bind-users