[Freeipa-devel] How to support Designate?

[Simo Sorce]

On Tue, 2015-09-01 at 07:17 -0600, Rich Megginson wrote:
> On 09/01/2015 05:39 AM, Petr Spacek wrote:
> > On 1.9.2015 00:42, Rich Megginson wrote:
> >> On 08/31/2015 11:00 AM, Simo Sorce wrote:
> >>> On Mon, 2015-08-31 at 10:15 -0600, Rich Megginson wrote:
> >>>> On 08/31/2015 01:35 AM, Petr Spacek wrote:
> >>>>> On 26.8.2015 20:09, Rich Megginson wrote:
> >>>>>> On 08/25/2015 09:08 AM, Petr Spacek wrote:
> >>>>>>> On 8.7.2015 19:56, Rich Megginson wrote:
> >>>>>>>> On 07/08/2015 10:11 AM, Petr Spacek wrote:
> >>>>>>>>> Assuming that Designate wants to own DNS and be Primary Master, it
> >>>>>>>>> would be
> >>>>>>>>> awesome if they could support standard DNS UPDATE protocol (RFC 2136)
> >>>>>>>>> alongside their own JSON API.
> >>>>>>>>>
> >>>>>>>>> The JSON API is superset of DNS UPDATE protocol because it allows to add
> >>>>>>>>> zones
> >>>>>>>>> but still, standard protocol would mean that standard client (possibly
> >>>>>>>>> guest
> >>>>>>>>> OS inside VM) can update its records without any OpenStack dependency,
> >>>>>>>>> which
> >>>>>>>>> is very much desirable.
> >>>>>>>>>
> >>>>>>>>> The use case here is to allow the guest OS to publish it's SSH key
> >>>>>>>>> (which was
> >>>>>>>>> generated inside the VM after first boot) to prevent Man in the middle
> >>>>>>>>> attacks.
> >>>>>> I'm working on a different approach for guest OS registration.  This
> >>>>>> involves
> >>>>>> a Nova hook/plugin:
> >>>>>> * build_instance pre-hook to generate an OTP and call ipa host-add with the
> >>>>>> OTP - add OTP to new host metadata - add ipa-client-registration script
> >>>>>> to new
> >>>>>> host cloud-init
> >>>>>> * new instance calls script - will wait for OTP to become available in
> >>>>>> metadata, then call ipa-client-install with OTP
> >>>>>> * Floating IP is assigned to VM - Nova hook will call dnsrecord-add with
> >>>>>> new IP
> >>>>> BTW dnsrecord-add can be omitted if standard DNS UPDATE is supported.
> >>>>> ipa-client-install is using DNS UPDATE today.
> >>>> I already have to support the IPA JSON REST interface with kerberos
> >>>> credentials to do the host add, so it is easy to support dsrecord-add.
> >>>>
> >>>>>> https://github.com/richm/rdo-vm-factory/tree/master/rdo-ipa-nova
> >>>>>>
> >>>>>>>>> The same goes for all other sorts of DANE/DNSSEC data or service
> >>>>>>>>> discovery using DNS, where a guest/container running a distributed
> >>>>>>>>> service
> >>>>>>>>> can
> >>>>>>>>> publish it's existence in DNS.
> >>>>>>>>>
> >>>>>>>>> DNS UPDATE supports GSS(API) for authentication via RFC 3007 and that is
> >>>>>>>>> widely supported, too.
> >>>>>>>>>
> >>>>>>>>> So DNS UPDATE is my biggest wish :-)
> >>>>>>>>>
> >>>>>>>> Ok.  There was a Designate blueprint for such a feature, but I can't
> >>>>>>>> find it
> >>>>>>>> and neither can the Designate guys.  There is a mention of nsupdate in the
> >>>>>>>> minidns blueprint, but that's about it.  The fact that Designate upstream
> >>>>>>>> can't find the bp suggests that this is not a high priority for them
> >>>>>>>> and will
> >>>>>>>> not likely implement it on their own i.e. we would have to contribute this
> >>>>>>>> feature.
> >>>>>>>>
> >>>>>>>> If Designate had such a feature, how would this help us integrate
> >>>>>>>> FreeIPA with
> >>>>>>>> Designate?
> >>>>>>> It would greatly simplify integration with FreeIPA. There is a plan to
> >>>>>>> support
> >>>>>>> DNS updates as described in RFC 2136 to push updates from FreeIPA
> >>>>>>> servers to
> >>>>>>> external DNS servers, so we could use the same code to integrate with AD &
> >>>>>>> Designate at the same time.
> >>>>>>>
> >>>>>>> (I'm sorry for the delay, it somehow slipped through the cracks.)
> >>>>>>>
> >>>>>> For Designate for our use cases, we want IPA to be the authoritative
> >>>>>> source of
> >>>>>> DNS data.
> >>>>> Why? In my eyes it is additional complexity for no obvious benefit. DNS is
> >>>>> built around assumption that there is only one authoritative source of data
> >>>>> and as far as I can tell all attempts to bend this assumption did not end
> >>>>> well.
> >>>> But what about users/operators who want to integrate OpenStack with
> >>>> their existing DNS deployment (e.g. IPA or AD)?  Will they allow
> >>>> converting their IPA/AD DNS to be a replica of Designate?
> >>> No, they would not want to, or have no permissions to do so.
> >>> But that shouldn't be a big issue, designate will probably be made to
> >>> manage a completely unrelated namespace.
> >>>
> >>>> This seems to
> >>>> be the obverse of most of the ways OpenStack is integrated into existing
> >>>> deployments.  For example, for Keystone Identity, you don't configure
> >>>> Keystone to be the authoritative source of data for identity, then
> >>>> configure IPA or AD to be a replica of Keystone.  You configure Keystone
> >>>> to use IPA/AD for its identity information.
> >>> Indeed.
> >>>
> >>>>> In my eyes IPA should have ability to integrate with whatever DNS server
> >>>>> admin
> >>>>> wants to use, using standard protocols.
> >>>> Does this mean the best way to support Designate will be to change IPA
> >>>> DNS so that it can be a replica of Designate, and get its data via AXFR
> >>>> from Designate?
> >>> No, we should probably just make it possible for IPA to talk to
> >>> designate to add the necessary records. If Designate is in use, the IPA
> >>> DNS will not be in use and turned off.
> >> Then why use IPA at all?  Would be much simpler for the user to stand up a
> >> PowerDNS or BIND9 which are supported out of the box.
> > Yes, that is basically what I'm saying :-) In my eyes IPA should integrate
> > with whatever DNS server you want to use, be it Designate or anything else. If
> > we have such integration then there is no point in doing two-way
> > synchronization between IPA DNS and <whatever> DNS.
> 
> What does "integration" mean in this context, if it doesn't mean 
> synchronization or zone transfers?

It means that the IPA framework operates directly no an external DNS
server instead of using its own. This means we can still have automatic
changes in DNS w/o using the integrated one. There may be limitations
(like no DNSSEC available, no ability to create forward zones, no
discovery location support or similar) but at least it should be
possible to set the core names that are needed for client discovery and
similar.

Simo.

> >
> >>> It makes little to no sense to replicate stuff out of designate if we
> >>> are not the master server.
> 


-- 
Simo Sorce * Red Hat, Inc * New York