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

[Simo Sorce]

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 ?

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


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


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


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


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

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York