[Opendnssec-develop] Enforcer NG minutes 20110912
Yuri Schaeffer
yuri at NLnetLabs.nl
Mon Sep 12 14:07:37 UTC 2011
> The Enforcer NG telecon minutes for today's call are online
> We have a lot of discussion about new behaviour w.r.t. DS
> submit/retract. We decide to keep the behaviour that Yuri and René
> implemented for the alpha even though this means an extra interaction
> for the user during a KSK rollover (needs to be documented in the
> README)
I just had a good hart to hart talk with Matthijs about this.
The bottom line is that the engine does support an atomic switch of the
DS (I had trouble reasoning about and explaining it during the call).
Also when doing a switch of DS RRs it does not matter at all if the
ds-seen or ds-gone command is given first and the amount of time between
them (For a moment I was afraid it would).
But since the enforcer-ng supports an arbitrary amount of KSKs at any
given time and keys are not coupled to rollovers, you would always have
to specify which key is seen and which is gone. Thus leaving the
following extra options:
enforcer key ds-swap --zone example.com --seen 12345 --gone 98765
You specify exactly what keys, but it is not better than two commands
or
enforcer key ds-IDidEverythingAtTheParentYouAskedMeTo --zone example.com
Applies all oustanding requests for zone. This leaves much room for
error at the user. Giving the command but just do half of the tasks.
How I see it, the rational behind having just one command is that the
purpose is to have just one interaction with the parent, and having the
user communicate twice with the enforcer defeats this purpose. But I
don't think this is true. The number of user interactions is not related
to the number of parent interactions but to the number of keys involved.
Which I think is rather reasonable.
So for now a seen and a gone command seem like the best way to go. Like
said before lets keep it this way and see how the testers respond.
//yuri
--
Yuri Schaeffer
NLnet Labs
http://www.nlnetlabs.nl
More information about the Opendnssec-develop
mailing list