[Opendnssec-develop] Importing shared keys

Roland van Rijswijk roland.vanrijswijk at surfnet.nl
Wed Jul 21 10:57:23 UTC 2010

Hi Sion,

Sion Lloyd wrote:
> Why shouldn't the key be used?

Because the other zones in the policy already participate in a
shared-key scheme, right? And it is not a "new" (fresh) key since it is
already in use for a zone. Thinking about this: I guess a move from
unshared to shared is:

- Add zone to shared policy
- Import zone keys into policy
- Next policy-based roll or user forced roll will move zone from
unshared to shared
- Discard keys

Would that work?

> Okay. I think that I misunderstood "rollover" in this... Do you mean that we 
> immediately retire the current set of keys, or just that all new keys will 
> come from the new policy?

I think both are valid options, see above.

> I have a story set up for this:
> http://www.pivotaltracker.com/story/show/1086197
> Moving from unshared to shared is okay I think, anything else is a bit more 
> tricky; but let's not worry about that right now.

I can see why anything else might be a bit more tricky. Isn't it
possible, though, to assign one key to multiple policies? In that case,
a move from shared to unshared could be:

- Assign shared key to new unshared policy
- Next policy-based roll or user forced roll will move zone from shared
to unshared
- Remove shared key from policy

The problem here - I think - is that you cannot discard the shared key
until all zones that used to share it have moved to an unshared policy;
a possible solution is to introduce reference counting (i.e. keys have
an attribute that specifies the number of policies a key is used in).
Keys can only be discard once the reference count reaches 0. Obviously
you would need to be able to distinguish between "fresh" unused keys and
"dirty" used keys.



-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl

More information about the Opendnssec-develop mailing list