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

[Dmitri Pal]

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.

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

I am not sure this is a priority. Let us wait until asked.
>
>> 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.

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

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

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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/