Converting an inline-signed zone to unsigned

[Graham Clinch]

> 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 
versions
'9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu3' &
'9.9.5-2-Ubuntu').

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 
dynamic update
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"
> work?

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...).

Graham