On Tue, 2013-10-15 at 19:34 -0400, Brendan Kearney wrote:

i am trying to setup BIND to use LDAP as the zone data repository, using bind-dyndb-ldap and continue to run into issues. i am not sure what this error message means, but it seems to be part of the problem.

i see that the bind attempt succeeds and that a search is attempted. but, when the search is attempted, a critical piece of the puzzle is missing and an extension is not recognized. indexing will be done once i get the rest of this working...

2013-10-15T19:10:16.980653-04:00 test slapd[12675]: conn=1057 fd=11 ACCEPT from IP=127.0.0.1:57849 (IP=0.0.0.0:389) 2013-10-15T19:10:16.980675-04:00 test slapd[12675]: conn=1057 op=0 BIND dn="cn=Manager,dc=my-domain,dc=com" method=128 2013-10-15T19:10:16.980680-04:00 test slapd[12675]: conn=1057 op=0 BIND dn="cn=Manager,dc=my-domain,dc=com" mech=SIMPLE ssf=0 2013-10-15T19:10:16.980683-04:00 test slapd[12675]: conn=1057 op=0 RESULT tag=97 err=0 text= 2013-10-15T19:10:16.982325-04:00 test slapd[12675]: conn=1058 fd=17 ACCEPT from IP=127.0.0.1:57850 (IP=0.0.0.0:389) 2013-10-15T19:10:16.983442-04:00 test slapd[12675]: conn=1058 op=0 BIND dn="cn=Manager,dc=my-domain,dc=com" method=128 2013-10-15T19:10:16.983456-04:00 test slapd[12675]: conn=1058 op=0 BIND dn="cn=Manager,dc=my-domain,dc=com" mech=SIMPLE ssf=0 2013-10-15T19:10:16.983459-04:00 test slapd[12675]: conn=1058 op=0 RESULT tag=97 err=0 text= 2013-10-15T19:10:16.990216-04:00 test slapd[12675]: conn=1057 op=1 SEARCH RESULT tag=101 err=12 nentries=0 text=critical extension is not recognized 2013-10-15T19:10:16.990883-04:00 test slapd[12675]: conn=1057 op=1 do_search: get_ctrls failed 2013-10-15T19:10:16.991177-04:00 test slapd[12675]: conn=1058 op=1 SRCH base="cn=dns,dc=my-domain,dc=com" scope=2 deref=0 filter="(&(idnsZoneActive=TRUE)(|(objectClass=idnsZone)(objectClass=idnsForwardZone)))" 2013-10-15T19:10:16.991468-04:00 test slapd[12675]: conn=1058 op=1 SRCH attr=idnsName idnsUpdatePolicy idnsAllowQuery idnsAllowTransfer idnsForwardPolicy idnsForwarders idnsAllowDynUpdate idnsAllowSyncPTR objectClass 2013-10-15T19:10:16.991740-04:00 test slapd[12675]: <= bdb_equality_candidates: (idnsZoneActive) not indexed 2013-10-15T19:10:16.992025-04:00 test slapd[12675]: conn=1058 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=

i know that the schema for dyn-dns is loaded and all the objectClasses and attributeTypes are available. the problem i run into is an A Record that should be in the zone data cannot be queried out of the BIND instance that is talking to LDAP.

[root@test conf.d]# nslookup foo.my-domain.com. localhost ;; Got SERVFAIL reply from 127.0.0.1, trying next server ;; Got SERVFAIL reply from 127.0.0.1, trying next server Server: localhost Address: 127.0.0.1#53

** server can't find foo.my-domain.com: SERVFAIL

i am using:

bind - 9.9.3 bind-dyndb-ldap - 3.5 openldap 2.4.36

on Fedora 19 (yes, it is the distro packaged version). Can anyone give me some pointers on how to get this working?

i have been pounding away at this and i finally have this working. first and foremost, i had to disable persistentSearch because it is on by default. the missing extension is the psearch control found in 389 or other LDAP servers.

once i disabled psearch (in both /etc/named.conf and as an attribute set in LDAP for the cn=dns,dc=my-domain,dc=com object), i had to get the zones in order. there was no valid NS record in the example zone, and no reverse zone with a PTR for the invalid NS record. in all, it was a bunch of persistence in getting it working.

the forthcoming move to rfc 4533 operations for syncing with soon replace persistentSearch and deprecate the zone_refresh (or idnsZoneRefresh) fucntionality. from some quick searching, it seems rfc 4533 is or will be supported in OpenLDAP, so there should not be any issues when that change occurs.

as of now i am able to house my DNS zone data in LDAP, and can query it with standard nslookup or dig commands. woohoo!!!