mirror of https://github.com/tLDP/LDP
52 lines
5.3 KiB
Plaintext
52 lines
5.3 KiB
Plaintext
<SECT1 ID="DNS"><TITLE>DNS</TITLE>
|
|
<PARA>There are to "forms" of dns that can be configured via ldap. The first is using the nss_ldap (again) also for the dns.
|
|
This means that only clients that modify their <FILENAME>/etc/nsswitch.conf</FILENAME> 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.</PARA>
|
|
<SECT2><TITLE>Using nss</TITLE>
|
|
<PARA>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 <COMMAND>nslookup</COMMAND> command bypasses both <FILENAME>/etc/hosts</FILENAME> and ldap, so it cannot be used to check if your setup is working. Use something like <COMMAND>ping</COMMAND> instead, which does a lookup with the internel gehostbyname() function.</PARA>
|
|
<SECT3><TITLE>Configuration</TITLE>
|
|
<PARA>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 <XREF LINKEND="pamnss">. Here i will assume you have a working nss_ldap configuration.
|
|
The dns lookups of nss are controlled with the <EMPHASIS>hosts</EMPHASIS> line in <FILENAME>/etc/nsswitch.conf</FILENAME>.
|
|
It is very unlikely that you do not already have a hosts line. Most probably it will contain the <EMPHASIS>files</EMPHASIS> and <EMPHASIS>dns</EMPHASIS> entries. You should add <EMPHASIS>ldap</EMPHASIS> to it like this:</PARA>
|
|
<PARA><PROGRAMLISTING FORMAT="LINESPECIFIC">
|
|
hosts: files, dns, ldap
|
|
</PROGRAMLISTING></PARA>
|
|
<PARA>Think well about the order in which you specify these! It is advised always to put <EMPHASIS>files</EMPHASIS> 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 <FILENAME>/etc/hosts</FILENAME> 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, whose 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 <FILENAME>/etc/ldap.conf</FILENAME>, that is.)</PARA>
|
|
</SECT3>
|
|
<SECT3><TITLE>Schema</TITLE>
|
|
<PARA>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 <EMPHASIS>ipHost</EMPHASIS>. The name part of the mapping is given in the attribute <EMPHASIS>cn</EMPHASIS>, while the ip part lives in <EMPHASIS>ipHostNumber</EMPHASIS>.
|
|
A typical ldif entry would therefore look like this:</PARA>
|
|
<PARA><PROGRAMLISTING FORMAT="LINESPECIFIC">
|
|
dn: cn=somehostname.mydomain.com,ou=Network,o=YourOrg,c=NL
|
|
objectclass: top
|
|
objectclass: ipHost
|
|
cn: somehostname.mydomain.com
|
|
ipHostNumber: 10.1.5.13
|
|
</PROGRAMLISTING></PARA>
|
|
<PARA>Of course, the usual restrictions and possibilities that come with dns apply.</PARA>
|
|
</SECT3>
|
|
</SECT2>
|
|
<SECT2><TITLE>Using bind</TITLE>
|
|
<PARA>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.</PARA>
|
|
<SECT3><TITLE>Bind patch</TITLE>
|
|
<PARA>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 <ULINK URL="ftp://ftp.eyeo.com/bind/">sources</ULINK>.</PARA>
|
|
</SECT3>
|
|
<SECT3><TITLE>ldap2dns</TITLE>
|
|
<PARA>Taken intirely from their website:</PARA>
|
|
<PARA>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 <FILENAME>data.cdb</FILENAME> files used by tinydns, but also may be used to write <FILENAME>.db</FILENAME>-files used by named.</PARA>
|
|
<PARA>The projects homepage is <ULINK URL="http://ldap2dns.tiscover.com/">here</ULINK>.</PARA>
|
|
</SECT3>
|
|
<SECT3><TITLE>ispman</TITLE>
|
|
<PARA>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 <ULINK URL="http://www.ispman.org">ispman.org</ULINK>.</PARA>
|
|
</SECT3>
|
|
</SECT2>
|
|
</SECT1>
|