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: c...@cam.ac.uk
_______________________________________________
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
