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? 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.
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?
What is the benefit of the other approach?
Petr^2 Spacek
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.
--
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
