[Freeipa-devel] How to support Designate?

[Rich Megginson]

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.

>
> It makes little to no sense to replicate stuff out of designate if we
> are not the master server.
>
> Simo.
>