On Mon, 2014-06-30 at 17:13 +0200, Martin Basti wrote: > On Tue, 2014-06-24 at 11:49 +0200, Petr Spacek wrote: > > On 23.6.2014 17:49, Martin Basti wrote: > > > On Mon, 2014-06-23 at 17:44 +0200, Martin Basti wrote: > > >> Hello, > > >> I have following issues: > > >> > > >> #1 Upgrading existing replicas to support DNSSEC won't work for current > > >> design (replica-file as storage for temporal replica key). > > >> Temporal private key needs to be copied to replica, and no encrypted > > >> master-key for replica is prepared in LDAP, because user doesn't need to > > >> run ipa-replica-prepare. > > >> > > >> After discussion with Petr2, the solution is: > > >> a) Each replica (except first - which generates master-key) generates > > >> replica public and private keys. > > >> b) Replica uploads public key to LDAP > > >> c) Replica with generated master key, use the public key (b) to encrypt > > >> master-key and store it to LDAP. Replica with master-key must detect, if > > >> there is any new public replica key. > > >> d) Replica (b) is now able to get master-key using own private replica > > >> key > > >> > > >> > > >> #2 We need to choose only one replica which will generate, (rotate, ...) > > >> DNSSEC keys. > > > and generate master key too > > > > > >> My proposal is to test during installation/upgrade if any dnssec/master > > >> keys are in LDAP. If no key was found, the first server is > > >> installed/upgraded and DNSSEC key generator is required. > > >> > > >> But there is issue with parallel upgrade multiple replicas (or if > > >> replication temporarily doesn't work). There is no guarantee if replicas > > >> will be able to detect if any replica became DNSSEC key generator. > > > > Let me add that we are going to use syncrepl anyway so the overall latency > > should be minimal (if replication works). > > > > Simo what do you think about it, could you tell us your opinion?
I think DNSSEC should not be enabled by default, so on upgrade no action should be taken. Activation/upgrade of DNSSEC feature should be manual so that no conflict can arise. Simo. _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel