I encountered an issue with the way the ldapbackend performs AXFR searches. It assumes that your subdomain entries are children of the parent dn of the entry with your SOA record.
For example, say I have this entry:
In ldapbackend.cc, in the method LdapBackend::list_simple(), two searches are performed to build an AXFR response for mydomain.com. The first search uses the "ldap-basedn" configuration entry from pdns.conf and works fine, like this:
SRCH base="dc=mydomain,dc=com" scope=2 deref=3 filter="&(associatedDomain=mydomain.com)(sOARecord=*)"
However the second search which looks for (associatedDomain=*.mydomain.com), uses the dn of the result of the first search as its basedn. This results in a search that looks like this:
SRCH base="ou=dns,dc=mydomain,dc=com" scope=2 deref=3 filter="associatedDomain=*.mydomain.com"
This assumes that all my subdomain entries are contained in the ou=dns,dc=mydomain,dc=com subtree, which is a bold assumption to make given that in my tree, subdomain are scattered around my tree according to their logical classification.
Accordingly, I have patched ldapbackend.cc (ldapbackend.so) to use the ldap-basedn that I defined rather than the parent dn from the first AXFR related search. Rather than change the current behaviour, I also added a boolean configuration item ldap-basedn-axfr-override which is first evaluated using mustDo().
Given this change, and the presence of the following in pdns.conf:
The resultant second AXFR query looks like:
SRCH base="dc=mydomain,dc=com" scope=2 deref=3 filter="associatedDomain=*.mydomain.com"
It's a simple change but I expect could be very useful to other admins in a use case similar to mine, where your LDAP tree is not designed solely for DNS and you might have host entries outside the same parent DN as your sOARecord. Diff is attached for a patch against the current trunk (also also works for 3.1.1 and 3.0.1, also 2.9.22 when applied manually).
allow overriding base dn for AXFR subtree search, closing #536
git-svn-id: svn://svn.powerdns.com/pdns/trunk/pdns@2934 d19b8d6e-7fed-0310-83ef-9ca221ded41b
Attachment '' (ldapbackend.cc.diff) https://gist.github.com/5466776
applied in r2934, thanks!