[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Suitability of LDAP as DNS backend - PowerDNS LDAP backend moving to unmaintained status

On Tuesday, 3 May 2011 11:57:36 Torsten Schlabach (Tascel eG) wrote:
> On Tue, 3 May 2011 08:28:02 +0200 (SAST), Buchan Milne
> <bgmilne@staff.telkomsa.net> wrote:
> >> I just wanted to add that according many testimonies, like:
> https://lists.isc.org/mailman/htdig/bind-users/2011-February/082814.html,
> >> BIND9
> >> with LDAP over DLZ has a very low performance, making it unsuitable
> >> for
> >> production systems,
> > 
> > No, making it unsuitable for directly serving DNS clients. The
> recommended
> > architecture with bind sdb_ldap for use with a high query load is that a
> > named running sdb_ldap be set up as a "hidden" master, with the slaves
> > running traditional file-backed zones to serve DNS clients.
> > 
> > Regards,
> > Buchan
> Honestly, I am not sure how much sense this extra layer makes. I mean,
> yes, it solves to the problem but to me this is as logical as writing a
> script which converts the LDAP database content into zone files and run
> that script via cron.

Not really. You can still point *some* clients at your hidden master. All our 
internal DNS (forward/reverse for all our internal addresses) is on BIND 
sdb_ldap, queried directly by our internal servers ....

> What I like about BIND with DLZ and LDAP is: I edit
> something and it's there.
> How often would one recommend the slaves to initiate a zone transfer from
> the master in Buchan's recommended scenario? Daily? Hourly?

Whenever the serial is changed, as a notify can be sent to the slaves (there 
is a slapi plugin for this, but it should probably be replaced with an 
overlay). The same way "normal" BIND slave propagation takes place.

> If PowerDNS really is so much faster and so much more lightweight (i.e. I
> have to install only what I need; something which always concerned be a bit
> when it comes to BIND) then it may indeed be worthwhile to look at.

It is so much faster than BIND sdb_ldap, because BIND sdb_ldap has *no* 
caching on the BIND side, whereas normal file-based zones are cached in 

> Just me
> personally our our organization, I cannot promise any real time budget for
> that right now.
> Also - while asking myself how much this is becoming off-topic on an
> OpenLDAP list, but the guys at ISC are also undertaking some serious
> efforts about BIND 10, which I understand will be a full re-write; see
> http://www.isc.org/bind10 and
> http://bind10.isc.org/wiki
> One question which I guess *does* belong here is what the plans for BIND
> 10 with regards to LDAP storage are. Maybe some active contribution may be
> even useful. I think they are also heavily preparing for the long awaited
> future called IPv6. I am not sure how well BIND 9 with DLZ and / or
> PowerDNS perform for IPv6 right now, especially thinking about the schema.

IPv6 is a non-issue, AFAIK both bind sdb_ldap and PowerDNS have had aAAArecord 
support for years before there was anything interesting to consumers on IPv6.