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. > > >> 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. > > > >> 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? 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. > > >> 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 _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel