[Freeipa-devel] How to support Designate?

[Rich Megginson]

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 makes little to no sense to replicate stuff out of designate if we
>>> are not the master server.