[Opendnssec-user] distributed OpenDNSSEC (distributed database and HSM)

[Petr Spacek]

On 6.3.2014 14:30, Jerry Lundström wrote:
> Hi Petr,
>
> On 06 Mar 2014, at 14:06 , Petr Spacek <pspacek at redhat.com> wrote:
>
>> Thank you for information, I will look into live DB. How it works on upgrade - generally? What if proto-buffer definition was changed between versions? Are there differences between 1.x and 2.x?
>
> Protobuf-orm is total new with 2.0 and I don’t know if any work has been done on upgrade after 2.0. The database schema are different, maybe not very but they are. Upgrade path from 1.x to 2.x will be an export/import step and upgrade path within 1.x have been SQL statements that you run manually.
>
>> The original proposal was also about 'distributed operation', i.e. multiple enforcers running and coordinating among multiple machines at the same time (possibly via shared database or something like that).
>>
>> I think this will require more significant changes than 'mere' database backend.
>
> If you want the Enforcer to understand its running in multiple places, yes that is a bit change and needs more high level design before we can start implementing. But if you can control which instance of the Enforcer that is running and make sure only one does, you can use what we got today and “just" add a new backend.
The high-level idea is described here:
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm

We expect that enforcer will run on N machines in parallel. If N-1 machines 
die nothing happens, the last enforcer will generate keys as scheduled and 
store them to 'networked-HSM' so all signers will still have fresh keys.

As usual, the interesting part is synchronization. We could use a quorum 
protocol but then there is a problem when N-1 enforcers die.

Another (maybe naive) alternative is to do 'opportunistic key generation' and 
solve conflicts (i.e. more keys generated at once) when they happen.
This idea is briefly described on
https://www.redhat.com/archives/freeipa-devel/2013-September/msg00047.html

There will be unsolved corner cases for sure. Any comments are more than welcome!

(The original thread on freeipa-devel died but now we are reviving it here :-)

-- 
Petr^2 Spacek