FreeBSD8.0 WEBサーバ構築ノート
rndcによるDNSサーバ管理

   rndc（Remote Name Daemon Control）とは、他のサイバーやPCからBIND9の作動状態の確認や、 ドメイン設定ファイルのリロードなど、BIND9の監視・制御を行うためのユーティリティです。 rndcコマンド（/usr/sbin/rndc）を使用することにより、BIND9を再起動することなく制御することができますので、 キャッシュの内容を保持したまま、様々な処理が可能になります。

   BIND8以前のDNSでは、自サーバー上のDNSの監視・制御を行うためのユーティリティとして ndc（Name Daemon Control）を使用しましたが、 BIND9では、他のPCやサーバからネットワークを介してDNSを監視・制御を行うことができます。 また、『BIND9 によるDNS サーバ』のページで述べた通り、 rndcは暗号化鍵によりBIND9と安全に通信することができます。

   rndcの動作条件は、構成ファイル/etc/namedb/rndc.conf で設定できます。 ただし、rndc.conf は、BIND9 の構成ファイル named.conf のサブセットですので、 BIND9をインストールしたマシンであり、 既に暗号化鍵を生成し、named.conf に keyステートメントを使用していれば、 特にrndc.confを設置する必要はありません。

   rndc.conf は、rndc.keyを生成した"rndc-confgen"を用いて以下のように生成されます。 表1　"rndc-confgen"によるrndc.confの生成 生成されたrndc.confは、keyステートメントおよびoptionsステートメントのみで構成されています。 ここでは、rndc.keyを使用しますので、 『BIND9 によるDNS サーバ』のページで既に生成した rndc.keyをincludeします。 また、制御する"default-server"のIPアドレスを書き換えて、表2のようなファイルになります。 表2　"rndc-confgen"で生成後、編集したrndc.conf

   BIND9 の状態を確認するコマンド"rndc status"でDNSの状態を確認してみましょう。 DNSサーバ192.168.1.100自身で実行してみます。 named.conf の controlsステートメントを 『BIND9 によるDNS サーバ』ページの表5 のように設定すると、 表3示す通りDNSの状態を確認することができます。 表3　rndc コマンドによるDNSの状態をの確認結果 しかし、controlsステートメントを 『BIND9 によるDNS サーバ』ページの表4 のように設定すると、 表4に示す通りDNSへの接続が拒否されます。 表4　rndc コマンドによる DNSサーバへの接続拒否

   controlsステートメントを 『BIND9 によるDNS サーバ』ページの表4のように設定した場合は、 rndcコマンドに、"-s"（サーバ）オプションをつけて、表5に示す通りコマンドを変更すると表示されるようになります。 "-s"オプション付きのrndcコマンドは、DNSサーバ自身で実行できるのは勿論ですが、 controlsステートメントで許可したネットワーク（192.168.1.0/24）内にあり、 かつ named.conf あるいは rndc.conf で指定された暗号化鍵（rndc-key）を持つコンピュータから実行することができます。 表5　DNSサーバIPアドレスを指定したrndc コマンドの実行

   rndc コマンドは多岐に渡りますが、ここでは、比較的よく使う便利な rndc コマンドのみご紹介しましょう。 ここに紹介していないコマンドの殆どは、 BIND9 を再起動 すれば達成できますが、再起動の間、DNSは停止します。 前述の通り、rndc コマンドを使用すれば、BIND9を再起動することなくDNSを制御することができます。

   rndc コマンドを使用する場合には rndc.key を読む必要がありますが、一般的に、rndc.key は、root あるいは bind しか読めないよう設定します。 また、通常 bind ユーザは、ログインユーザではないので、rootでログインすることになります。

   named.conf ファイルに新しいゾーンを追加したり削除したりした場合は、 "rndc reconfig"コマンドにより named.conf ファイル、および新たに追加されたゾーンのゾーンファイルの内容が読み込まれます。 なお、このコマンドでは、既存のゾーンファイルの更新内容は反映されませんので、注意してください。 表6　rndc reconfig コマンドによるDNSの再構築

   ゾーンファイルを変更し、これを再読込みしたい場合は、表7に示す通り"rndc reload"コマンドを発行します。 "rndc reload"コマンドは、

rndc

reload

ゾーン名

[レコードクラス]

[view名称]

の形式で構成されます。ここで[ ]付きの項目は省略可能を意味し、 named.conf に view を設定していない場合は、view名称を省略することができます。 表7の例では、"in"は レコードクラス を、 "internal"は view名称（ここでは内向きviewステートメント） を、それぞれ意味します。 表7 rndc reload コマンドによるゾーンデファイルの再読込み（viewがある場合）

   プライマリDNSで「DNSの再構築」や「ゾーンファイルの再読込み」を行うと、 セカンダリDNSに"NOTIFY"メッセージが送信され、ゾーン転送が行われることになりますので、 セカンダリDNS側は、特に何もする必要はありません。

   『BIND9 によるDNS サーバ』ページのloggingステートメントで、 ログの出力方法を解説しました。 この解説の通り設定していれば、表3に示す通り、"rndc status"コマンドでDNSの状態を確認すると、"query logging is ON"となっています。 ここでは、rndc コマンドでクエリーログを停止してみましょう。

   表8の通り"rndc querylog"コマンドにより"query logging is OFF"となり、クエリーログが停止していることがわかります。 また、再度"rndc querylog"コマンドを発行すればクエリーログが再開できます。 『BIND9 によるDNS サーバ』ページの表10 では、クエリーログを3世代までしか保存しないので、それ程サーバのリソースを消費する訳ではありません。 しかし、問題が発生していない時には、殆どクエリーログを見ることはないので、通常はクエリーログを停止しておき、 問題発生時にのみ多量のクエリーログを残したいという運用方法も有効でしょう。 このような場合には、"rndc querylog"コマンドにより namedを再起動することなくクエリーログを制御することができます。 表8　rndc querylog コマンドによるクエリーログの制御