On 08/07/15 20:45, Rich Megginson wrote:
It receives AXFR/IXFR, Notify from DNS master, and updates data by
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:
Sort of. DNS is conceptually built around concept of single
database hosted on Primary Master server. The database is then
using AXFR to Slave servers, which are read-only (and can forward
On 07/08/2015 04:31 AM, Petr Spacek wrote:
By "master" do you mean "unable to accept AXFR/IXFR from another
On 1.7.2015 17:12, Rich Megginson wrote:
Designate in setups with mini-DNS acts as DNS master server, i.e.
source of DNS data/truth. Currently FreeIPA can act only as
master, too, which
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
I need to read more about it. Could you please point me to some
Designate? Right now, their miniDNS component only supports
being a master
and sending updates via AXFR, but they have IXFR support planned.
docs about Designate?
is not possible.
requests to the Primary Master).
The Primary Master server is the place where changes are made. There
definition only one primary master server per zone, so FreeIPA and
cannot be Primary Masters at the same time.
We need to decide who is going to have control over the data.
This sounds interesting. This seems like it would fit in with the
OpenStack use case - create a new host, assign it a hostname in a
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
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
machinery we implemented for master zones in FreeIPA so DNSSEC
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
by Designate API.
To be sure we understood each other:
In the scenarios where FreeIPA acts as Slave server, the change is
Designate and then a new version of the DNS zone is transferred to
After that FreeIPA can DNSSEC-sign the zone and serve the signed
I implemented support in Designate for a FreeIPA backend which used
B) We can avoid implementing slave zones by using 'agent':
If I'm not mistaken, this is what you implemented last year.
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
system which can accept AXFR from Designate. This agent would then
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:
How does this work? Does it receive zone transfer (AXFR? IXFR?) from
a DNS master, then update LDAP with those records?
You can write own plugin for it to support any DNS server/backend.
But it is proof of concept, it is not rock stable.
Anyway, I do not see any value in doing so in this particular scenario.
Designate would be the authoritative source of data (Primary Master)
functional point of view it would be the same (or worse) than
just with more code and more error prone.
Generally FreeIPA should integrate with other DNS server
implementations in a
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.
I wrote a script (ipaextractor.py) that will extract DNS data from
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
installation and replica management.
store it in Designate. That would be a good place to start.
way similar to this:
Hopefully 4.3 timeframe will allow us to work on that.
How much can we change? :-D I liked the original architecture where
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
would you propose?
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
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
but still, standard protocol would mean that standard client
OS inside VM) can update its records without any OpenStack
is very much desirable.
The use case here is to allow the guest OS to publish it's SSH key
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
discovery using DNS, where a guest/container running a distributed
publish it's existence in DNS.
DNS UPDATE supports GSS(API) for authentication via RFC 3007 and
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