There are to ways of dns that can be configured via ldap, client side and server side. The first, client side, is using the name server switch to access the dns entries in the Ldap database. This means that only clients that modify their /etc/nsswitch.conf file will see the dns entries from ldap. The second way to do it is to use ldap as a backend for bind or tinydns. There are some projects going on about this subject and i will describe them below.
When using nss to access (additional) host entries, please take not that only "friendly" machines (e.g. machines that you know of and whoes configuration you can control) can use this service. It might be useful for intranet host lookups that change often, but it cannot be used to distribute your webservers virtual hostnames to the world. Note that also the nslookup command bypasses both /etc/hosts and ldap, so it cannot be used to check if your setup is working. Use something like host or ping instead, which does a lookup with the internel gehostbyname() function.
To have the name server switch use ldap for dns lookups it must be configured with nss_ldap. How to set up nss_ldap, you can find in Section 2. Here i will assume you have a working nss_ldap configuration. The dns lookups of nss are controlled with the hosts line in /etc/nsswitch.conf. It is very unlikely that you do not already have a hosts line. Most probably it will contain the files and dns entries. You should add ldap to it like this:
hosts: files, dns, ldap |
Think well about the order in which you specify these! It is advised always to put files as the first entry. Then, if you want ldap to override your local dns server, you have to make sure that the ip of the ldap server can be found in the /etc/hosts file. If not, you will have a nice recursive lookup going. -- You want to look up a host, it's not in files, so we try to contact the ldap server, whoes ip we don't know, so we try to look it up in files, where we cannot find it, so we try to contact the ldap server -- get the point? You could bypass this problem entirely by referring to your ldap server with an ip number instead of a hostname (in /etc/ldap.conf, that is.)
The schema used for this, and similar services, can be found in RFC 2307. Entries used for mapping names to ipnumbers are in an objectclass ipHost. The name part of the mapping is given in the attribute cn, while the ip part lives in ipHostNumber. A typical ldif entry would therefore look like this:
dn: cn=somehostname.mydomain.com,ou=Network,o=YourOrg,c=NL objectclass: top objectclass: ipHost cn: somehostname.internal.example.com ipHostNumber: 10.1.5.13 |
Of course, the usual restrictions and possibilities that come with dns apply.
There are a few possibilities with bind or tinydns nowadays, but imho none of them is a "real" solution (yet). I must say, however, that i have no experience with any of them. They are listed below.
David Storey is working on a patch for Bind, which makes it get its data directly from ldap. This means that every time a request is performed on the bind daemon, it does a lookup in ldap. At this time, his future plans were: (Taken from the source) to have at least two modes of operation: cached and dynamic. Cached mode operates just like an rbtdb by loading the entire zone into memory and reloading whenever the server is HUP'ed. Dynamic mode is much like it is now: every request means an LDAP lookup. For up to date information you should check out the sources.
Taken entirely from their website:
ldap2dns is a program to create DNS records directly from a LDAP directory. It can and should be be used to replace the secondary name-server by a second primary one. ldap2dns helps to reduce all kind of administration overhead. No more flat file editing, no more zone file editing. After having installed ldap2dns, the administrator only has to access the LDAP directory. If he desires he can add access control for each zone, create a webbased GUI and add all other kind of zone and resource record information without interfering with the DNS server. ldap2dns is designed to write binary data.cdb files used by tinydns, but also may be used to write .db-files used by named.
The projects homepage is here.
ispman is a perl-based isp management package. It uses an ldap database backend for it's configuration. It can do lot's of things, so you might check out what you need exactly. It's at ispman.org.
|
Space for these documents provided by
Ben Spade
in support of the Linux community.
Change happens - click for HOWTO index |