New maintainer:
This is the new location of the Bind 9 LDAP sdb back-end. This page will have to stay untill I have had time to make a new one...
/Turbo Fredriksson, New Maintainer for the bind9 ldap sdb back-end

LDAP sdb back-end for BIND 9

This is an attempt at an LDAP back-end for BIND 9 using the new simplified database interface "sdb". Using this you can store zones in LDAP rather than in files. Note that when using sdb, the zones are not cached in memory, BIND will do a database lookup whenever it gets a query. If you want to store zones in LDAP but still have BIND do caching, you may be interested in the ldap2zone tool.

Mailing list

A mailing list is now available for discussions and announcements related to this back-end and other issues related to DNS and LDAP. To join the list, go here. Questions you might have regarding this back-end should also go to the list. There is also an archive that might contain answers.

Releases

Below are the different releases with sources and changes since previous release. I would generally suggest using the most recent. In addition to the below there are some other ways you can obtain it. A number of people are packaging and building it for different platforms. For FreeBSD you may want to use these ports.

The latest releases are the stable 1.0 and the more experimental development release 1.1.0

Feel free to try my own, highly experimental 1.1.1 release. Please report any bugs or issues you might have with it!

CVS Repository

With the new maintainence, there is now a CVS repository and the CVS repository can be viewed over the web at the URL https://cvs.bayour.com/cgi-bin/cvsweb/bind9-ldap/. To checkout the 1.0 version (unchanged from the 1.0 release done by Stig Veenas), execute the following two commands after each other (just press the ENTER key when asked for a password): 
        cvs -d :pserver:anonymous@cvs.bayour.com:/var/cvs login
        cvs -d :pserver:anonymous@cvs.bayour.com:/var/cvs co -rUPSTREAM_1_0 bind9-ldap
To retreive Stig's 1.1.0 version, exchange UPSTREAM_1_0 with UPSTREAM_1_1_0.

Schemas

A schema called dNSZone is used. The Cosine dNSDomain schema defines some RR types, but not enough for our use. dNSZone adds all the useful RR types I think, but let me know if there's some you think should be added. In addition to the RR types dNSZone also adds TTL, class, zone name and relative domain name. The code doesn't care about class, but I added it for completeness. Here's a howto for using the dnsZone schema with the back-end.

Roman A. Egorov has written a utility called zone2ldif for converting a zone file into an LDIF file that uses the dNSZone schema. This is quite useful for moving your existing zone files into LDAP. Also, if you're not sure how to use the schema, you could first write a zone file and then use this utility to see how it's done.

A related utility by Jeffry McNeil is zone2ldap It will try to write the zone to LDAP rather than just creating LDIF.

You can speed up the LDAP searches done by BIND quite a lot by using indexing. In your LDAP server configuration you should specify that you want equality indexing on the zoneName amd relativeDomainName attributes.

Master and slave configurations

Using the back-end master servers will make an LDAP query each time they receive a query. There are some advantages to that, but it will of course be slower than using BIND's memory caching. Also note that this back-end appears to be stable, but it has not been tested as heavily as BIND itself, which means that the same level of stability can't be assumed.

One way to solve this could be to have a stealth master, not giving it an NS record, and have at least two slaves. The slaves can be any nameserver software you like, and will use AXFR and do caching as usual. In many situations LDAP lookups might be fast enough and you might like the advantage of instant updates. You could then have several masters all using LDAP. You should then use LDAP replication or whatever so that the masters use different LDAP servers. There's no point in several masters and one LDAP server.

DHCP

A number of people have asked for Dynamic DNS support, or how they can make their DHCP server do DNS updates. There is now a tool that allows a zone to be updated based on the ISC DHCP server's lease database updates. The tool is dhcp2ldapd-1.1 and is a Perl script written by Travis Groth.

Changes in short

2007-07-03
Finished a bind9-ldap package for Debian GNU/Linux and Ubuntu. Packages for Feisty is done, and packages for Sarge is building right now.
I think I have, with the 1.1.1 version, managed to fix the problem with bind9 reload (a reload failed previously because the bind didn't work). Please test this (either packages or by checking out HEAD).

2007-06-30
Spent the whole day merging all my changes from my days with the LDAP sdb. The changes I've done is in the HEAD branch in the CVS repository, and it's change log is also availible.

2007-06-29
I, Turbo Fredriksson, took over maintainence on the request of author, Stig Veenas. Started to import the code into CVS, tagged UPSTREAM_1_0 for his 1.0 version, and tag UPSTREAM_1_1_0 for the 1.1.0 version.
I'm currently in the process of merging my changes and fixes that I've been using on my own installations. To test/use this version, please checkout the HEAD branch from CVS. This is still experimental (and migt compile - I'll merge all changes/differences first, then fix any compile problems etc). Any patches etc will be much appreciated. Please mail these to the mailinglist.

2005-05-01
Two new releases are available. First is the 1.0 release. This is identical to the beta release and is the one to use in production. There is also release 1.1.0 which has a number of experimental features. I believe it works well, but I advice testing that in a non-production environment. The main new feature is perhaps support for URLs with ldaps and ldapi schemes when using OpenLDAP libraries. This means you can use SSL or UNIX domain sockets. The use of UNIX domain sockets should give better performance than TCP/IP. Other features are support for specifying search scope and which LDAP attributes to request.

2004-08-22
The 1.0-beta release fixes a memory leak present since 0.8. I recommend upgrading to this release, especially if you have problems with BIND eating up too much memory. The only new feature since 1.0-alpha is optional TLS support. This will become the official 1.0 release unless any problems show up.

2004-04-12
The 1.0-alpha release uses LDAPv3 by default while previous versions used the LDAP library's default which usually is LDAPv2. It also supports LDAP simple bind. That is, one can use plain-text password for authentication. Except for this, it's identical to 0.9.

2002-04-17
In version 0.9 the code has been cleaned up a bit and should be slightly faster than previous versions. It also fixes an error with zone transfers (AXFR) and entries with multiple relativeDomainName values. The problem was that it would only use the first value in the result.

2001-12-29
Version 0.8 uses asynchronous LDAP search which should give better performance. Thanks to Ashley Burston for providing patch. Another new feature is allowing filters in URLs. Some error logging has also been added.

2001-09-11
Version 0.7 allows space and other characters to be used in URLs by use of %-quoting. For instance space can be written as %20. It also fixes a problem with some servers and/or APIs that do not preserve attribute casing.

2001-06-16
Version 0.6 fixes a memory leak present when not using the RFC 1823 API.

2001-05-06
Version 0.5 introduces thread support and improved connection handling, and also support for URLs with literal IPv6 addresses. See README for details.

2001-04-12
Since 0.4 a new schema called dNSZone is used. In my opinion this schema is much better than what was used in prior versions. The main advantage is that you can store your zones any way you like in the directory tree.

venaas@uninett.no (original author)
turbo@bayour.com (new maintainer/author)
Last modified: 2011-02-22