[Freeipa-devel] How to support Designate?

Thu Jul 9 10:32:07 UTC 2015

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