設定と運用の基本的な例

想定環境

インストールのページで挙げたdo-configure.shの内容にしたがってインストールしてあると仮定します。
このホスト(ns.example1.jp[10.2.0.4])では以下の2つのゾーンのネームサービスを提供することにします。

example1.jp
- プライマリとして動作する。
- ns.example2.jp[10.2.0.3]がセカンダリとして動作する。
example2.jp
- セカンダリとして動作する。
- マスタとしてns.example2.jp[10.2.0.4]を参照する。

rootの特権を放棄するためにsetuid()する仮想ユーザはnsd(configureのデフォルト)とします。また、nsdの-tオプションのパラメータには/proj/nsd3を与えてchroot()することにします。
FreeBSD 6.1で動作確認しましたので、OSに依存する箇所はFreeBSDの場合について説明します。また、もしかすると意図せずOSに依存している箇所があるかもしれません。

環境構築

ユーザnsdのアカウントの作成

vipw(8)などでnsdという仮想ユーザのアカウントを作成します。動作確認したホストでは、元々あったbindという仮想ユーザのエントリをcut&pasteして第1フィールドだけbindからnsdに書き換えたので(今、このページを書きながら確認したら、GECOSフィールドも"Bind Sandbox"のままでした :-)、getgrgid()はnsdではなくbindというユーザ名を返してきます。

chroot環境の作成

以下のディレクトリツリーを作成します。


/- proj - nsd3 -+- etc -+- localtime
                |       |
                |       +- namedb ----+- primary/
                |                     +- secondary@
                |
                +- var -+- db ---------- namedb ---- secondary/
                        |
                        +- run/

動作確認したホストは実験機なのでやっていませんが、本格的に運用するサーバでは、/proj/nsd3/var以下はファイルシステムを分けた方が、人間の操作によらずプログラムにより自動的に行われる書き込みアクセスのファイルシステムあるいはセクタレベルでの局所化、つまりファイルシステムがクラッシュした際の被害範囲の局所化の観点で好ましいのではないかと思います。同様の理由で/proj/nsd3/etc/namedb/secondaryは、../../var/db/namedb/secondaryを指すsymbolic linkにしていますが、気にならない人はディレクトリの実体を作成すればいいと思います。
/proj/nsd3/var以下のオーナを

# chown -R nsd /proj/nsd3/var

のようにして、仮想ユーザnsdに変更しておきます。
/proj/nsd3/etc/localtimeは/etc/localtimeをコピーしておきます。これを忘れると、nsdのプロセスのタイムゾーンがUTCになってしまい、ログのタイムスタンプがUTCで記録されてしまいます(少なくともFreeBSDでは)。
syslogdが/proj/nsd3/var/run/logというソケットでメッセージを待ち受けるように設定します。FreeBSDの場合、syslogdに-l /proj/nsd3/var/run/logというオプションを与えます。/etc/rc.confに

syslogd_flags="-s -l /proj/nsd3/var/run/log"

というエントリを加えれると、次回のboot時から反映されます。あるいは、まず/etc/rc.confにこのエントリを追加してから

# /etc/rc.d/syslogd restart

を実行します。-sについては、/etc/defaults/rc.confに記載されているので、ここでも引き継ぎましたが、それぞれの環境に応じて設定して下さい。

nsd.confの作成

/proj/nsd3/etc/nsd.confを以下の内容で作成します。


server:
        chroot: /proj/nsd3
        zonesdir: /proj/nsd3/etc/namedb

zone:
        name: example1.jp
        zonefile: primary/example1.jp
        provide-xfr: 10.2.0.3 NOKEY
        notify: 10.2.0.3 NOKEY

zone:
        name: example2.jp
        zonefile: secondary/example2.jp
        allow-notify: 10.2.0.3 NOKEY
        request-xfr: 10.2.0.3 NOKEY
        allow-notify: 127.0.0.1 NOKEY

configureにchroot:オプションと対応する引数がないことと、インストールのページで述べたように、NSD 3.0.3の時点ではconfigureの--zonesdir引数が無効だったので、これら2つのオプションをserver: clauseに設定し、あとはconfigureで設定したデフォルト値を使っています。zonesdirの問題はNSD 3.0.4で修正されているので、NSD 3.0.4以降のバージョンでは、configureに与えた引数と変更するのでなければnsd.confに設定する必要はありません。
example2.jpゾーンはセカンダリとして動作するので、allow-notify:オプションで127.0.0.1あるいは::1からのNOTIFYを許可しないと、nsdc updateを実行した際にエラーが発生します。

ゾーンデータ

example1.jpゾーンのゾーンデータを/proj/nsd3/etc/namedb/primary/example1.jpというパス名で作成します。構文はアーキテクチャのページで述べたように、$GENERATEディレクティブを除いて、BINDと互換です。

nsd.dbの生成

以下のようにして/proj/nsd3/var/db/nsd.dbを生成します。


# /usr/bin/su -m nsd
# /proj/nsd-3.0.3/sbin/nsdc rebuild
zonec: reading zone "example1.jp".
zonec: processed 4 RRs in "example1.jp".
zonec: reading zone "example2.jp".
warning: slave zone example2.jp with no zonefile 'secondary/example2.jp'(No such file or directory) will force zone transfer.

zonec: processed 0 RRs in "example2.jp".

zonec: done with 0 errors.

この工程が必要なところが、BINDとの相違点の中でも目立つところではないでしょうか。

'secondary/example2.jp'(No such file or directory)

というメッセージに一瞬ドキリとしますが、warningであり、また直後にwill force zone transfer.という文言が続いているように、まだexample2.jpゾーンのゾーンデータが存在しないので、nsdを起動したらゾーン転送を要求します、という意味なので問題ありません。

nsdの起動

以下のようにしてnsdを起動します。


# /proj/nsd-3.0.3/sbin/nsdc start
[1167123640] nsd[82723]: warning: No IPv6, fallback to IPv4. getaddrinfo: hostname nor servname provided, or not known

あるいは

# /proj/nsd-3.0.3/sbin/nsd -t /proj/nsd3

のように直接nsdを起動しても構いません。
起動時に表示されているwarningは、IPv6が無効になっているホストで起動したときに表示されますが、動作には問題ありません。気になるようであれば、nsd.confのserver: clauseにip4-only: yesというオプションを追加すると表示されなくなります。ここの動作はNSD 3.0.2から3.0.3へのバージョンアップで変更されており、NSD 3.0.2では

configureに--disable-ipv6引数を与えずにインストールしたnsdを
IPv6が無効なFreeBSD 6.1で
起動時オプション-4もnsd.confのip4-only:オプションも与えずに

起動すると、この箇所でエラーとなって異常終了していました。何らかの理由でNSD 3.0.2以前を使われる場合には注意して下さい。

動作確認

起動した端末やログに異常を示すメッセージが出力されていなければ、digなどでexample1.jpゾーン、example2.jpゾーンについて動作を確認しましょう。
ここまでの操作で/proj/nsd3/var/dbディレクトリにnsd.dbと、example2.jpゾーンのゾーン転送に失敗していなければixfr.dbとxfrd.stateというファイルが生成されているはずです。この時点では、ゾーン転送してきたexample2.jpゾーンのデータは、ジャーナルのixfr.dbに格納されているので、/proj/nsd3/etc/namedb/secondary/example2.jpはまだ存在しませんが、問題ありません。

nsdc patch

ここで以下のようにしてnsdc patchを実行します。



# /usr/bin/su -m nsd
# /proj/nsd-3.0.3/sbin/nsdc patch
reading database
reading updates to database
writing changed zones
writing zone example2.jp to file secondary/example2.jp
zone example1.jp had not changed.
done
zonec: reading zone "example1.jp".
zonec: processed 4 RRs in "example1.jp".
zonec: reading zone "example2.jp".
zonec: processed 5 RRs in "example2.jp".

zonec: done with 0 errors.

これで/proj/nsd3/var/db/ixfr.dbがなくなり、/proj/nsd3/etc/namedb/secondary/example2.jpが生成されます。その後、もう1度nsdc rebuildを実行すると


# /proj/nsd-3.0.3/sbin/nsdc rebuild
zonec: reading zone "example1.jp".
zonec: processed 4 RRs in "example1.jp".
zonec: reading zone "example2.jp".
zonec: processed 5 RRs in "example2.jp".

zonec: done with 0 errors.

今度はexample2.jpについてもwaningは出力されません。これらの動作についてはアーキテクチャのページも参照して下さい。
このままで運用を続けても構わないんですが、ゾーン転送で得たデータが、いつまでもジャーナルに保持されたままでは運用者にとっての見通しが悪いので、cronで定期的にnsdc patchを起動するよう設定しておくとよいと思います。実行周期については、セカンダリとして動作しているゾーンの数やそれらの更新頻度などによるのではないかと思うので、個人的には今のところ定量的な知見はありませんが、doc/READMEには例えば日に1回と書いてあります。nsd 2.xではcronでnsdc updateを実行していましたが、3.xではnsdがSOAのパラメータにしたがってゾーン転送を試みるので、cronでnsdc updateを実行する必要はなくなりました。