[Freeipa-devel] FreeIPAv2 with dns zones stored in ldap

Jeff Schroeder jeffschroed at gmail.com
Tue May 27 23:45:24 UTC 2008


On Tue, May 27, 2008 at 1:20 PM, Simo Sorce <ssorce at redhat.com> wrote:
> On Tue, 2008-05-27 at 10:31 -0700, Jeff Schroeder wrote:
>> The FreeIPA V2BPRD document[1] mentions storing dns information in
>> ldap. How do you plan on accomplishing this?
>> Will redhat be adding in the bind patch[2] to enable storing zone
>> files in ldap or use an alternative server like powerdns?
>> Which schema will you be using for this? I'm interested in setting up
>> a copy of (RH|F)DS and whatever is needed to start
>> working on and testing this. The upstreams for all projects that store
>> dns zones in ldap other than powerdns seem awful
>> quiet.
>>
>> Any pointers or ideas would be much appreciated.
>>
>>
>> [1] http://freeipa.org/page/V2BPRD#1._Machine_Identity_and_Authentication
>>  [1.1.1] Store DNS information in LDAP
>> [2] http://bind9-ldap.bayour.com/
>
>
> Jeff we are not yet completely sold to any schema or server, I have been
> working and testing with bind some, so far I am not completely satisfied
> with any solution.
>
> Aside from caching problems (apparently bind does not cache stuff if the
> backend uses sdb, there is also a DNS Update problem in that bind does
> not allow you to update info into an sdb backend at this point.
>
> Access Control when using GSS-TSIG is also extremely limited with bind
> at this point.
>
> I am lookig for a solution that present the least resistance path for
> getting in what we need.

Ok so I've got an idea that might or might not work. It seems like the
path of least resistance.

Re-implement ldap2dns in python. Use python-ldap to read the zones
from ldap and python bindings
for libaugeas to write the zones out.

The implementation would run something like this:
- A script, cronjob, or daemon in freeipa runs every XXX amount of
time and checks the serial
  number of every zone on disk to the zone in ldap.
- If the zone in ldap is newer ldap2dns dumps the new zone to disk
- A backup of the old zone is made, the new zone is moved into place,
and rndc reload $zone is ran

The cleanest solution is native ldap support in bind. The problem is
that the patch is not in upstream
bind and hasn't been updated in some time. Unless redhat or someone
dusts that patch off and tries to
get it upstream it is a deadend. Short of that happening, my solution
seems like the path of least resistance.

Here is a diagram of the LDAP setup I'd like to use:
http://www.digitalprognosis.com/pics/fds-multimaster.png

You could have ldap + dns on the same server. Since ldap is the
canonical source for zone information,
every bind instance could be master and AXFR could be disabled. A lot
of these ideas come from
Nathaniel Mccallum, a buddy of mine. I'm willing to work with you the
code as best as possible. This
seems related to one of the goals of FreeIPA so we might be able to
work together.

-- 
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com




More information about the Freeipa-devel mailing list