[Freeipa-devel] DNS/bind-dyndb-ldap development plans

Mon Mar 19 20:36:38 UTC 2012

On 03/19/2012 03:28 PM, Martin Kosek wrote:
> On Mon, 2012-03-19 at 09:54 -0400, Dmitri Pal wrote:
>> On 03/19/2012 09:42 AM, Simo Sorce wrote:
>>> On Mon, 2012-03-19 at 14:34 +0100, Petr Spacek wrote:
>>>> Hello list,
>>>>
>>>> there are several big features, that are missing in IPA DNS/plugin now.
>>>> So we have to triage "big features" for next plugin development.
>>>>
>>>> In short - there is a list of biggest features:
>>>> - DNSSEC (Domain Name System Security Extensions) support
>>>> - IDN (Internationalized Domain Names) support
>>>> - DNS test suite
>>>> - Push dynamic database API to upstream
>>>> - More flexible/BIND equivalent record format
>>>> - "Never ending stories" about code quality etc.
>>>>
>>>> All details for each big item is below. BIND LDAP plugin Trac contains a
>>>> lot of minor things + placeholders for some big features.
>>>> URL: https://fedorahosted.org/bind-dyndb-ldap/report/3
>>>>
>>>>
>>>> DNSSEC (Domain Name System Security Extensions) support
>>>> -------------------------------------------------------
>>>> There are some problems to be solved. After discussion with Adam I think
>>>> it is doable. It requires some effort, but IMHO it is crucial feature
>>>> for future.
>>>>
>>>> BIND supports DNSSEC from RHEL5. Fedora 17 will have client side
>>>> support. There should not be any interoperability problem with DNSSEC
>>>> client&  not-DNSSEC-aware server (i.e. current IPA).
>>>>
>>>> https://fedorahosted.org/bind-dyndb-ldap/ticket/56
>>> This seems material for F18 maybe ?
>>
>> Yes this is a priority for RHEL7. I will add to PRD. F18 should be the
>> upstream target.
>
> Exactly. I also think it would be also a nice Fedora 18 feature. Fedora
> 17 introduces "DNSSEC on Workstations", so Fedora 18 would be a good
> time to add a support for FreeIPA DNS servers as well.

I definitely agree.

>>>> IDN (Internationalized Domain Names) support
>>>> --------------------------------------------
>>>> Non ASCII domain names are encoded to ASCII strings. Theoretically it IS
>>>> supported now in plugin, from plugin point of view it is nothing special.
>>>> Another side is support for encoding/decoding strings in all our
>>>> utilities, documentation and testing.
>>>>
>>>> Nowadays it's supported in DNS system from top-level and it's usable.
>>>>
>>>> The Question: Is there any user of this? I'm not really sure if somebody
>>>> really uses IDN. But people with non-latin alphabet will probably have
>>>> another opinion :-)
>>>>
>>>> https://fedorahosted.org/bind-dyndb-ldap/ticket/58
>>> Isn't this a matter of just having the UI compute the right value to
>>> store in the plugin ? I do not think we want to do on the fly
>>> conversions within the plugin, would be very inefficient.
>
> Simo, I suppose you mean that encoding unicode<->punycode in
> bind-dyndb-ldap plugin would be inefficient. I can agree with that. I
> think our DNS plugin (CLI and WebUI) should simply do the
> encoding/decoding from unicode to punycode, bind-dyndb-ldap will then
> just pass the data to bind.
>
>>
>> I am not sure this is a priority. Let us wait until asked.
>
> +1. This may need some designing before we implement it and also we
> would need to define a scope of IDN support in the entire FreeIPA.
> Whether to implement it just for DNS resolution or also for other parts
> where we process hostnames.

I also agree with postponing. Simo is right, it's not about plugin, but 
about UI and other parts as Kerberos etc. I not mentioned it clearly, sorry.

>>>> DNS test suite
>>>> --------------
>>>> We don't have any test suite now. Everything is tested manually, usually
>>>> with dig. (Same situation is there with BIND package.)
>>>>
>>>> Several open source DNS tests are around on Internet. All of them are
>>>> partial and they are usually unmaintained. Test them, select best
>>>> pieces, write what will be missing and combine it to our DNS test suite.
>>>>
>>>> It would be better to start separate "dnstest" project or something
>>>> similar. It can start from simple packaging of selected tools for Fedora
>>>> and then start to integrate them to own test suite.
>>>>
>>>> Our client interface is plain DNS protocol, so it can be reused for BIND
>>>> or any other DNS server.
>>> We have the need of getting a better DNS library in our ipa python
>>> modules, maybe writing tests using that library should be part of the
>>> work of replacing what we currently use.
>>> If we do it right we can make most tests non-ipa specific so that they
>>> can be used to test the plugin as a standalone component.
>>
>> Makes sense to do.

I can't imagine IPA-only DNS test other than simple DNS queries and 
nsupdate. Do you have any other example? I think we use plain 
DNS/DNSSEC, the rest is only about our DNS records.

For this reason I propose to design DNS testing "framework" as totally 
IPA independent. I can imagine this "framework" as more or less 
integrated set of existing tools with some scripting support.
Then we can implement testing scripts ("IPA test suite") for all 
IPA-related records and other things.

IMHO main focus has to be put on trying-out of existing frameworks and 
integrating them together, not developing something big from scratch.

My candidates for deeper exploration:
http://www.zonecheck.fr/
http://www.tahi.org/dns/ (low level DNS tests)
http://www.dnspython.org/ (scripting to glue all thinks together)

We can share this framework with other DNS guys (e.g. Adam :-) and work 
together on improvements. I think they will be happy with this kind of tool.

BTW: Which Python DNS library was selected as substitute for IPA? DNS 
Python (www.dnspython.org)?

>>>> Push dynamic database API to upstream
>>>> -------------------------------------
>>>> I got detailed information from Adam. Situation is better than I knew a
>>>> week ago during meeting.
>>>> Basically, ISC can accept current API, but there are some requirements:
>>>> - small code clean-up (not a big thing)
>>>> - complete documentation (of course)
>>>> - some sort of API tests
>>>> - example driver with *BSD* license, GPL is not acceptable
>>>>
>>>> Really simple driver is acceptable (without any dynamic things), so I
>>>> think it is doable.
>>>>
>>>> I think it will be better to push API to upstream after deep DNSSEC
>>>> inspection and implementation design, some problems can arise...
>>> I think this should have a very high priority.
>>
>> Can you explain this? What API we are talking about?
>
> AFAIU, this is an API for bind name server for dynamic loading of
> database backends (like bind-dyndb-ldap). We need this patch in bind in
> order to be able to use bind-dyndb-ldap with bind. For a long time it
> was not accepted upstream, but was just bundled as a patch in Fedora
> (RHEL).
>
>>
>>>
>>>> More flexible/BIND equivalent record format
>>>> -------------------------------------------
>>>> Current record format in LDAP is less powerful than BIND's. Generally,
>>>> each record can have own TTL value, see RFC1035
>>>> http://tools.ietf.org/html/rfc1035 section 5.1.
>>>> We allow only single value per name, so it's not possible to have e.g.
>>>> single name with long-term A record and short term LOC record.
>>>>
>>>> It probably leads to some performance degradation in some special cases,
>>>> but generally it's not a problem. I think it's very-long-term "nice to
>>>> have". (It is good to remember to this problem in meantime.)
>>>>
>>>> Problem is, that this change will affect LDAP scheme and whole DNS UI,
>>>> so it's very problematic.
>>> Nice to have :-)
>>> We also would need to find a way to make this either optional or make it
>>> w/o breaking the schema, I would defer at this stage.
>>>
>>
>> Open an RFE in BZ if it does not exist and let us leave it there for now.
ACK

>>>> Never ending stories (in progress, of course :-)
>>>> --------------------
>>>> - improve error handling
>>>> - improve configuration (local overriding etc.)
>>>> - stabilize persistent search
>>>> - performance optimization
>>>>
>>>>
>>>>
>>>> Thanks for you patience and sorry for long mail.
>>> Thanks for bringing this up, excellent summary.
>>>
>>
>> Indeed! Thanks!
>>
>>> Simo.
>>>
>>
>>
>
> Yup, Petr, thanks for posting this. It is important to set our course as
> soon as possible so that we can manage to pass the deadlines.
>
> Martin

Petr^2 Spacek