[Freeipa-devel] How to support Designate?

[Petr Spacek]

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

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.

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 :-)

-- 
Petr^2 Spacek