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