BIND 9を徹底活用するためのTips集：実用 BIND 9で作るDNSサーバ（最終回）（2/2 ページ）

BIND標準ツールの活用

サービスダウン時の自動回復

　突然namedプロセスが落ちることがまれにあります。2Gbytesのゾーンファイルを複数持っているゾーンサーバや、recursive-clientsが限界に達しているキャッシュサーバでは、その確率が高くなります。そのため、プロセスが立ち上がっているか否かを常時監視する必要が生じます。実用qmailサーバ運用・管理術 第9回で、qmailのプロセスをdaemontoolsによって監視する方法を紹介しています。これを応用して、namedプロセスにもdaemontoolsを適用する方法が考えられますが、単純なプロセス監視だけでは名前解決を正常に行っているかどうかを見張ることができません。

　そこで、BIND 9のソースディレクトリにあるPerlスクリプト「nanny.pl」を使用します。nanny.plはデーモンプロセスとしてシステムに常駐し、PIDファイルやdigコマンドでnamedが正常に動作している否かを確認し、異常を検知した場合は指定された引数でnamedを起動します。

　nanny.plは、BIND 9のソースディレクトリのcontrib/nannyにあります。設定は、nanny.plを直接編集することで行います。変更個所は以下の4点です。環境に合わせて適宜編集します。また、Perlが/usr/bin以外にインストールされている場合は、1行目のPerlのパスも変更します。

$pid_file_location = '/var/run/named/named.pid';　←PIDファイルの指定 $nameserver_location = 'localhost';　←DNSサーバの指定 $dig_program = '/usr/local/bin/dig';　←digコマンドのパス $named_program = '/usr/local/sbin/named -u named';　←namedの起動コマンド

　修正が完了したら、nanny.plを起動します。

# perl nanny.pl

注：# cdmod +x nanny.pl;./nanny.plでも可

　デフォルトでは、30秒ごとにチェックを行います。ただし、異常を検知してnamedを再起動した直後は、120秒間チェックを行いません。必要な場合は修正します。

（45行目） sleep 30;　←適宜修正

チェック間隔を調整する場合

（54行目） sleep 120;　←適宜修正

named再起動後の無チェック時間を修正する場合

性能測定ツールqueryperf

　第10回で、rndc statusやMRTGを使ってBIND 9の統計情報を収集する方法を紹介しました。こうして収集した統計情報を解析する際、サーバの上限をあらかじめ知っておくと、よりサーバの状態を把握しやすくなります。そこで、BIND 9のソースに同梱されているqueryperfを使用します。

　インストールは、BIND 9のソースディレクトリにあるcontrib/queryperfで行います。

# mysql bind_mysql # cd contrib/queryperf # ./configure # make

　make installは用意されていないため、必要に応じて手動で/usr/local/binなどにコピーします。

　次に、測定で使用するデータファイルを用意します。例（test.data）では、測定するDNSサーバ自身が持っているゾーン情報を対象にしています。

example.jp SOA example.jp NS pc1.example.jp

test.data 注：utils下のPythonスクリプトgen-data-queryperf.pyを使用し、ランダムなデータファイルを作成することもできます。詳細は「gen-data-queryperf.py -h」で確認できます。

　test.dataでは3レコードしか用意しませんでしたが、データ数が多いほど非キャッシュのデータに対する実パフォーマンスを測定することができます。

　データの用意ができたら、queryperfを以下のように実行します。測定対象はローカルサーバで、測定時間は10秒にしています。

# ./queryperf -d test.dat -s 127.0.0.1 -l 10 DNS Query Performance Testing Tool Version: $Id: queryperf.c,v 1.1.1.2.2.5 2003/05/12 07:07:13 marka Exp $ [Status] Processing input data [Status] Sending queries [Status] Testing complete Statistics:   Parse input file:     multiple times   Run time limit:       10 seconds   Ran through file:     33553 times   Queries sent:         100662 queries   Queries completed:    100662 queries   Queries lost:         0 queries   Percentage completed: 100.00%   Percentage lost:        0.00%   Started at:           Wed Apr 21 17:36:57 2004   Finished at:          Wed Apr 21 17:37:09 2004   Ran for:              11.874827 seconds   Queries per second:   8476.923495 qps

　10秒では信ぴょう性のあるデータが得られないため、実際には大きな値を指定する必要があります。とはいえ、たった10秒の間に10万662回のDNS問い合わせが行われていることが分かります。

　queryperfは、多大な負荷をDNSサーバに与えます。サービスインしているサーバで測定する場合は、注意が必要です。また測定サーバ自身が持っていないゾーン情報や再帰問い合わせを伴うテストも好ましくありません。

-d	データファイルの指定 （標準入力）
-s	DNSサーバの指定（localhost）
-p	DNSサーバのサービスポートの指定（53）
-q	未解決問い合わせの上限を指定（20）
-t	DNS問い合わせのタイムアウト秒を指定（5）
-l	テスト時間を秒で指定（なし）
-1	問い合わせを1回だけ実施する
-b	input／outputバッファのサイズをkbytesで指定（32k）
-e	EDNSを有効にする（無効）
-D	DNSSECを有効にする（無効）
-v	DNS問い合わせごとに詳細な情報を表示（off）
-h	ヘルプの表示
括弧内はデフォルト

　最後に、queryperfのオプションを紹介しておきます。

ソースディレクトリにあるそのほかのcontribute

　ソースディレクトリにあるcontributeとして、nanny.pl、queryperf、sdbを紹介しました。ほかにも以下のようなものがあります。

そのほかのTips

forwardersの利用

　BIND 9は、options{};セクション内でforwardersを指定することで、DNS問い合わせを回送することができます。例えば図1の構成では、部門DNSサーバA〜Cが直接外部へ抜けられなくても、外部へ抜けられるDNSが1台あれば、DNS問い合わせを回送することで各部門も名前解決が可能となります。

　各部門DNSサーバのnamed.confは以下のようになります。

options {         directory "/var/named";         pid-file "/var/run/named/named.pid";         （省略）         forwarders {基幹DNSサーバのアドレス;};　（1）         forward only;　（2） };

　（1）で、回送先DNSを指定します。この設定を行った場合でも、回送先DNSサーバのダウンなどでタイムアウト時間内に応答が得られなければ、通常の再帰問い合わせを開始します。しかし、タイムアウトが長いため、通常クライアント側はその結果を待ちません。また、図1のように直接外部へ抜けられない場合は、通常の再帰問い合わせができません。

　そこで（2）を追加し、（1）で指定したDNSサーバ以外への問い合わせを制止し、回送専用とします。回送サーバを用いることで、部門A?C内の各クライアントが直接基幹DNSを使うのに比べて負荷を分散できます。部門ごとにDNSを置くほど大規模な用途だけでなく、SOHOなど中小規模でもforwardersにプロバイダのDNSを指定することで、無駄な再帰問い合わせを減少させることができます。

　zone{};セクションでforwardersを指定した場合、そのゾーンのみ回送設定が有効になります。以下の場合、example.jpドメインに対する問い合わせは回送先DNSサーバに回送されます。

zone "example.jp" {         type forward;         forwarders {DNSサーバA;}; };

　逆に、特定ドメインのみ回送させない場合は、そのドメインのzone{};セクションを設けてforwardersの内容を無指定にします。

options {         （省略）         forwarders {回送先DNSサーバ;};         forward only; }; /* options{};セクションでforwardersが指定されているため、自身で管理しているゾーン情報以外の問い合わせを回送してしまう */ （省略） zone "example.com" {         type master;         file "example.zone";         forwarders {};  //forwardersの内容を無指定にする };

キャッシュをflushする

　第4回でキャッシュサーバの構築法を紹介しましたが、キャッシュをクリアする手段については言及しませんでした。

　DNSサーバを運用していると、他者（社）のDNS設定ミスのせいでキャッシュをクリアしなければならない事態に遭遇します。例えば、A社（example.jp）がDNSサーバをISP 1からISP 2に変更したとします。この場合、A社はISP 1とISP 2をしばらく並行運用し、その期間中はISP 1内のNSの設定をISP 2へ向けておく必要があります。というのは、NICへのNSの変更依頼が終わったからといってすぐに全世界のDNSがISP 2に向くわけではないからです。

　example.jpを一度でも引いたことのあるDNS（DNS-Aとします）は、NSレコードをISP 1としてキャッシュします。NICのNS登録が変更されても、DNS-AはISP 1へ問い合わせに行きます。その問い合わせの際にTTLが新たにカウントされるため、DNS-AはISP 1への問い合わせを無期限に続けます。このようなケースでは、新たなNSレコードが引けるようにするために世界中のDNSのキャッシュをクリアし、NSレコードを再取得してもらう必要があります（注）。

　DNSサーバのキャッシュ情報をクリアするには、次のようにrndcを利用します。

# rndc flush

注：rndcのインストール、使用方法については第5回参照。

　BIND 9.3では、特定ドメインのキャッシュのみ削除できます。

GUIでゾーン情報を操作する

　ゾーン情報やDNSサーバをGUI管理できるツールには、以下のようなものがあります。

digのオプション

　本連載では、DNSの動作チェックにdigコマンドを使用してきました。ここでは、これまでに紹介し切れなかったdigの表示・動作制御オプションについて補足します。

　digは、+optionで結果表示や動作の制御が行えます。以下に、使用頻度が高いオプションをまとめました。

+time=#	問い合わせのタイムアウトの秒数（5）
+domain=#	デフォルトドメインの指定
+[no]search	resolv.conf中のsearchリストを使用
+[no]defname	resolv.conf中のdomainリストを使用
+[no]recurse	再帰問い合わせを行う
+[no]fail	SERVFAILの際に次のサーバに問い合わせを行わない
+[no]cmd	dig実行時の引数を表示する
+[no]comments	「;; ADDITIONAL SECTION:」のようなコメント行を表示する
+[no]question	QUESTION SECTIONを表示する
+[no]answer	ANSWER SETIONを表示する
+[no]authority	AUTHORITY SECTIONを表示する
+[no]additional	ADDITIONAL SECTIONを表示する
+[no]stats	問い合わせにかかった時間などの統計情報を表示する
+[no]short	表示結果をごく簡単にする
+[no]nssearch	ゾーンに対し権威を持つすべてのDNSを検索
+[no]trace	ルートサーバからのトレース結果を表示
+[no]dnssec	DNSSECを使った問い合わせを行う
注：括弧内はデフォルト値。 [no]は、「no」を付けることで逆の効果が得られる。 　例：+recurse→+norecurse

　そのほかのオプションは-hオプションで確認できます。

Dynamic DNS環境における手動ゾーン更新

　第7回で、Dynamic DNS環境下における手動更新の併用について説明しました。Dynamic DNS環境では、ゾーンファイルを手動で修正する際にnamedを停止しておく必要があります。また、手動で更新した際はjnlファイルを削除し、その後namedを起動します。

　スレーブサーバを運用している場合は、jnlファイルを削除するとゾーン情報が全転送されます。BIND 9.3では、

# rndc freeze

および

# rndc unfreeze

を使うことにより、動的更新の受け付けを凍結・解除できます。これにより、namedを起動した状態でも手動によるゾーンファイルの修正を行うことが可能です。

DNS管理者の苦労はまだまだ続く

　1年以上にわたり続いた本連載も、今回が最終回です。

　南カリフォルニア大学で産声を上げたDNSも2004年で21年目を迎えます。いまではインターネットを支える基盤技術として欠かせない存在であり、第14回で紹介したENUMをはじめとする新しいアーキテクチャにも必要とされています。単なるホストの名前解決だけでなく、サービス名やサービスのプライオリティまでDNSで管理する方向にあるなど、DNSに求められる機能はますます増加しています。

　パフォーマンスやセキュリティに特化したさまざまなDNSサーバがリリースされていますが、このような過渡期においては良くも悪くもBINDがスタンダードであり、これからもそうであること予想されます。私自身、ここまで回を重ねて紹介できるほどBIND 9の話題に事欠かなかったことに驚愕しています。

　少しでも皆さんのお役に立っていることを願いつつ、本連載の結びとしたいと思います。読者の皆さん、ありがとうございました。