LDAP 経由で設定できる DNS には、ふたつの「形式」があります。 最初のものは、(またもや) nss_ldap を、DNS の代わりに使うというものです。 これはつまり、/etc/nsswitch.conf ファイルに 手を加えたクライアントだけが LDAP から DNS エントリを見られるようになる ということです。 ふたつめの方法は LDAP を bind や tinydns のバックエンドとして 使用することです。これに関連して活動している プロジェクトは幾つかあります。それはのちほど説明することにします。
NSS を (付加的な) ホストエントリへのアクセスに 使っているときには、「親密」なマシン (つまり、 自分が知っていて、その設定を制御することもできるマシン) だけが このサービスを使えるのだということに注意してください。 これはイントラネットでの、ころころ変わるホスト名解決には 有用かもしれませんが、自分のウェブサーバのバーチャルホスト名を 全世界に公開するには使えません。 また nslookup は /etc/hosts も LDAP も経由しないため、 設定がうまくいっているかどうかの確認には使えない ということも覚えておいてください。かわりに、ping のように内部で gethostbyname() 関数を使って名前解決しているものを 使うようにしてください。
Name Service Switch に LDAP で名前解決させるには、 nss_ldap を使うよう設定しなくてはなりません。 nss_ldap の設定方法は Section 2 に書いてあります。 ここでは正常に動いている nss_ldap の設定があるものとして話を続けます。 NSS による名前解決は /etc/nsswitch.conf 内の hosts 行の内容で制御されます。 まだ hosts 行がないということは、まずありません。 たぶん files と dns がエントリとして書かれていることでしょう。そこに ldap を、次のように追加するのです。
hosts: files, dns, ldap |
順番をよく考えて指定してください！ どのような場合でも 最初に files を置くよう忠告しておきます。 それから、LDAP をローカル DNS サーバよりも優先させたい ならば、LDAP サーバの IP が確実に /etc/hosts ファイルの中にあるようにしてください。 そうしないと、困った再帰解決が生じてしまいます。つまりこういうことです。 「あるホスト名を解決したいけれど、ファイル内にはエントリがないので、 LDAP サーバに問い合わせようとする。しかしサーバの IP を知らないのでファイル内を探してみるが、そこにはないので LDAP サーバに 聞こうとする……」 要点がつかめましたね？ この問題は、ホスト名のかわりに IP 番号で LDAP サーバを参照する (つまり /etc/ldap.conf の中に書いておく) ことによって、完全に回避することができます。
このサービスや同様のサービスに使われるスキーマが RFC 2307 に定義されています。IP 番号にホスト名を割り当てるためのエントリは ipHost という objectclass に入ります。 割り当てのホスト名の部分は cn 属性の中に入れられ、 IP 部分の方は ipHostNumber に入ります。 ですから、典型的な LDIF のエントリはこのようになります。
dn: cn=somehostname.mydomain.com,ou=Network,o=YourOrg,c=NL objectclass: top objectclass: ipHost cn: somehostname.mydomain.com ipHostNumber: 10.1.5.13 |
もちろん、ふつう DNS に付随する制限や機能は このサービスにも当てはまります。
今日では bind や tinydns にも多少の可能性 はありますが、これらのいずれも、著者の意見では (今のところ) 「ほんとうの」解決策ではありません。しかしながら、著者が それらを使った経験がないということも言っておかなくてはなりません。 それらを以下に列挙します。
David Storey が bind へのパッチの作業をしています。 このパッチは、データを直接 LDAP から取得するようにするものです。 それは bind デーモン上に要求がなされるたびに LDAP で 解決することを意味します。現時点での彼の計画 (ソースから引用) は、 「少なくともふたつのモード ― キャッシュモードとダイナミックモード ― で 動くようにすること」です。 キャッシュモードでは、ちょうど rbtdb のように、ゾーンをまるごと メモリにロードして動作し、サーバが HUP シグナルを受けるとロードしなおします。 ダイナミックモードでは現状とよく似ていて、すべての要求が LDAP への参照となります。最新情報は ソース を確認してください。
ウェブサイトからまるごと引用します。
「ldap2dns は DNS レコードを直接 LDAP ディレクトリから作成する プログラムです。これは、セカンダリネームサーバを第二のプライマリサーバで 置換するために使うことができますし、そのために使うべきです。 ldap2dns はあらゆる煩わしい管理作業を軽減する助けになります。 もう単調なファイル編集は必要ありません。ゾーンファイル編集も必要ありません。 ldap2dns をインストールしてしまえば、管理者はただ LDAP ディレクトリに アクセスするだけでよいのです。望むなら、管理者はゾーンごとにアクセス コントロールをかけることができます。ウェブベースの GUI を作成して、DNS に干渉することなく、あらゆる種類のゾーンやリソースレコードの情報を 追加することもできます。 ldap2dns は tinydns に使用される data.cdb という バイナリファイルを書き出すよう設計されていますが、named に使用される .db ファイルを書き出すようにすることもできます。」
このプロジェクトのホームページは ここ です。
ispman は Perl で書かれた ISP 管理パッケージです。 これは LDAP データベースを設定のバックエンドに使います。 このパッケージは非常に多くのことができるので、正確に自分の 必要としているものを確認した方がよいかもしれません。 アドレスは ispman.org です。