Converting an inline-signed zone to unsigned

Chris Thompson 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 
>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

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.

-- 
Chris Thompson
Email: cet1 at cam.ac.uk


More information about the bind-users mailing list