Bug 520256 - Wrong search filter in bind-dyndb-ldap
Summary: Wrong search filter in bind-dyndb-ldap
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: bind-dyndb-ldap
Version: 11
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Martin Nagy
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-29 20:20 UTC by Michal Bruncko
Modified: 2016-07-26 23:47 UTC (History)
3 users (show)

Fixed In Version: 0.1.0-0.3.a1.fc11
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-08-31 23:37:20 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michal Bruncko 2009-08-29 20:20:59 UTC
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.

Comment 1 Fedora Update System 2009-08-31 09:19:09 UTC
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

Comment 2 Martin Nagy 2009-08-31 09:25:52 UTC
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.

Comment 3 Michal Bruncko 2009-08-31 10:19:48 UTC
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.

Comment 4 Fedora Update System 2009-08-31 23:37:15 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.