Difference between revisions of "PowerDNS LDAP Backend/Troubleshooting"

From Linuxnetworks
Jump to: navigation, search
(Troubleshooting)
(Bad search filter)
Line 16: Line 16:
  
 
== Bad search filter ==
 
== Bad search filter ==
Note, that when applying ldap-filter-lookup, in user provided string (remember, no " or ' quotes!) , a string part :target:  
+
Note, that when applying ldap-filter-lookup, in user provided string (remember, no " or ' quotes!), a string part :target:  
is replaced with - without quotes :) - '(associatedDomain=QUERYDATA)' and braces ARE added. So if You create some filter like<BR>
+
is replaced with - without quotes - "(associatedDomain=QUERYDATA)" and braces ARE added. So if You create some filter like
ldap-filter-lookup=(&(:target:)(active=yes))<BR>
+
 
it will result as<BR>
+
ldap-filter-lookup=(&(:target:)(active=yes))
ldap-filter-lookup=(&((associatedDomain=NSQUERYDATA))(active=yes))<BR>
+
 
which results with bad search filter. Instead You should add <BR>
+
it will result as
ldap-filter-lookup=(&:target:(active=yes))<BR>
+
 
 +
ldap-filter-lookup=(&((associatedDomain=QUERYDATA))(active=yes))
 +
 
 +
which results with bad search filter. Instead You should add
 +
 
 +
ldap-filter-lookup=(&:target:(active=yes))
 +
 
 
to get wanted result.
 
to get wanted result.
I guess strbind function should be replaced with some more intuitive version, and probably some  
+
 
ldap-target-attribute-name would be very useful, to be able to decide which attribute actually get used with query.
+
I guess strbind function should be replaced with some more intuitive version, and probably some ldap-target-attribute-name would be very useful, to be able to decide which attribute actually get used with query.
  
 
----
 
----

Revision as of 21:03, 22 April 2006

Troubleshooting

Use of quotation marks ("")

Do never use quotation marks in the PowerDNS config files! They are not evaluated and remain part of the parameter value. This leads to hard to find errors, e.g. no objects are returned from the ldap directory.

No reverse zone transfer

Your ldap tree must contain a seperate subtree of PTR records (e.g. for 1.1.10.10.in-addr.arpa) and you can't set "ldap-method" to "strict".

IPv6 reverse lookup doesn't work in strict mode

For automatically generated reverse IPv6 records your AAAARecord entries must follow two restrictions: They have to be fully expanded ("FFFF::1" is not allowed and it must be "FFFF:0:0:0:0:0:0:1" instead) and they must not contain leading zeros, e.g. an entry containing "002a" is incorrect - use "2a" without zeros instead. These restrictions are due to the fact that LDAP AAAA entries are pure text and doesn't allow searching by wildcards.

Bad search filter

Note, that when applying ldap-filter-lookup, in user provided string (remember, no " or ' quotes!), a string part :target: is replaced with - without quotes - "(associatedDomain=QUERYDATA)" and braces ARE added. So if You create some filter like

ldap-filter-lookup=(&(:target:)(active=yes))

it will result as

ldap-filter-lookup=(&((associatedDomain=QUERYDATA))(active=yes))

which results with bad search filter. Instead You should add

ldap-filter-lookup=(&:target:(active=yes))

to get wanted result.

I guess strbind function should be replaced with some more intuitive version, and probably some ldap-target-attribute-name would be very useful, to be able to decide which attribute actually get used with query.


Feel free to add your own tips



Back to Overview