On 08/07/15 20:45, Rich Megginson wrote:
On 07/08/2015 11:56 AM, Rich Megginson wrote:
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
with
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?
Thanks!
http://docs.openstack.org/developer/designate/architecture.html
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).
See http://tools.ietf.org/html/rfc2136#section-1
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
the clients.
B) We can avoid implementing slave zones by using 'agent':
http://docs.openstack.org/developer/designate/glossary.html
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:
https://github.com/bastiak/dnssyncd
How does this work? Does it receive zone transfer (AXFR? IXFR?) from
a DNS master, then update LDAP with those records?
It receives AXFR/IXFR, Notify from DNS master, and updates data by
Dynamic DNS.
You can write own plugin for it to support any DNS server/backend.
But it is proof of concept, it is not rock stable.
Martin
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:
https://fedorahosted.org/freeipa/ticket/4424
http://www.freeipa.org/page/V4/External_DNS_integration_with_installer
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 . . .
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 :-)
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?
--
Martin Basti
--
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
