[Opendnssec-develop] Re: 2-phase key backup for ksmutil

[Roland van Rijswijk]

Hi Jakob, Rick,

Jakob Schlyter wrote:
> first, we should decide if this is a problem that OpenDNSSEC should
> address. I'm still not convinced this is the case, but I will look
> into this later this week. I will not be at the f2f meeting in
> Maastricht though.

OK, shame you cannot make it to the f2f as that would've been a good
place to discuss this.

I'll add my €0,02 to the discussion:

The KASP already has functionality to address backing up of key material
so it is aware of the fact that such things can happen. Having this
feature thus means that reckoning with key backup is something that
OpenDNSSEC already addresses.

Unfortunately, the way in which this currently works is not sufficient
when it meets "the real world". In a registrar environment there are
potentially thousands if not 10s or 100s of thousands of zones for which
key material is constantly being generated and updated. So creating a
backup while the current KASP is running is not an option since this may
incorrectly mark keys as being backed up (because - for instance - new
keys were generated while the backup was running).

The only way to do it currently is to stop the KASP, perform the backup
and restart the KASP. Unfortunately, that has certain drawbacks:

* There is no guarantee that someone or some process does not restart
the KASP ad-interim before the "backup done" is sent; this makes this
way of working fragile and potentially unreliable.

* The current ods-control script does not support this way of working;
it has issues with the PID file for the KASP that we have not been able
to solve after much debugging (the PID file is sometimes overwritten or
contains incorrect information). This also makes this way of working
unreliable and requires to add all sorts of extra checks to work around
this issue (manual checks with ps, etc.).

What we are proposing is to solve this using a simple two-phase commit;
it is an extension of existing functionality that is already there by
introducing a new state (these keys are now being backed up). This makes
it safe to back up keys with both the KASP running and the KASP not
running (whichever someone prefers and compatible with existing
implementations). And it has the added bonus of not having to stop an
important component of a running system.

Summarising: in my opinion what we are proposing is an extension to an
already existing feature (namely the KASP being aware of keys being
backed up before they are used).

Cheers,

Roland

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