Description of problem: After configuring bind with dyndn-ldap support, dyndn-ldap cannot find any stored DNS zone in configured LDAP directory. This is due to wrong ldap search filter: "(&(objectClass=idnsZone)(?idnsZoneActive=True))" (from openldap log). The wrong part of filter is a value of idnsZoneActive attribute... it should be "TRUE" instead of "True", becasue this attribute has syntax "1.3.6.1.4.1.1466.115.121.1.7", which is boolean. In second, I don't understand the "?" character before the idnsZoneActive attribute. Version-Release number of selected component (if applicable): bind-dyndb-ldap-0.1.0-0.2.a1.fc11.x86_64 bind-9.6.1-4.P1.fc11.x86_64 openldap-servers-2.4.15-3.fc11.x86_64 How reproducible: Configure LDAP server with some DNS records (based on bind-dyndns-ldap schema), configure a dyndb module part in named.conf like this: dynamic-db "foo.local" { library "ldap.local"; arg "uri ldap://ares.foo.local"; arg "base ou=Dynamic,ou=DNS,ou=Sluzby,dc=foo,dc=local"; arg "bind_dn cn=bind,ou=DSA,dc=foo,dc=local"; arg "password p4ss"; arg "auth_method simple"; arg "cache_ttl 300"; }; example of stored idnsZone: dn: idnsName=0.0.127.in-addr.arpa,ou=Dynamic,ou=DNS,ou=Sluzby,dc=foo,dc=local objectClass: top objectClass: idnsZone objectClass: idnsRecord idnsName: 0.0.127.in-addr.arpa idnsZoneActive: TRUE nSRecord: ns.foo.local. idnsSOAmName: ns.foo.local. idnsSOArName: root.foo.local. idnsSOAserial: 2009083001 idnsSOArefresh: 10800 idnsSOAretry: 900 idnsSOAexpire: 604800 idnsSOAminimum: 86400 ...and start named daemon. Named will cannot load any idnsZone entry from LDAP. If I try to search zone entry mannualy, result is the same (empty). If I used following filter "(&(objectClass=idnsZone)(idnsZoneActive=TRUE))" i got all my active defined DNS zones. Complete part of openldap log file: Aug 29 21:42:35 ares slapd[6632]: conn=23 fd=35 ACCEPT from IP=172.x.x.32:48925 (IP=0.0.0.0:389) Aug 29 21:42:35 ares slapd[6632]: conn=23 op=0 BIND dn="cn=bind,ou=DSA,dc=foo,dc=local" method=128 Aug 29 21:42:35 ares slapd[6632]: conn=23 op=0 BIND dn="cn=bind,ou=DSA,dc=foo,dc=local" mech=SIMPLE ssf=0 Aug 29 21:42:35 ares slapd[6632]: conn=23 op=0 RESULT tag=97 err=0 text= Aug 29 21:42:35 ares slapd[6632]: conn=23 op=1 SRCH base="ou=Dynamic,ou=DNS,ou=Sluzby,dc=foo,dc=local" scope=2 deref=0 filter="(&(objectClass=idnsZone)(?idnsZoneActive=True))" Aug 29 21:42:35 ares slapd[6632]: conn=23 op=1 SRCH attr=idnsName idnsUpdatePolicy Aug 29 21:42:35 ares slapd[6632]: conn=23 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: The example ldif file /usr/share/doc/bind-dyndb-ldap-0.1.0/example.ldif has also defined wrong values "True" in idnsZoneActive.
bind-dyndb-ldap-0.1.0-0.3.a1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/bind-dyndb-ldap-0.1.0-0.3.a1.fc11
Hi, thanks for the report. Can you please test the rpms from the link above and let me know if this fixes the issue for you? The problem was that I always tested the ldap plugin with fedora directory server which (in that version) didn't do syntax checking, which is why I didn't catch this before. I'm not sure how the '?' got into the search filter, I'm assuming that this was just how openldap logged it.
Thanks for prompt reaction. I have installed latest build and after restarting named daemon all my DNS zones were loaded (with correct filter). And I can also resolve any DNS record from LDAP storage. I guess, that the "?" character before attribute name is due to resolved syntax problem by openldap server. Thanks, bug is solved for me.
bind-dyndb-ldap-0.1.0-0.3.a1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.