[Freeipa-devel] How to support Designate?

Wed Jul 8 18:45:11 UTC 2015

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?

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