$B0J2<$N%F%-%9%H$O!"<9I.;~Ev;~$N>pJs$r85$K=q$$$?$b$N$G$"$j!"(B
$B8=:_$N>p@*$K$=$0$o$J$$$3$H$r4^$`>l9g$,$"$k$N$GCm0U$5$l$?$$!#(B
$B$^$?!"%F%-%9%H$O:G=*Ds=P869F$G9;@5$r7P$kA0$N$b$N$J$N$G!" $BCWL?E*$J8m$j0J30$O2CI.=$@5Ey$O9T$J$o$J$$$N$G>pJs$NA/EY$K5$$r$D$1$D$D(B
$BMxMQ$7$FM_$7$$!#(B $B"*(B$BL\
djbdnsを使ったDNS管理
一般ユーザの立場からするとネームサーバは、ネットワーク管理者、あるいはプ
ロバイダが設定したものを利用するという対象であって、自分が独自に立てるも
のという印象は薄いかもしれない。本稿ではdjbdnsを使って自己利用用のキャッ
シュ専用ネームサーバを設置してその効果を体験することから始め、権利委譲さ
れたドメインのプライマリサーバを運用するために必要な知識までを説明したい。
■DNSのもうひとつの実装djbdns
BINDによるネームサーバの構築には起動設定ファイルとゾーンファイルの記述が
必要である。Part?? の解説で見たようにこれらのファイルは比較的見ためにも
分かりやすく、プログラミング言語のようである。慣れてしまえば問題ないのだ
が、最初に見たときは設定すべき項目が多く難しいと感じたのではないだろうか。
また、既に見本があれば良いのだが、ゼロから書くのはなかなか難しく尻込みし
た読者も少なくないのではなかろうか。
djbdnsは qmail の作者であるD. J. Bernstein 氏による全く新しいDNSの実装で、
qmail と同様に高セキュリティ性を持ち、非常に簡単に導入することができる。
●djbdnsの特徴
ネームサーバには大きく分けて二つの働きがある。ひとつはクライアントからの
依頼を受けて別ドメインの名前情報を引き、クライアントに返答するというもの。
もうひとつは自己ドメインに属するホストの名前情報を供給するというもの。
BINDの場合はいずれの機能も同一プログラム(named)で行なっているのだが、
djbdnsでは各機能ごとに独立したプログラムが用意されている。前者の機能に相
当するプログラムはdnscache、後者の機能に相当するプログラムはtinydnsとな
る。dnscacheは、名前の問い合わせを許可するクライアントの違いによってさらに
二つに分類される。
ひとつは「ローカルキャッシュ」で、これは図1のようにひとつのホストが名前
解決を行なうときに外部のネームサーバに問い合わせた結果を保持しておいて、
次回同じ問い合わせが来たときにそれを利用して効率化をはかるものである。こ
れは、一台のマシンだけが単体でDNSの問い合わせを必要とする場合に利用する。
ローカルキャッシュが最も有効に機能する例のひとつとしては、
携帯可能なUNIX-PCを利用して
いる場合が挙げられる。出先で、メイルやWebを利用するときに、遅いダイヤル
アップ回線の先のネームサーバを参照せずに、ローカルにキャッシュしてあるデー
タを参照するとかなり快適になる。
もうひとつは「外部キャッシュ」で、図2のようにキャッシュしてある名前を別
のマシンでも参照できるものである。
図1 ローカルキャッシュ----------------------+
| Computer
| +-----------+
| | |
| | | (www.hoge.co.jp という
| | | 名前の問い合わせが
| +-+-------+-+ 自己ループしている絵)
| |↑ ↓ |
| /~~~↑~~↓~~~~\
| www.hoge.co.jp
+-------------------------------------------+
図2 外部キャッシュ--------------------------+
| キャッシュサーバ
| +-----------+
| | |
| | | (名前の問い合わせを
| | | 別ホストにさせている絵)
| +-+-------+-+ +---+ +---+ +---+ +---+
| | | | | | | | | | |
| /~~~~~~~~~~~~~\ +---+ +---+ +---+ +---+
| [...] [...] [...] [...]
+-------------------------------------------+
この設定では、同一LANのコンピュータの、名前解決用ネームサーバとして利用
することができる。もちろんクライアント機はUNIXでなくても構わないし、参照
許可さえ出せば同一LANのものでなくても構わない。多くのオフィスでは自前の
ドメインを持つわけではなく、ネームサーバを単に外部ホストの名前解決のため
だけに利用していることから、「外部キャッシュ」となるサーバを用意すれば事
足りることが予想される。
いっぽう、tinydnsでは自前のドメインの名前情報を供給するネームサーバをき
わめて簡単に構築することができる。BIND利用経験者にとってひとつだけ注意が
必要なのは、外部ドメインの名前解決機能はtinydnsにはなく、完全にdnscache
に任されているという点である。
●djbdnsの導入
djbdnsはDNSに関する機能ごとに細分化されたいくつかのプログラムで構成され
ている。これらのプログラムは "daemontools" という、デーモンプロセスの起
動・監視・停止などを統合的に行なうツールを経由して起動することを想定して
設計されている。daemontoolsを使わなくともdjbdnsを利用することは可能だが、
その場合動作ログを効率的に採取するという事柄一つをとっても、それに適した
プログラムを効果的に組み合わせて使うためにUNIXに関する深い知識を求められる
ので、素直にdaemontoolsのお世話になってしまう方が賢明である。
・daemontoolsとは
UNIXではいろいろなデーモンプロセスが走っている。それらを統合的に、全く同
じインタフェースで管理するためのツールがdaemontoolsである。たとえば次の
ような経験はないだろうか。
「sshdの設定変えるかな。よし、sshd_config書き換えたからHUP送るか。
えーとPIDは何番だ? あれ、/var/run/sshd.pid がさっき試しに違う
ポート番号で起動した sshd のPIDで上書きされちゃったよ。元々走っ
てるのは何番だ? それ、ps だ。あれ、psのオプションが違う。なんだっ
け? えーと、man ps …うわ、たくさんあるなあ…(1分経過)…そうか、
ps -le くらいでいいのか。あ、1234番だ。それ kill -HUP 1234 と。
ちゃんとログに出てるかな。あれ、出てない。そういえばsshd_config
にSyslogFacilityとかってあったな。Facilityって何? man syslog。うー
ん、違った。man syslog.conf。これか。難しいな。えーと…(5分経
過)…そうか。sshd_config書き換えてもう一度 kill -HUP 1234 と。は
あ、疲れた。」
この例文ではsshdの設定しか触れていないが、実際には多種多様のデーモンを多
種多様のOS上で管理する必要があり、より大きな手間がかかることになる。これ
らの繁雑さを解決してくれるのが daemontools であると考えると分かりやすい。
daemontoolsでは、全てのデーモンプログラムは決められた構造をもつ一つのディ
レクトリで管理することを約束としている。具体的には、あるデーモンをフォア
グラウンドで走らせるコマンド行を書いたスクリプトを run というファイル名
で持つディレクトリを作っておくのが最低限の約束である。このように作成した
デーモン管理用のディレクトリを D とすると、daemontools付属のsvscanプログ
ラムに D ディレクトリを認識させることでそのサービスデーモンが起動する。
daemontoolsによるデーモンプログラムの管理の流れの要点をまとめると以下の
ようになる。
1. daemontoolsのインストール
これは次節で解説する。
2. デーモン管理ディレクトリ D の作成
"run" というファイル名でデーモンを起動するシェルスクリプトを
作成する。今回紹介するdjbdnsではデーモン管理用のディレクトリ
は自動的に生成してくれるのでそれに任せてしまえばよい。
3. svscanプログラムの起動
svscanは、ある特定のディレクトリの中に存在するディレクトリを
常に監視していて、起動すべきサービスデーモンを自動的に探して
即座に起動してくれる。慣習的に /service ディレクトリを監視用
のディレクトリとして利用する。
4. 管理用ディレクトリ D の /service への配置
実際にはディレクトリ D の実体を/service に置く必要はなく、容
量に余裕のある別のパーティションに置いて、そこへのシンボリッ
クリンクを /service/ に作成するという形で管理することになろ
う。たとえば、/var/djbdns を管理用ディレクトリとしたなら
# ln -s /var/djbdns /service
とするだけでsvscanが(5秒以内に)自動的にこれを検出し、ただちに
起動する。
1〜4の手順を踏んで正常に動作することが分かったら、3のsvscanの起動をシス
テムのスタートアップファイルに記述すれば、以後はシステム起動後、自動的に
各種サービスが起動することになる。それでは各ステップの具体的説明に移ろう。
・daemontoolsの導入
今月号付録CD-ROMにあるdaemontools-0.70.tar.gzがソースアーカイブである。
これを利用してのインストールを解説しよう。まずアーカイブを展開し、README
ファイルを読もう。
# tar vzxpf daemontools-0.70.tar.gz
# cd daemontools-0.70
# less README
ドキュメントにあるように http://cr.yp.to/daemontools.html に確実な解説が
あるのでそれも参考にしながら以下の作業に移る。
ソースディレクトリにある conf-home というファイルにdaemontoolsをインストー
ルするディレクトリのprefixが書かれている。デフォルトでは /usr/local となっ
ているが、別の場所にインストールしたいときはこれを書き換えればよい。イン
ストール場所を確認したらすぐにmakeに移る。
# make
そしてインストールする。
# make setup check
これで完了である。念のためコンパイルされたコマンドが正常に動作しているか
の確認をしよう。
# ./rts > rts.out
# cmp rts.out rts.exp
とコマンド起動してみて何も出力されなければ正常である。また、
# date | ./tai64n | ./tai64nlocal
# date | sh -c './multilog t e 2>&1' | ./tai64nlocal
と起動してみて
2000-11-04 13:47:11.523517500 Sat Nov 4 13:47:11 JST 2000
2000-11-04 13:47:12.428708500 Sat Nov 4 13:47:12 JST 2000
のように各行の左側に現れる時刻と、右側に現れる時刻が同じになっていれば正
常である。
インストールに問題がなければ早速必要なサービスデーモンの監視をさせよう。
監視するディレクトリはとくに問題がなければ /service とする。ルートパーティ
ションに作成することになるが、一般的な利用方法ではこのディレクトリにはシ
ンボリックリンクを作成するだけなのでディスク容量のことなどは心配する必要
はないだろう。また、/ に置くことで上げているサービスが分かりやすくなるこ
とと、後述する svc, svstat でサービスを指定するときにディレクトリで指定
するのでなるべく素早くタイプできる利点などを考慮しても /service に配置す
るのが妥当と思われる。
# mkdir /service
# chmod 755 /service
svscanプログラムにこのディレクトリ名を渡して監視してもらう。今後の利用を
考えて次のようなシェルスクリプト(start-sv.sh)を作成しておくとよいだろう。
[start-sv.sh]
#!/bin/sh
env - \
PATH=/usr/local/bin:/usr/sbin:/usr/bin:/bin csh -cf 'svscan /service &'
ここで、/usr/local/bin はdaemontoolsの各実行プログラムがインストールされ
たディレクトリを意味する。conf-home ファイルを書き換えた場合はPATHの値も
それに応じて書き換える。そして、このスクリプトを実行する。
# ./start-sv.sh
これでdjbdnsの導入に必要な設定は終了である。次回起動時にも自動的に有効に
したい場合は Linux系、SytemV 系の場合は /etc/rc?.d/ に、BSDの場合は
/etc/rc.local や /usr/local/etc/rc.d にstart-sv.shを起動する定義を入れて
おけばよいだろう。
=== コラム ===================================================================
daemontools の管理コマンド
~~~~~~~~~~~~~~~~~~~~~~~~~~
daemontoolsに付属するコマンド群の働きについて簡単に紹介しよう。以後の説
明で用いている「サービス」の指定は、サービスデーモン foo を管理している
/service/foo ディレクトリで表すものとする。たとえば、qmailのデーモンを
/service/qmail ディレクトリで監視させている場合、以下のコマンドの「サー
ビス」の部分は "/service/qmail" となる。
-------------------
【supervise】
起動時に与えられたディレクトリで定義されるサービスデーモンプログラムの起
動と監視を行なう。デーモンプログラム開始用スクリプト ./run をまず起動し、
その後常にそのスクリプトから起動されたデーモンプロセスを監視して、もし途
中で終了してしまうようなことがあったら、少しの間隔(約1〜5秒)を置いて再起
動する。superviseプログラムを直接起動してもよいが、通常は以下で説明す
るメタデーモン svscan に自動的に起動させる。
【svc】
superviseプログラムによって監視されているデーモンを制御する。
# svc オプション サービス
の形式で起動して管理ディレクトリで指定されるデーモンプロセスにシグナルな
どを送ったりすることができる。オプションは以下の通りである。
-u デーモンを上げる。
-d デーモンを落とす。再起動しない。
-o デーモンを上げる。ただしデーモンが止まっても再起動しない。
-p デーモンに STOP シグナルを送る(Pause)。
-c デーモンに CONT シグナルを送る。
-h デーモンに HUP シグナルを送る。
-a デーモンに ALRM シグナルを送る。
-i デーモンに INT シグナルを送る。
-t デーモンに TERM シグナルを送る。
-k デーモンに KILL シグナルを送る。
-x supervise がただちに終了するよう指示する。何かトラブルが起きたとき
以外はこのオプションは利用しないはずである。
【svok】
# svok サービス
の形式で利用して、ディレクトリに対応するサービスデーモン(を監視している
superviseプロセス)が起動しているかどうか確認する。起動していれば終了コー
ド0を、していなければ100を返す。
【svstat】
svokと同様の形式で起動して、サービスデーモンの起動に関する統計情報を出力
する。
【svscan】
superviseのさらに上位に位置するデーモンとして、複数のデーモンの起動状態
を監視し、常に上がっているようにコントロールする。慣習的に /service を利
用する。svscan起動時には環境変数PATHにdaemontoolsのコマンド群のあるディ
レクトリを含める必要がある。
【fghack】
通常 supervise が起動する ./run スクリプトではデーモンプログラムをフォア
グラウンドで起動することが期待されている。自動的にバックグラウンド動作に
移行するデーモンプログラムをsuperviseで管理したいときは起動スクリプト
(run)のデーモン起動をfghack経由で行うようにするとうまくsuperviseで管理で
きるようになる場合もある。
【multilog】
標準入力をさまざまなログに出力する。
【tai64n】
入力の各行に対してその行を読んだときのタイムスタンプをTAI64N形式でつける。
【tai64nlocal】
TAI64N形式のタイムスタンプ文字列を可読形式に変換する。
【setuidgid】
指定したUID, GIDに setuid/setgid したうえで別のプロセスを起動する。
【envuidgid】
指定したアカウントのUIDとGIDを環境変数に設定して別のプロセスを起動する。
【envdir】
指定したディレクトリにあるファイル名と同じ環境変数の値を、そのファイルの
内容にセットしたうえで別のプロセスを起動する。
【softlimit】
指定したリソース制限をセットして別のプロセスを起動する。
【setlock】
指定したファイルをロックして別のプロセスを起動する。
-------------------
これらのコマンド群のうち svc, svstat, tail64nlocal を覚えておけば大抵の
管理作業はこなせる。システム起動時にsvscanを起動しておくことで自動的に各
種サービスが上げられるので普段は明示的に起動する必要はない。サービスに
HUPシグナルを送る場合は
# svc -h サービス
によって行える。サービスを停止したいときは
# svc -d サービス
で行えるが、リブート後を含め本当に完全に停止したいときはサービスの管理ディ
レクトリに down という名前のファイルを作成してからsvc -d する。
# touch /service/Service/down
# svc -d /service/Service
とすると supervise がこのサービスを上げずに待機するようになる。再度上げ
るときは down ファイルを消せばよい。
# rm /service/Service/down
# svc -u /service/Service
また、サービスを落とし復活する予定もない場合は以下のようにシンボリックリ
ンクを消去してサービスを抹消する。
# cd /service/Service
# rm /service/Service
# svc -dx . log
==============================================================================
・djbdnsのインストール
daemontoolsのインストールが完了し、svscanプログラムの起動が完全に成功し
たらdjbdnsのインストールに移る。djbdnsのインストールを説明するWebページ
でもsvscanが正常に起動している事を前提としているので注意する。djbdnsの本
稿執筆時の最新版は1.02であり、これも今月号付録CD-ROMに収録しているので利
用されたい。これもソースアーカイブを展開してドキュメントに目を通そう。
# tar vzxpf djbdns-1.02.tar.gz
# cd djbdns-1.02
# less README
これも http://cr.yp.to/djbdns.html に公式な解説があるのでこれを傍らに開
いておいて以下の作業を進めて欲しい。djbdnsのmakeもdaemontoolsと全く同様
である。デフォルトのインストールprefixは /usr/local となっているがこれを
変更するには conf-home ファイルの内容を書き換えるとよい。
# make
# make setup check
これでインストール完了である。以後の設定ではdjbdnsの各コマンドがインストー
ルされているディレクトリ (デフォルトでは/usr/local/bin) がPATHに入っている
ものと仮定する。
●ローカルキャッシュの設定
単一マシンで外部DNS参照を行なう際に有効なローカルキャッシュを作成してみ
よう。ローカルキャッシュサーバの起動にはサーバを動かすためのユーザと、ロ
グを取得するためのユーザが必要となる。まずはこれらのアカウントを作成する。
アカウント名は何でもよいが、公式ドキュメントの例に従いここでは前者のアカ
ウント名を dnscache, 後者のものを dnslog とする。また、各アカウントはど
んなグループでも構わないが、分かりやすくするため両者を `dns' というグルー
プに入れることにしておく。
# vi /etc/group
--------------------------------------------------
dns:*:9800: (追加)
--------------------------------------------------
# vipw
--------------------------------------------------
dnscache:*:9800:9800:0:0:/var/dns:/bin/noshell (追加)
dnslog:*:9801:9800:0:0:/var/dns:/bin/noshell (追加)
--------------------------------------------------
もちろんこれらのUID/GIDは既存のものと重複しなければ何番でも構わない。
ここで作成したサーバプログラム用アカウントとログ取得用アカウントを
dnscache-conf プログラムに与えてローカルキャッシュサーバの起動環境を作成
する。
# dnscache-conf dnscache dnslog /var/dnscache
最後の引数の /var/dnscache はキャッシュサーバの動作環境を保持するディレ
クトリで、ここにchrootして動作することになる。このディレクトリの下にはロ
グが出力されるので容量的にゆとりのあるパーティションに配置する(※か)。
----------
※註か
djbdnsのページの説明では /etc/dnscache のように、/etc に配置するようになっ
ている。/ パーティションに十分な空き容量があれば /etc でも構わない。本稿
では / に大容量を割り当てはいない環境が多いであろうと考えて /var を管理
ディレクトリとすることで説明を進める。
----------
さて、上記のコマンド起動により /var/dnscache に daemontools で監視するの
に適したファイル群が生成されるのでここを /service ディレクトリ内のシンボ
リックリンクとしてsvscanに検知させる。
# ln -s /var/dnscache /service
5秒以内にdnscacheが起動する。早速localhostをネームサーバとして動作試験を
行ってみよう。/etc/resolv.conf の nameserver の指定を書き換える。
--------------------------------------------------
nameserver 127.0.0.1
--------------------------------------------------
実際にWebブラウザなどを利用して任意のホスト名が引けるか確認してみる。
クライアントからの名前解決のリクエストがあると同時にキャッシュサーバの
/var/dnscache/log/main/current にログが書き込まれる。このログを観察する
ときは
# tail -f /var/dnscache/log/main/current | tai64nlocal
などのように、tai64nlocal に時刻を可読形式に変換すると読みやすい。ログ
の出力される場所と読み方は以後説明する各ツールに共通している。
log/main/current ファイルは最新のログが書き込まれ、適当なサイズ(デフォル
トでは99999バイト以内)で自動的にローテートされる。
●外部キャッシュの設定
自ホスト以外のマシンからも利用できる外部キャッシュもローカルキャッシュと
ほぼ同じ手順で構築できる。dnscache-conf コマンドに設定するホストのネット
ワークアドレスを与えて起動する。
# dnscache-conf dnscache dnslog /var/dnscachex 10.0.1.23
これにより /var/dnscachex ディレクトリに必要なファイルがインストールされ
る。これも
# ln -s /var/dnscachex /service
とすることでsvscanが5秒以内に検知して外部キャッシュサーバが立ち上がる。
続いてDNS参照を許可するクライアントのIPアドレスを登録する。許可するホス
トのIPアドレスをファイル名とする空ファイルを /var/dnscachex/root/ip ディ
レクトリに作成する。たとえば
# touch /var/dnscachex/root/ip/10.0.1.24
とすると IP アドレスが 10.0.1.24 であるホストからのDNS参照を許可し、
# touch /var/dnscachex/root/ip/10.0.2
とすると、10.0.2.x (xは任意)のIPアドレスを持つホスト全てからのDNS参照を
許可することができる。
●ドメイン固有のネームサーバの明示的指定
dnscacheでは特定のドメインに属する名前の問い合わせを指定したネームサーバ
に直接行なうように指示することができる。たとえば、自社のホスト名であれば
自社のネームサーバに直接問い合わせた方が効率が良い。この指定は dnscache
管理ディレクトリの中の "root/servers/<ドメイン名>" というファイルで行な
う。もし、自社のドメインがhoge.co.jp(10.1.0.0/16) で、そのネームサーバが
10.1.1.1 だとしたら以下のようにする。
# echo 10.1.1.1 > /var/dnscachex/root/servers/hoge.co.jp (順引き用)
# echo 10.1.1.1 > /var/dnscachex/root/servers/1.10.in-addr.arpa (逆引き用)
●キャッシュサーバのパラメータ設定
dnscache-conf で管理ディレクトリを作成すると以下のディレクトリ、ファイル
が生成される。このディレクトリの構造は後述する tinydns の管理ディレクト
リと同様のものとなっている。
* envディレクトリ
プログラム起動時に与える環境変数とその値を持つファイルを格納する。ここ
に置くファイルで実際にプログラムに動作パラメータを渡すことになる。
* logディレクトリ
プログラムの出力するログを受け取るディレクトリ。このディレクトリも
supervise が管理するので run スクリプトなどが含まれる。
* superviseディレクトリ
superviseがデーモンプロセスを監視する作業ディレクトリ。
* runスクリプト
実際にデーモンプロセスを動かすためのスクリプト。デーモンプログラムを呼
ぶときに、envdirプログラムを経由させて、起動に必要な環境変数を渡してい
る。
このうち、envディレクトリにあるファイルでキャッシュ用のパラメータを調整
することができる。変更できるパラメータは以下の通り。
* env/CACHESIZE
キャッシュするデータのバイトサイズを指定する。デフォルトは1000000。
* env/DATALIMIT
プロセス起動時のリソース datasize のリミット値を設定する。この値は
softlimit コマンドに渡される。デフォルトは3000000で、もちろん
env/CACHESIZEで指定したものより大きくなければ無益である。
* env/IP
dnscacheがlistenするIPアドレスを設定する。
* env/IPSEND
パケット送出アドレスを指定。通常は0.0.0.0を指定。
* env/ROOT
キャッシュをコントロールするディレクトリを指定。
メモリに余裕があればキャッシュサイズは大きいほど効果的であるが、dnscache
ではどんなレコードも(TTLにかかわらず)最長で一週間しか保存しない。
CACHESIZEを大きくする場合は利用状況を見てレコード寿命が平均で一週間を超
過しない範囲にとどめるように留意すると良い。平均寿命を知るにはログファイ
ル(log/main/current)の中の stats 行を参考にする。まず、ある時点での
stats 行を見る。
# grep -w stats /var/dnscachex/log/main/current \
| tai64nlocal | tail -1
次に、およそ24時間後にもう一度 stats 行を見る。二つのstats行が以下の通り
だったとしよう。
2000-11-14 02:00:22.750708500 stats 1992 105360 3
~~~~~~
2000-11-15 06:15:34.542646500 stats 7153 326252 1
~~~~~~
statsに続く数字のうち2番目のものがキャッシュのデータ移動量に当たる。この
場合 326252-105360=220892 がこのキャッシュサーバでの一日のデータ移動量と
なる。したがって、一週間程度のレコード寿命を確保するにはこの値を7倍、余
裕を見て10倍程度にした2000000バイト程度のCACHESIZEがあれば十分ということ
になる。DATALIMITもこれに合わせて大きく取り直す必要があるので、
# echo 2000000 > /var/dnscachex/env/CACHESIZE
# echo 2097152 > /var/dnscachex/env/DATALIMIT
# svc -t /service/dnscachex
のようにする。
■ネームサーバの構築
ある特定のドメインのホスト名情報を受け持つネームサーバもdjbdnsによって構
築できる。これにはtinydnsを利用する。tinyという名前から簡素で機能的に貧
弱なのではないかと思うかもしれないが、プログラム自身の作りがコンパクトで、
設定ファイルも簡潔だということで、そのパフォーマンスはきわめて高い。大規
模なドメインの管理を高速にこなせるのも大きなアドバンテージとなっている。
また、設定ファイルを作成する苦労から開放されるのも管理者にとってありがた
い。BINDでは多かれ少なかれ、named起動時の設定ファイル、順引き用ゾーンファ
イル、逆引き用ゾーンファイルなどを自分のサイト用に正しく書き換え(もしく
は作成し)なくてはならない。文法も厳密に定義されているので、セミコロン等
の記号を忘れたりするとそれだけでうまく機能しなくなるのでなかなか神経を遣
う。tinydnsではサーバプログラム自身の定義ファイルは不要であり、さらにゾー
ンファイルも驚くほど簡潔な形式になっていて、順引きレコードと逆引きレコー
ドの対応を人間が取る必要がなくなっている(後述)。
●tinydnsの設定
ここでも既に daemontools がインストールしてあり、svscan に /service ディ
レクトリを監視させる状態になっていることを前提として解説を進める。
tinysdnsが動作するときにUIDを必要とするのでそれを作成する。
# vipw
--------------------------------------------------
dns:*:9802:9800:0:0:/var/dns:/bin/noshell (追加)
--------------------------------------------------
つづいてネームサーバの環境構築を tinydns-conf コマンドで行う。
# tinydns-conf dns dnslog /var/tinydns 192.168.24.8
この例では /var/tinydns ディレクトリに 192.168.24.8 というアドレスで公開
するネームサーバ環境を作成している。もし、公開したいドメイン名がLAN専用
のプライベートなものなら、プライベートIPアドレスを指定し、外部に公開する
ドメインであればグローバルIPアドレスを指定することになろう。
上記の tinydns-conf の起動により /var/tinydns/root にホスト情報を登録す
るために必要なファイルがインストールされる。このディレクトリに作成される
dataというファイルがBINDでいうところのゾーンファイルに相当する。このファ
イルは人間が編集できる形式になっているが、以下のコマンドを利用することに
より簡単にホストの登録が行える。
【add-ns】
ドメインに対するネームサーバを追加する。
./add-ns fqdn ip
と起動すると、ドメイン名 に対するAレコード、NSレコード、SOAを生
成するエントリを追加する。実際にdataファイルに追加されるエントリは
.:::
という形式となる。ドメインのNSレコードのホスト名として が自
動生成され、そのホストのAレコードが となる。はデフォルト値で
ある259200秒(=3日間)が入る。
【add-host】
IPアドレスに対するホストの名前を追加する。
./add-host fqdn ip
と起動すると、ホスト名 に対するAレコードとしてIPアドレス
を生成し、逆に のPTRレコードとして を生成するエントリを追
加する。実際に追加されるエントリは
=::
という形式となる。はデフォルトで86400(24時間)である。
【add-alias】
IPアドレスに対するホストの別名を追加する。
./add-alias fqdn ip
と起動すると、ホスト名 に対するAレコードとしてIPアドレス
を生成するエントリを追加する。逆引きレコードは生成しない。
実際に追加されるエントリは
+::
という形式となる。
【add-mx】
あるアドレスに対するメイルサーバ(MXレコード)を追加する。
./add-mx fqdn ip
と起動すると、ホスト名またはドメイン名 に対するMXレコードとして
IPアドレス を生成するエントリを追加する。
実際に追加されるエントリは
@::::
という形式となる。 のMXレコードのホスト名として が自動生成さ
れ、そのホストのAレコードが となる。 はpreference値でadd-mx
スクリプトで追加した場合は省略されて、既定値の0となる。明示的に
preference値を指定したい場合はdataファイルを直接編集すればよい。
【add-childns】
サブドメインに対して権限を委譲するエントリを追加する。
./add-childns fqdn ip
と起動すると、サブドメイン名 に対する NS, A レコードを生成する
エントリを追加する。実際に追加されるエントリは
&:::
という形式となる。
これらのコマンドを利用してdataファイルに何個かエントリを足してみれば
tinydnsで参照するファイルの仕組みが大体理解できるのではないかと思う。
dataファイル形式の詳しい仕様の説明は
http://cr.yp.to/djbdns/tinydns-data.html
にあるので、実際に管理を始めるときに参考にするとよいだろう。
●tinydnsのパラメータ設定
tinydns-conf で作成された管理ディレクトリ内の env ディレクトリにやはり動
作環境を決定するファイルがあるのでこれを変更することでパラメータ設定が行
える。
* env/IP
tinydnsがlistenするIPアドレスを設定する。
* env/ROOT
ドメインのdataファイルを置くディレクトリを指定する。
サーバのIPアドレスや、ファイルの起き場所を変えた場合などはこれらのファイ
ルを変更することで対応することができる。
■tinydnsによるネームサーバ構築例
新しいDNSドメイン構築を想定して、実際の手順をシミュレーションしてみよう。
ここでは新しく管理するドメインとして subdom.ymzk.org というドメインを保
持するネームサーバを 10.8.50.1 というIPアドレスをもつホストで管理したい。
もちろん、djbdnsによる管理作業を始める前にドメイン名の申請、あるいは上位
ドメインからのネームサーバの権限委譲は受けていることを前提とする。
前節の手順で解説したように、まずデータ管理を行うディレクトリを作成し、
サービスを起動する。
# mkdir /var/dns
# tinydns-conf dns dnslog /var/dns/namedb 10.8.50.1
# ln -s /var/dns/namedb /service
IPアドレス 10.8.50.1 の部分は、自身で管理する予定のホストのものに、そし
て管理ディレクトリは自身で管理するシステムにふさわしい適切なディレクトリ
に適宜読み変えて欲しい。続いてこのドメインのネームサーバ自体にかかわるエ
ントリを作成する。
# cd /var/dns/namedb/root
# ./add-ns subdom.ymzk.org 10.8.50.1
ただし、add-nsコマンドによって足されるNSレコードは a.ns.subdom.ymzk.org
という機械的に付けられる名前となる。しかし多くの場合上位ドメインからのNS
指定は、ns1.subdom.ymzk.org などのように話し合いによって決められた典型的
な名前が既に付けられていることが多い。そのような場合は、dataファイルを直
接編集してNSとなるホスト名を直接記述する。
# vi data
(修正前) .subdom.ymzk.org:10.8.50.1:a:259200
↓
(修正後) .subdom.ymzk.org:10.8.50.1:ns1.subdom.ymzk.org:259200
セカンダリサーバがあるならば、それらに対しても同様の登録作業を行う。
つづいて、ドメインに属する一般ホストを登録しよう。smoke(10.2.50.2) と
twin(10.8.50.1)というホストを追加する。
# ./add-host smoke.subdom.ymzk.org 10.2.50.2
# ./add-host twin.subdom.ymzk.org 10.8.50.1
また、このドメインのメイルサーバを 10.2.50.2 で受け持ち、セカンダリメイルサー
バとして 10.2.50.4 を利用することを知らせる。
# ./add-mx subdom.ymzk.org 10.2.50.2
# ./add-mx subdom.ymzk.org 10.2.50.4
これにより追加される二つのメイルサーバの preference 値を変えておきたい場
合はやはりdataファイルを直接変更する。
(変更例)
# vi data
(修正前) @subdom.ymzk.org:10.2.50.2:a::86400
@subdom.ymzk.org:10.2.50.4:b::86400
↓
(修正後) @subdom.ymzk.org:10.2.50.2:a:10:86400
@subdom.ymzk.org:10.2.50.4:b:20:86400
ネットーワークサービス用ホストの別名を設定しよう。
POPサービスを10.2.50.2で行い、WWWサービスを10.8.50.1で受け持つのでこれの
別名を設定する。
# ./add-alias pop.subdom.ymzk.org 10.2.50.2
# ./add-alias www.subdom.ymzk.org 10.8.50.1
最後にtinydnsが解釈できるようcdb形式に変換する。
# make
これでネームサーバ側の作業は完了した。実際に名前が引けるか確認してみよう。
別のホストからhostコマンド、またはdnsqueryコマンドを利用して行う。
nslookupコマンドはBINDの実装に依存しているいくつかの問題点があって、ネー
ムサーバをコマンドラインで明示的に指定したときにうまく引けないことが多い
(※1)が、host, dnsqueryは正常に問い合わせを行うことができるのでこれらを
利用する。
----------
※註1
http://cr.yp.to/djbdns/faq/tinydns.html#nslookup 参照
----------
ネームサーバ(10.8.50.1)に到達可能な別のホストから設定したドメインのホス
トのレコードが引けるか確認しよう。
anotherhost% host smoke.subdom.ymzk.org 10.8.50.1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Using domain server 10.8.50.1:
smoke.subdom.ymzk.org has address 10.2.50.2
anotherhost% dnsquery -n 10.8.50.1 -t mx subdom.ymzk.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33010
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 3
;; subdom.ymzk.org, type = MX, class = IN
subdom.ymzk.org. 1D IN MX 10 a.mx.subdom.ymzk.org.
subdom.ymzk.org. 1D IN MX 20 b.mx.subdom.ymzk.org.
subdom.ymzk.org. 3D IN NS ns1.subdom.ymzk.org.
a.mx.subdom.ymzk.org. 1D IN A 10.2.50.2
b.mx.subdom.ymzk.org. 1D IN A 10.2.50.4
ns1.subdom.ymzk.org. 3D IN A 10.8.50.1
また、データ登録のときには全く意識しなかったSOAも自動的に生成されている
ことが以下の通り分かる。
TRX# dnsquery -n 10.8.50.1 -t soa subdom.ymzk.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14707
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; subdom.ymzk.org, type = SOA, class = IN
subdom.ymzk.org. 42m40s IN SOA ns1.subdom.ymzk.org. hostmaster.subdom.ymzk.org. (
973855992 ; serial
4h33m4s ; refresh
34m8s ; retry
1w5d3h16m16s ; expiry
42m40s ) ; minimum
subdom.ymzk.org. 3D IN NS ns1.subdom.ymzk.org.
ns1.subdom.ymzk.org. 3D IN A 10.8.50.1
この出力で分かるように、ドメインの管理者のメイルアドレスとして
hostmaster が自動的に埋め込まれるので、このアドレスで受け取れるように設
定しておくことを忘れないようにする。
●セカンダリネームサーバ
ネームサーバの運用にはセカンダリサーバ(※あ)が不可欠である。これから
djbdnsを導入しようというときに一番厄介なハードルとなるのがセカンダリサー
バではないだろうか。セキュリティ上の問題から tinydns には zone transfer
が用意されておらず、セカンダリネームサーバには、dataファイルをrsync等の
安全なリモートアップデートツールでコピーすることが推奨されている。しかし、
BINDによるネームサーバとの相互運用性を確保するために zone transfer を行
う専用のツールが用意されている。「セキュリティとデータ管理の手間軽減を考
慮してdjbdns に移行したいが、セカンダリサーバとの連係が…」などというケー
スは多いと思われ、このような場合には djbdns パッケージにある zone
transfer 用ツールを利用するのが現実的な解決策であろう。
-----
※註あ
最近のBINDでは master←→slave という関係で呼んでいる。djbdnsではとくに
定義せず「DNSサービスの複製(replicate)をする」とだけ説明している。本稿で
は中立的な意味でオリジナルデータを持っているサーバをプライマリ、
その正規コピーを持つサーバをセカンダリと呼ぶことにする。
-----
ここでは、新しくdjbdnsを用いてDNS管理をする場合に考慮せねばならないセカ
ンダリサーバとの連係措置についての方針の一例を紹介しよう。
・djbdns → djbdns
プライマリサーバとセカンダリサーバでともにdjbdnsを利用している場合はデー
タファイルをrsyncでセカンダリサーバに送り込むのが安全かつ効率的である。
ホストの追加等を行ったときにはmakeによってdataファイルをcdb形式に変換す
るので、この Makefile に
rsync -avz data dns@secondaryserver:/var/dns/tinydns/root
などのようなコマンドを含めてしまうのが確実である。secondaryserver 側では
一定時間毎に tinydns-data コマンド(またはそれを走らすmake)を呼ぶように
cronに登録しておく。
・djbdns → BIND
自ホストがdjbdnsに移行したが、bind運用サイトにセカンダリサーバをお願いし
ている場合はtinydnsだけでなく、zone transfer 供給を行う axfrdns プログラ
ムを利用する。axfrdns は tinydns が読むのと同じデータファイルを読み込ん
で外部からの zone transfer 要求に応えるよう TCP の53番ポートで待ち受ける。
このときアクセスを許可するホストを制限するにはtcpserverを利用する。
tcpserverは ucspi-tcpをインストールすることで利用できる。原稿執筆時の最
新版は ucspi-tcp-0.88.tar.gz (本誌付録CDROMに収録) で、インストールは
daemontools, djbdns と全く同様
# tar vzxpf ucspi-tcp-0.88.tar.gz
# cd ucspi-tcp-0.88
# vi conf-home (←インストールPATHの確認)
# make
# make setup check
で完了する。tcpserverがインストールされたことを確認したら axfrdns の管理
ディレクトリを作成する。以下の例は /var/dns/namedb にプライマリサーバ用
のtinydnsデータがある場合に、これを axfr で zone transfer 配布するための
ディレクトリを /var/dns/axfrdns に作成する作業を示している。
# axfrdns-conf dns dnslog /var/dns/axfrdns /var/dns/namedb 10.8.50.1
すると /var/dns/axfrdns ディレクトリにアクセス制限をかける定義ファイルと
なる tcp ファイルができている。このファイルは tcpserver が解釈して、接続
要求をして来たクライアントのIPアドレスによってサービスデーモンの起動時の
条件を制御するためのものである。デフォルトで作成されるtcpファイルの内容
は以下のようになっている。
# sample line: 1.2.3.4:allow,AXFR="heaven.af.mil/3.2.1.in-addr.arpa"
これを参考にすると、「セカンダリサーバ(192.168.5.5)に対して、
subdom.ymzk.org ゾーン と 10.in-addr.arpa ゾーンの転送許可を与える」場合
のアクセス制御定義は以下のように書ける。
192.168.5.5:allow,AXFR="subdom.ymzk.org/10.in-addr.arpa"
:deny
設定すべき環境変数AXFRには、zone transfer 対象となるゾーン名を/(スラッシュ)
で区切って書く。tcpファイルの修正が終わったらmakeの実行によりtcpserverが
読める tcp.cdb ファイルに変換される。
続いてaxfrサービスを起動する。これもsvscanに通知するだけで自動的に起動
される。
# ln -s /var/dns/axfrdns /service
ひとつ注意が必要なのは、./run スクリプト実行時に tcpserver コマンドが
PATHに含まれているようにすることである。ucspi-tcpをdaemontoolsと同じ場所
にインストールした場合はとくに問題は起きないが、別のディレクトリにインス
トールした場合は /var/dns/axfrdns/log/main/current に
softlimit: fatal: unable to run tcpserver: file does not exist
などのエラーメッセージが出てうまく起動できないことがある。この場合は
svscan起動時に ucspi-tcp のコマンドのあるディレクトリをPATHに含めるよう
にする(※2)か、/var/dns/axfrdns/run スクリプト中の tcpserver コマンドを
フルパス記述に書き換える。
----------
※註2
axfrdnsサービスに限らず svscan 経由のサービスがうまく起動しないときは、
環境変数PATHに必要なコマンドのあるパスが入っているかを確認するとよい。
----------
正常に起動したかどうかを確認する。
# svstat /service/axfrdns
~~~~~~~~~~~~~~~~~~~~~~~
/service/axfrdns: up (pid 30476) 2681 seconds
最後に、zone transfer 許可を与えたホストから確認する。
実行例いのようにゾーンファイル形式で登録された名前一覧が獲得できれば成功
である。
-------------------- 実行例い(許可を与えたホスト192.168.5.5から)
% host -v -l -t any subdom.ymzk.org 10.8.50.1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Using domain server:
Name: ns1.subdom.ymzk.org
Address: 10.8.50.1
Aliases:
Trying 10.8.50.1
subdom.ymzk.org 2560 IN SOA ns1.subdom.ymzk.org hostmaster.subdom.ymzk.org(
973855992 ;serial (version)
16384 ;refresh period
2048 ;retry refresh this often
1048576 ;expiration period
2560 ;minimum TTL
)
subdom.ymzk.org 259200 IN NS ns1.subdom.ymzk.org
ns1.subdom.ymzk.org 259200 IN A 10.8.50.1
smoke.subdom.ymzk.org 86400 IN A 10.2.50.2
twin.subdom.ymzk.org 86400 IN A 10.8.50.1
subdom.ymzk.org 86400 IN MX 10 a.mx.subdom.ymzk.org
a.mx.subdom.ymzk.org 86400 IN A 10.2.50.2
subdom.ymzk.org 86400 IN MX 20 b.mx.subdom.ymzk.org
b.mx.subdom.ymzk.org 86400 IN A 10.2.50.4
pop.subdom.ymzk.org 86400 IN A 10.2.50.2
www.subdom.ymzk.org 86400 IN A 10.8.50.1
:
:(SOAが二回表示される…)
:
--------------------
・BIND → djbdns
BINDによる別ドメインのセカンダリサーバを受け持っていて、それをdjbdnsに移
行したい場合は axfr-get プログラムを利用してプライマリサーバから定期的に
新しいレコードを回収したものをtinydnsに与えるようにすればよい。axfr-get
プログラムは、ucspi-tcp 付属のtcpclientプログラムと組み合わせて利用する。
たとえば、別部署の other.ymzk.org というドメインのネームサーバが
192.168.5.5 だと仮定したときに、ここから other.ymzk.org を zone transfer
で受け取る場合は、
# tcpclient 192.168.5.5 53 axfr-get other.ymzk.org other.dat other.tmp
とすると、other.dat ファイルに結果が得られる。これは tinydns-data 形式と
なっているのでこれを tinydns の管理ディレクトリにある data ファイルに追
加してやればよい。ちなみに、IPv6用のAAAAレコードも正しく処理できる(とい
うか未知のレコードタイプの切捨て処理等を行っていないので将来どんなレコー
ドタイプが増えても影響がない)。
%%%%%%%%%%%%%%%% プライマリとセカンダリを兼ねる話、書くかなあ…?
%%%%%% このコラム、省略可能です。
=== コラム ===================================================================
【プライマリ/セカンダリネームサーバを一つのtinydnsで賄うTips】
axfr-getを利用すれば、他ドメインのゾーン情報をtinydns-data形式で得ること
ができる。これは行指向のレコードファイルであるため複数のドメインのファイ
ルををcatすれば全てのドメインのレコードを含むファイルが作成できる。これ
に、自己ドメインのものを含めたネームサーバを立てるための工夫の一例を紹介
しよう。本文中で説明したように、プライマリサーバを行うドメインのホストを
追加するには add-host コマンドなどを利用する。add-* コマンド群、
tinydns-data コマンド、いずれもデータファイル名として "data" を要求する
ので、他ドメインのゾーンレコードをcatする処理がやりづらい。そこで、
add-* コマンドの処理処理対象となるファイル名を "data" から別のものに変え
てしまうと複数ゾーンのマージがやりやすくなる。たとえば、プライマリサーバ
となる自己ドメイン名が local.domain である場合、add-* コマンドで管理するファ
イル名もやはり "local.domain" にしてしまう。add-* コマンドはシェルスクリ
プトなのでそこに書かれている "data" をすべて "local.domain" に書き換える。
# perl -i -pe 's/data/local.domain/g' add-*
# touch local.domain
さらにセカンダリを受け持つドメインが ext1.domain, ext2.domain の場合は
Makefile を次のようにしておけば効率的に3つのドメインを含むdataファイルを
更新できる。
[Makefile]
TCPCLIENT = /usr/local/bin/tcpclient
AXFRGET = /usr/local/bin/axfr-get
all: data.cdb
ext1.domain: /dev/null
${TCPCLIENT} "ext1.domainのサーバ" 53 ${AXFRGET} $@ $@ dummy.tmp
ext2.domain: /dev/null
${TCPCLIENT} "ext2.domainのサーバ" 53 ${AXFRGET} $@ $@ dummy.tmp
data: ext1.domain ext2.domain local.domain
cat $> > data
data.cdb: data
/usr/local/bin/tiny-dns
==============================================================================
●ネームサーバ統合化の注意点
djbdnsではキャッシュサーバ、ネームサーバ、zone transferプログラムが独立
している。それぞれを設置すべきネットワーク的位置は本来異なる。キャッシュ
サーバはLAN内のみから到達できるアドレス(たとえばNATマシンのプライベート
側アドレス)にあればいいし、ネームサーバは外部のあらゆるホストからの問い
合わせに答えられるようグローバルアドレスを持つホストが持つべき(プライベー
ト空間用の名前ならばその逆)だし、zone transferはセカンダリとなるホストか
ら到達可能でさえあればよい。これを熟慮して適切なホストで各種デーモンを動
かすのが望ましいのだが、都合により一台で賄わなければならないときは以下の
点に注意して、各サービスが利用するポートが競合しないように設置すればよい。
サービス | 使用ポート
------------+------------------
dnscache | UDP 53
tinydns | UDP 53
axfrdns | TCP 53
これから分かるようにdnscacheとtinydnsは同じホストの同じIPアドレスでは起
動できない。各ホストが NAT BOX を介して間接的にインターネットに出て行け
るプライベートアドレスで構成されたLAN (*.mylan.private, 192.168.0.0/24 図う)
があると仮定すると、最大以下のようなサーバを必要と感じるだろう。
1. LAN内でのみ有効なプライベートなドメイン名(*.mylan.private)
のネームサーバ
2. LAN内のホスト(10.0.0.0/24)だけが参照できるキャッシュサーバ
3. グローバルIPアドレスを持つホスト群のドメイン名用のネームサーバ
4. (3)のzone transferを許すaxfrdns
-------------
図う
〜〜〜 The Internet 〜〜〜
|
[gateway]
| (global area 10.2.50.0/28)
..-----+-------+-------+-------+-------+-------+--.....
| | | | |
[host1] | [WWW] [host3] [host4] (*.subdom.ymzk.org)
|(10.2.50.3)
[NAT]
|(192.168.0.1) (private area 192.168.0.0/24)
...-----+-------+-------+-------+-------+-------+--.....
[pc1] [pc2] [pc3] [pc4] [pc5] [pc6]
〜〜〜*.mylan.private〜〜〜
(↑このLAN用のネームサーバを立てたい)
-------------
ここでネームサーバを動かせるホストがNATホストしかなかったとしよう。極端
な例だが、このような場合も4つのデーモンを次のように配置すると全てのサー
ビスを一台で賄える。
# tinydns-conf dns dnslog /var/dns/private 127.0.0.1 (1用)
# dnscache-conf dnscache dnslog /var/dns/dnscache 192.168.0.1 (2用)
# tinydns-conf dns dnslog /var/dns/global 10.2.50.3 (3用)
# axfrdns-conf dns dnslog /var/dns/axfrdns \ (4用)
/var/dns/global 10.2.50.3
# touch /var/dns/dnscache/root/ip/192.168.0 (LANに参照許可を出す)
# echo 127.0.0.1 > /var/dns/dnscache/root/servers/mylan.private
# echo 10.2.50.3 > /var/dns/dnscache/root/servers/subdom.ymzk.org
:
(以後、ホスト名の追加やaxfrdns用のtcpserverのアクセス制御などを行う…)
最後の二行では、外部キャッシュサーバに「*.mylan.privateの名前問い合わせ
があったら、127.0.0.1 のネームサーバに、*.subdom.ymzk.org は 10.2.50.3
に問い合わせよ」という指定を行なっている。
■その他のデーモン
djbdnsには少し特殊な環境で役に立つ気の利いたツールも用意されているので簡
単に紹介しておこう。
●walldns
あるIPアドレス (a.b.c.d) にたいする逆引き問い合わせ(PTRレコード)全てに
d.c.b.a.in-addr.arpa を返す、いわば自動PTRレコード生成ネームーサーバであ
る。tinydns-data形式でいえば
=d.c.b.a.in-addr.arpa:a.b.c.d:
に相当するレコードを任意のIPアドレスへの問い合わせに関して生成すると考え
ればよい。anonymous ftpサーバなどでは、IPアドレスの逆引き登録がされてい
ないものは接続を拒否するものがあるので、ホスト名情報を開示したくないホス
トがあるときや大量のクライアントマシンの逆引き登録の作業を軽減するなどの
意味合いがあるのではなかろうか。
設置にはtinydnsなどと同様 *-conf コマンドで行う。
# walldns-conf アカウント ログ用アカウント ディレクトリ IPアドレス
# ln -s ディレクトリ /service
●pickdns
ある名前に対して複数の異なるIPアドレスを返すためのネームサーバである。
WWWサーバ等の負荷分散等の目的に利用できる。設置はやはり同じ手順で行える。
# pickdns-conf アカウント ログ用アカウント ディレクトリ IPアドレス
# ln -s ディレクトリ /service
このdataファイルもtinydns-data形式となっている。
+fqdn1:ip1
+fqdn1:ip2
+fqdn1:ip3
:
:
のように同じ名前に対して最大128個までのIPアドレスを登録できる。
また、dataファイルの先頭の + を - に変えることにより、一時的にそのIPアド
レスを候補から外すことができる。
上記の定義に加えて、特定の場所からの問い合わせに答える候補を異なるIPアド
レス集合に定義することもできる。
%KO:131.113
%KO:133.27
+www.xxxx.yyy:10.8.50.1:KO
+www.xxxx.yyy:10.8.50.5:KO
+www.xxxx.yyy:10.8.50.6:KO
:
:
%で始まる行はロケーション定義で、アルファベット(最大)2文字のロケーション
コードの定義である。%で定義したコードを + によるIPアドレス登録行に、コロ
ンで区切って付加することにより、そのロケーション定義で示されたIPアドレス
prefixをもつクライアントからの問い合わせには、それらの答を返すようになる。
これもマイナス(-)記号を利用してその行を候補から外すことができる。
●rbldns
IPアドレスの一覧を保持するゾーンを作成するために利用する。具体的な例でい
うと、MAPS RBL(※お)のようなデータベースとなるネームサーバを構築するとき
に使うことができる。MAPS RBL とは、不正中継が可能な状態になっているSMTP
サーバの一覧をDNS上に保持する、いわば迷惑設定のSMTPサーバのブラックリス
トである。任意のSMTPサーバは、配送依頼の接続要求をして来たクライアントホ
ストのアドレスが、そのブラックリストに載っているかどうかを簡単に調べるこ
とができる。そのような、多数のIPアドレスが含まれる巨大なデータベースを
DNS上に構築するときに利用するのがrbldnsである。
----------
註お
Mail Abuse Prevention System, Realtime Blackhole List.
http://mapx.vix.com/
----------
■まとめ
固定IPアドレスによる常時接続環境がずいぶん手頃な価格になって来た。そこに
個人ドメインのサーバを上げよう、というときにネームサーバをどうするかが問
題となってくる。djbdnsはそのようなときの強い見方となるだろう。コンピュー
タ界では「バグのないソフトウェアはない」とよく言われる。しかし、その法則
もKnuth先生とdjb氏の公開ソフトウェアには当てはまらないのではないかと思え
るほど djb tools は安定している。djbdnsはOS標準のものではないので、最初
に関連ツールを含めてインストールするという手間はあるが、ひとたび設定が終
わったら全く手のかからない道具になることは間違いないだろう。これから新し
いドメインのネームサーバを構築する場合は、djbdnsの導入を考えてみてはいか
がだろうか。
yuuji@
Fingerprint16 = FF F9 FF CC E0 FE 5C F7 19 97 28 24 EC 5D 39 BA