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

Mon Mar 19 14:28:04 UTC 2012

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