[Freeipa-devel] How to support Designate?
Rich Megginson
rmeggins at redhat.com
Wed Aug 26 18:09:21 UTC 2015
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
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.
When a client wants to read data from Designate, that data should
somehow come from IPA. I don't think Designate has any sort of proxy or
pass-through feature, so the data would have be sync'd from IPA. If IPA
supports being a server for AXFR/IXFR, Designate could be changed to
support AXFR/IXFR client side, then would just be a slave of IPA. If
IPA does not support zone transfers, then we would need some sort of
initial sync of data from IPA to Designate (I wrote such a script for
Designate
(https://github.com/openstack/designate/blob/master/contrib/ipaextractor.py).
Then, perhaps some sort of proxy/service that would poll for changes
(syncrepl?) in IPA, then submit those changes to Designate (using
Designate REST API, or DNS UPDATE when Designate mDNS supports it).
When a client wants to update data in Designate, we need to somehow get
that data into IPA. The only way Designate pushes data out currently is
via AXFR, which doesn't work for IPA to be a direct slave of Designate.
What might work is to have an "agent" that gets the AXFR, then somehow
converts that into IPA updates. This would only work if the volume of
updates is fairly low. If Designate supported IXFR it would be much better.
More information about the Freeipa-devel
mailing list