DNS discovery for OpenLDAP

Just as with Kerberos client administration, when faced with a sigificant number of LDAP clients, one possible way to streamline administration is to maintain a predetermined set of DNS hostname aliases (CNAME records) to refer to the OpenLDAP database servers on a network. However, the flexibility of this approach is limited for the same reason it is when doing this with Kerberos, so it is fortunate that OpenLDAP also supports DNS discovery.

Like Kerberos, OpenLDAP supports DNS discovery through use of the SRV resource record. For instance, if two LDAP servers are available on the network, klas1 and klas2, to allow them to be discovered by certain LDAP utilities through DNS, just add a couple of entries to the zone file for example.com, such as these in BIND9 format:

_ldap._tcp.example.com.	IN	SRV	10 0 389 klas1.example.com.
_ldap._tcp.example.com.	IN	SRV	20 0 389 klas2.example.com.

This type of record is composed as follows:

1. A name that starts with an underscore followed by the name of the service. See /etc/services for a list of protocol names.
2. An underscore followed by the name of the protocol, in this case only TCP is used.
3. The DNS name that matches the LDAP domain component (without a prepended underscore) followed by a trailing dot.
4. The IN (Internet) data class indicator.
5. The SRV (service) resource record type indicator.
6. A priority value within a range of 0-65535; lower values have higher priorities.
7. A weight value within a range of 0-65535. Used for simple load-balancing among identical services with equal priority values. Employs a probabilistic algorithm to give preference to hosts with higher weight values. A value of 0 disables it.
8. The TCP port number on which the service listens.
9. The target: FQDN (no aliases!) of the host that provides the service followed by a trailing dot.

Since omission of the trailing dots will cause BIND9 to complete the names in each entry with the zone's domain name, it is possible to achieve exactly the same results as above with the following:

_ldap._tcp		IN	SRV	10 0 389 klas1
_ldap._tcp		IN	SRV	20 0 389 klas2

Once the correct SRV entries have been implemented, check that they are available:

~$ host -t SRV _ldap._tcp
_ldap._tcp.example.com has SRV record 10 0 389 klas1.example.com.
_ldap._tcp.example.com has SRV record 20 0 389 klas2.example.com.
~$ _

When using DNS discovery in general, it is often said that not all utilities support it equally well. This is sooner apparent with OpenLDAP than with Kerberos or AFS, because once the URI option has been omitted from /etc/ldap/ldap.conf, /etc/libnss-ldap.conf and /etc/pam_ldap.conf, users may still be able to log in − which is the most important issue − but the standard LDAP utilities, that come with the ldap-utils package, all complain that no LDAP server can be contacted. They still expect to find one or more servers listed in /etc/ldap/ldap.conf.

Luckily, there is a workaround. All of the LDAP utilities accept a -H option followed by an LDAP URI to specify which LDAP server to use. It is possible to use this to test LDAP DNS discovery, for instance with the ldapsearch command, using a special URI:

~$ ldapsearch -H ldap:///dc%3Dexample%2Cdc%3Dcom uid=ccolumbus

The string used above for the LDAP URI is "dc=example,dc=com" with the comma and the equals signs escaped according to RFC-2396. Of course, it would be rather awkward to have to include this option every time one of the LDAP utilities was needed, so to avoid this just add the following lines to /etc/profile:

alias ldapadd='ldapadd -H ldap:///dc%3Dexample%2Cdc%3Dcom'
alias ldapcompare='ldapcompare -H ldap:///dc%3Dexample%2Cdc%3Dcom'
alias ldapdelete='ldapdelete -H ldap:///dc%3Dexample%2Cdc%3Dcom'
alias ldapmodify='ldapmodify -H ldap:///dc%3Dexample%2Cdc%3Dcom'
alias ldapmodrdn='ldapmodrdn -H ldap:///dc%3Dexample%2Cdc%3Dcom'
alias ldappasswd='ldappasswd -H ldap:///dc%3Dexample%2Cdc%3Dcom'
alias ldapsearch='ldapsearch -H ldap:///dc%3Dexample%2Cdc%3Dcom'
alias ldapwhoami='ldapwhoami -H ldap:///dc%3Dexample%2Cdc%3Dcom'

• OpenLDAP client on Debian squeeze
• OpenLDAP client on Debian lenny
• OpenLDAP client with MIT Kerberos V on Debian lenny
• Integrated Kerberos-OpenLDAP client on Debian lenny
• Integrated Kerberos-OpenLDAP-OpenAFS client
• DNS discovery for MIT Kerberos V
• DNS discovery for OpenAFS

• Berners-Lee T, Fielding R, Irvine UC, Masinter L. 1998. RFC2396 − Uniform Resource Identifiers (URI): Generic Syntax. HTML at the Internet FAQ Archives.
• Eastlake D, Panitz A. 1999. RFC2606 − Reserved Top Level DNS Names. The Internet Society. HTML at the Internet FAQ Archives.
• Gulbrandsen A, Vixie P, Esibov L. 2000. RFC2782 − A DNS RR for specifying the location of services (DNS SRV). The Internet Society. HTML at the Internet FAQ Archives.

• Aitchison R. 2005. Pro DNS and Bind. Apress. ISBN 1-59059-494-0. 571 pp. See pages 464-465.
• Liu C, Albitz P. 2006. DNS and BIND. Fifth Edition. O'Reilly & Associates, Inc. ISBN-13 978-0-596-10057-5. 616 pp.
• OpenLDAP Project. 2009. OpenLDAP Software 2.4 Administrator's Guide. HTML at OpenLDAP.