On Wed, 2015-09-02 at 08:09 -0600, Rich Megginson wrote:
> On 09/02/2015 08:07 AM, Simo Sorce wrote:
> > 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.
> 
> I'm assuming this option does not exist currently.  Is there a freeipa 
> ticket for this?

https://fedorahosted.org/freeipa/ticket/4424

Simo.


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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to