# DLZ bind/named & ldap.conf



## Leander (Nov 1, 2017)

Hi,

it turns out, named is not recognising /etc/ldap.conf, /usr/local/etc/ldap.conf or /usr/local/etc/openldap/ldap.conf. Am I missing something? It's not running as chroot:


```
cat /etc/rc.conf
[...]
named_enable="YES"
named_conf="/usr/local/etc/namedb/named.conf"
[...]
```

on LDAP side it clearly states that it is not doing a starttls:


```
Nov  1 21:15:31 FreeBSD slapd[30750]: conn=1058 op=0 BIND dn="cn=admin,dc=DOMAIN,dc=TLD" method=128
Nov  1 21:15:31 FreeBSD slapd[30750]: conn=1058 op=0 RESULT tag=97 err=13 text=confidentiality required
```


```
root@Prod-DNS-1 [~]$ ls -lach {/usr/local/etc/openldap/ldap.conf,/usr/local/etc/ldap.conf,/etc/ldap.conf}
lrwxr-xr-x  1 root  wheel    33B Nov  1 21:01 /etc/ldap.conf -> /usr/local/etc/openldap/ldap.conf
lrwxr-xr-x  1 root  wheel    33B Nov  1 20:12 /usr/local/etc/ldap.conf -> /usr/local/etc/openldap/ldap.conf
-rwxrwxr-x  1 root  wheel   921B Nov  1 21:29 /usr/local/etc/openldap/ldap.conf
```

All other TLS/SSL connections to LDAP work fine. My ldap.conf is definitely fine. I just don't know where named is looking for it?! With sshd I needed to do something like this, to get ssh pub keys working from LDAP:


```
LDAPCONF='/usr/local/etc/openldap/ldap.conf'
export LDAPCONF
export PATH=${PATH}:/usr/local/bin
```

But where would I place this?


----------



## SirDice (Nov 2, 2017)

I haven't looked very closely on how to configure BIND for this but it looks like it uses its own settings from named.conf and doesn't use ldap.conf at all.


----------



## Datapanic (Nov 2, 2017)

/usr/local/etc/ldap.conf and /usr/local/etc/openldap/ldap.conf are two totally different files but you have the former linked to the later...

/usr/local/etc/ldap.conf is the configuration file for the LDAP nameservice switch library and the LDAP PAM module. 

/usr/local/etc/openldap/ldap.conf is used to set system-wide defaults to be applied when running ldap clients.


----------



## Leander (Nov 2, 2017)

SirDice said:


> I haven't looked very closely on how to configure BIND for this but it looks like it uses its own settings from named.conf and doesn't use ldap.conf at all.


Thus far it looks like the only thing I can change regarding this is to switch between "*ldap:///*" or "*ldaps:///*". Problem is, that I can not set any *CADIR*, *CACERT*, etc.


```
dlz "LDAP Zone Master" {
    database "ldap 1
    v3 simple {cn=admin,dc=domain,dc=tld} {maypassword} {ldap.domain.tld}
   ldap:///dlzZoneName=$zone$,ou=zone.master,ou=dns,ou=services,dc=domain,dc=tld???objectclass=dlzZone
   ldap:///dlzHostName=$record$,dlzZoneName=$zone$,ou=zone.master,ou=dns,ou=services,dc=domain,dc=tld?dlzTTL,dlzType,dlzPreference,dlzData,dlzIPAddr,dlzPrimaryNS,dlzAdminEmail,dlzSerial,dlzRefresh,dlzRetry,dlzExpire,dlzMinimum?sub?objectclass=dlzAbstractRecord
    {}
   ldap:///dlzZoneName=$zone$,ou=zone.master,ou=dns,ou=services,dc=domain,dc=tld?dlzTTL,dlzType,dlzHostName,dlzPreference,dlzData,dlzIPAddr,dlzPrimaryNS,dlzAdminEmail,dlzSerial,dlzRefresh,dlzRetry,dlzExpire,dlzMinimum?sub?objectclass=dlzAbstractRecord
   ldap:///dlzZoneName=$zone$,ou=zone.master,ou=dns,ou=services,dc=domain,dc=tld??sub?(&(objectclass=dlzXFR)(dlzIPAddr=$client$))";
};
```




Datapanic said:


> /usr/local/etc/ldap.conf and /usr/local/etc/openldap/ldap.conf are two totally different files but you have the former linked to the later...
> 
> /usr/local/etc/ldap.conf is the configuration file for the LDAP nameservice switch library and the LDAP PAM module.
> 
> /usr/local/etc/openldap/ldap.conf is used to set system-wide defaults to be applied when running ldap clients.



Thank you. I've linked them because the requirements for nslcd and system wide defaults are equal in my case. Nevertheless, bind dlz seems to completely ignore the defaults or simply doesn't look for the defaults where I would expect it to look for.




Helpful clues are very welcome


----------



## Leander (Nov 2, 2017)

Same issue: https://sourceforge.net/p/bind-dlz/mailman/message/25943411/
But unfortunately it doesn't seem to pick up on the openLDAP standards as expected.


----------

