On 07/08/2015 10:11 AM, Petr Spacek wrote:
On 8.7.2015 17:10, Rich Megginson wrote:
On 07/08/2015 04:31 AM, Petr Spacek wrote:
On 1.7.2015 17:12, Rich Megginson wrote:
On 07/01/2015 09:10 AM, Petr Spacek wrote:
On 1.7.2015 16:43, Rich Megginson wrote:
How much work would it be to support IPA as an AXFR/IXFR client or server
Designate? Right now, their miniDNS component only supports being a master
and sending updates via AXFR, but they have IXFR support planned.
I need to read more about it. Could you please point me to some comprehensive
docs about Designate?
Designate in setups with mini-DNS acts as DNS master server, i.e. the only
source of DNS data/truth. Currently FreeIPA can act only as master, too, which
is not possible.
By "master" do you mean "unable to accept AXFR/IXFR from another server"?
Sort of. DNS is conceptually built around concept of single authoritative
database hosted on Primary Master server. The database is then transferred
using AXFR to Slave servers, which are read-only (and can forward update
requests to the Primary Master).
The Primary Master server is the place where changes are made. There is by
definition only one primary master server per zone, so FreeIPA and Designare
cannot be Primary Masters at the same time.
We need to decide who is going to have control over the data.
I can see several alternatives:
A) Add support for slave zones to FreeIPA.
It should be relatively easy and I guess doable in Fedora 23 time frame if it
gets appropriate priority.
For plain/insecure DNS zones it will allow us to use FreeIPA in place of any
other DNS server but the added value will be negligible because FreeIPA acting
as a slave cannot change the data.
The real added value could be the ability of FreeIPA to DNSSEC-sign zones and
do the DNSSEC key management. I believe that we should be able to re-use
machinery we implemented for master zones in FreeIPA so DNSSEC signing for
slave zones should be almost 'for free'.
When implemented, FreeIPA could become the easiest way how to secure DNS in
Designate with DNSSEC technology even in cases where all the data are managed
by Designate API.
This sounds interesting. This seems like it would fit in with the typical
OpenStack use case - create a new host, assign it a hostname in a sub-zone.
To be sure we understood each other:
In the scenarios where FreeIPA acts as Slave server, the change is done in
Designate and then a new version of the DNS zone is transferred to FreeIPA.
After that FreeIPA can DNSSEC-sign the zone and serve the signed version to
B) We can avoid implementing slave zones by using 'agent':
If I'm not mistaken, this is what you implemented last year.
I implemented support in Designate for a FreeIPA backend which used the JSON
HTTPS API to send updates from Designate to FreeIPA.
Designate has deprecated support for backends.
The agent approach is basically putting a "mini-DNS"-like daemon on each
system which can accept AXFR from Designate. This agent would then use the
backend code I developed to send the data to FreeIPA.
Wow, that is a lot of complexity. I suspect that something like this is
already implemented in dnssyncd written by Martin Basti:
Anyway, I do not see any value in doing so in this particular scenario.
Designate would be the authoritative source of data (Primary Master) so from
functional point of view it would be the same (or worse) than variant (A),
just with more code and more error prone.
C) We can say that combining FreeIPA DNS and Designate does not make sense and
drop what you did last year.
It was already dropped when the backend approach was deprecated.
In current architecture it really does not add
any value *unless* we add DNSSEC to the mix.
D) Integrate IPA installers with Designate API.
This is somehow complementary to variants A (and C) and would allow us to
automatically add DNS records required by FreeIPA to Designate during FreeIPA
installation and replica management.
I wrote a script (ipaextractor.py) that will extract DNS data from FreeIPA and
store it in Designate. That would be a good place to start.
Generally FreeIPA should integrate with other DNS server implementations in a
way similar to this:
Hopefully 4.3 timeframe will allow us to work on that.
In my opinion variants A+D are the best way to move forward. What do you think?
If we could change Designate in some way to work better with FreeIPA, what
would you propose?
How much can we change? :-D I liked the original architecture where Designate
just 'proxied' change requests to DNS implementations/backends.
Me too, but we didn't/don't have much say in the direction/design that
Designate takes . . .
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.
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. 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 :-)
If Designate had such a feature, how would this help us integrate
FreeIPA with Designate?
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code