[Freeipa-devel] How to support Designate?

Wed Sep 2 14:00:49 UTC 2015

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?

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

How?

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