[Pdns-dev] LDAP backend fork

Grégory Oestreicher greg at kamago.net
Wed Dec 12 22:51:33 CET 2012

Hi All,

Following a chat with the PowerDNS chaps on IRC I've decided to fork the LDAP 
backend. The reasons are explained in the project README, but as no-one ever 
reads those I'll just paste it below. It saves me typing time :)

I don't know if there LDAP backend users on these lists, even less if there 
are any left, but a little publicity over this fork is needed to start it up.

For those that won't read the README below here is the summary:
- The LDAP backend has been forked (temporarily hopefully) into a separate 
project, whose source code is available at http://repo.or.cz/w/pdns-ldap-
- Support for the new backend must not go on the PowerDNS lists. I don't want 
the pdns guys bothered by requests they won't be able to handle. Everything 
should go to the project ML: pdns-ldap-backend at sequanux.org (you can subscribe 
at http://sequanux.org/cgi-bin/mailman/listinfo/pdns-ldap-backend)
- Send patches!
- The new backend adds GSSAPI auth support and is able to reconnect to the 
LDAP server when it went down temporarily

More may come to this backend :)


-------------- README --------------
This is a fork of the official PowerDNS LDAP backend module and
is intended to be used as a drop-in replacement for it. As such
the library name is the same.

As this project is independent from PowerDNS support requests
related to the new functionnalities should be sent to the
mailing list pdns-ldap-backend at sequanux.org (go to
to subscribe).

The latest version of the code is available from

All bug reports should go to the mailing list for now.

Why a fork?

First the situation of the official LDAP backend is not good.
The original developer stopped maintaining it, and nobody
stepped in to replace him. The developer of PowerDNS did
maintain it in the official tree, checking that it's still
compiling, but unfortunately they have no knowledge of LDAP
and can't spend resources on this module. Furthermore they
express legitimate doubts on the interest of maintaining
a module for which they have little usage return.

So here it is for the vicious cycle: no users -> no incentive
to maintain the module -> users are not interested in a
module that's not maintained.

Now Grégory Oestreicher (the chap writing these lines, but
referred later at the third person should this change) had
developed some patches to add GSSAPI authentication to the
LDAP backend. They were submitted, but will never be
integrated in the main tree for two reasons:
- nobody but their author can validate them in the actual
  situation. As they are consequent it's hard for someone
  without LDAP and Kerberos knowledge to vouch for them.
  And as said above the PowerDNS authors can't dedicate
  time to this backend;
- their author cannot commit himself to become the official
  maintainer of the LDAP backend. Yeah, this sucks but at
  least it's not giving false hopes.

Another problem faced by the LDAP backend is the lack of 
automated regression tests.

The PowerDNS developers and PowerDNS BV are clearly not to
blame for this, and their work should be praised. Forking
a software is not in this case due to an argument that
overheated or to some ego who wants to have more power
(though this can be debatted :).

So why the fork?

These patches can be useful to a more general audience than
the readers of the pdns-dev mailing list, where they were
originally submitted. As they won't be integrated into the
main tree, and as the license permits forks, the decision
was taken to temporarily part ways.

Maintaining an external repository should have two
- Allowing the backend to evolve at its rythm, without
  the need of a full commitment to the backend maintainership.
- Showing that the backend still moves however and attract
  actual users. This would be a good message to send to
  the PowerDNS devs that this backend is still alive
  and kicking.

Maintenance status

As the maintenance is a one-man operation, and given that
the time of said man is rather limited, the backend should
be considered as 'sporadically updated'. One major
bug of the backend (issues 260 and 323 for those that used
the official PDNS bug tracker) have already been addressed,
making it more robust.

However future evolution is subject to
- free time of the author, as well as his mood and the
  disposition of the start;
- people sending patches.

More information about the Pdns-dev mailing list