On Mon, 2014-07-07 at 16:10 +0200, Petr Spacek wrote: > On 30.6.2014 17:38, Simo Sorce wrote: > > 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. > > I think we can do a compromise. > > First of all, DNSSEC will not be enabled until admin explicitly decides to do > so. It is per-zone setting exposed in API/CLI/Web UI. Clients will not see > any > change if the "DNSSEC checkbox" is not enabled for at least one DNS zone. > > IMHO it is reasonable to automatically install dependencies we need during > upgrade. I.e. to install softhsm package to every replica by default and also > generate replica keys (wrapping keys) by default. > > I agree that key-master-server election (used in IPA 4.1) can be done > manually. I.e. all replica keys will be generated automatically but admin has > to run something like ipa-dns-install --dnssec-master on one replica to > explicitly mark one replica as key generator. This replica will run > OpenDNSSEC > daemon responsible for key maintenance. > > This approach will save us terrible headache from manual dependency > installation and situations where DNSSEC-feature-dependencies were installed > on some replicas but are not present on all of them etc. > > Do you agree?
Sounds reasonable. Simo. _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel