[Freeipa-devel] How to support Designate?

Wed Jul 8 17:56:37 UTC 2015

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
>
> 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?