[Freeipa-devel] How to support Designate?

[Simo Sorce]

On Wed, 2015-09-02 at 08:00 -0600, Rich Megginson wrote:
> On 09/01/2015 07:34 AM, Simo Sorce wrote:
> > 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.
> 
> So this is the same as the case where a customer already has DNS and 
> wants to use it, and we tell them how to set up their DNS with the 
> records that IPA needs?

No it goes beyond that, we have the framework enabled to do changes to
the DNS.

> > This means we can still have automatic
> > changes in DNS w/o using the integrated one.
> 
> How?

nsupdate as the simplest integration option, perhaps plugin with use of
native APIs if available.

Simo.

> > 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