Re: bind-dyndb-ldap

[Brendan Kearney <bpk678@gmail.com>]

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!!!