[Freeipa-devel] DNSSEC: IPA Installation/Upgrade

Simo Sorce ssorce at redhat.com
Mon Jul 7 16:37:05 UTC 2014


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.






More information about the Freeipa-devel mailing list