Converting an inline-signed zone to unsigned
cet1 at cam.ac.uk
Thu Mar 6 21:03:11 UTC 2014
On Mar 6 2014, Graham Clinch wrote:
>> 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
Oh, ****. You are right. Using 9.9.5, I get messages exactly like that
when updating the unsigned zone file while there are no keys. I am not
sure how I previously managed to convince myself otherwise.
I think I am going to have to retreat hurt from this attempt to use
inline signing, and find some other way of achieving what I want.
Email: cet1 at cam.ac.uk
More information about the bind-users