[Pdns-dev] Query on LDAP backend

Jamie Thompson pdns.dev at jamie-thompson.co.uk
Mon Jul 21 01:19:28 CEST 2008


Hi, sorry for the cross-posting, but I guess pdns-users was the wrong place for 
this sort of enquiry, so here it is again :)

I'm migrating from ldapdns to pdns and it's LDAP backend (ldapdns's lockups are 
killing me), and have hit a interesting snag, namely I suspect due to some 
unusual interpretation of the RFCs by ldapdns or yourselves. I'm not saying what 
you currently do is wrong by any means, I'm just intrigued why the use of the 
associatedDomain attribute is apparently hardcoded, forcing you to pull in the 
domainRelatedObject objectclass for each domain object in the tree? My initial 
guess is simplicity, as the query string needn't be processed, just plugged into 
the query filter.

The crux of the issue is that I designed my tree to mimic the DNS hierarchy:
dc=jamie-thompson,dc=co,dc=uk,dc=.
dc=1,dc=1,dc=168,dc=192,dc=in-addr,dc=arpa,dc=.
...and so on.

This works just fine with ldapdns, but doesn't with pdns-ldap, as I have no 
associatedDomain attributes, the information from which probably being inferred 
from the LDAP tree structure by ldapdns.

This seems reasonable to me, as duplicating the information from the DN in the 
associatedDomain seems superfluous, it's just as easy to transform the query 
"www.jamie-thompson.co.uk" into...
base: "dc=www,dc=jamie-thompson,dc=co,dc=uk" + rootValue
filter: "(dc=*)" (or even better, dc=<leftmost component of domain query>)
scope: base
...or thereabouts.

My reading of the RFC is that all that's required is the objectClass dNSDomain 
(or more likely given you do things more correctly with PTR records, 
dNSDomain2), and the only required attribute for that is "dc" (domainComponent), 
which would seem to mesh with what I have/want. domainRelatedObject's 
associatedDomain attribute seems to be intended for non-linearly mapped 
directories, so that ou=jamie-thompson could then have the associatedDomain of 
jamie-thompson.co.uk without any additional fluff. Which is indeed useful, but 
not quite what I'm after.

Anyway, want I mean by that rambling is that it'd be nice to have the option of 
a mode that uses the basic dc attributes as the search base, and the filter 
solely used to filter the results by whatever arbitrary filter the sysadmin 
wants. I've already found and am using ldap-method=tree, but it still seems to 
be looking for associatedDomain attributes in my entries.

Since my post to pdns-users I've since gone through adding the required 
objectClasses and associatedDomain attributes, but ideally I'd still prefer a 
cleaner tree.

Thoughts?

- Jamie


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://mailman.powerdns.com/pipermail/pdns-dev/attachments/20080721/a629ec50/signature.bin


More information about the Pdns-dev mailing list