最終回　BIND 9を徹底活用するためのTips集

 鶴長 鎮一
2004/5/15

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を紹介しました。ほかにも以下のようなものがあります。

  • nslint
    第11回で、dnswalkやnamed-checkconfを紹介しました。nslintも同様にnamed.confを読み込み、named.confで指定されているゾーンファイルの検証を行います。これを使うことによって、正引きに登録されているのに逆引きに登録されていないといった矛盾を検出できます。

    インストールは以下の手順で行います。

    # cd contrib/slint-2.1a3/
    # ./configure
    # make
    # make install

    以上で、/usr/local/binにインストールされます。/etc/named.confを使用しているならオプションを指定する必要はありません。それ以外のnamed.confを使用している場合は、以下のようにnamed.confをオプションで明示します。

    # nslint -c /path/named.conf

    DNSサーバの設定を確認するツールとして、ほかにも「www.DNSreport.com」（http://www.dnsreport.com/）のようなサービスも提供されています。

  • idnkit

    日本語をはじめとする国際化ドメインを扱うためのツール類がidnkitです。

    　 参考：
    　 　 今すぐ使える国際化ドメイン名の理論と実践
    　 　 日本語ドメイン名をPunycodeに変換するには

  • linux
    カーネル2.2用のパッチです。カーネル2.2使用時のマルチスレッドプログラムのコアダンプを正常なものにします。パッチ適用後にカーネルの再構築が必要です。

  • named-bootconf
    BIND 4の設定ファイルnamed.bootをBIND 9のnamed.confに変換します。

そのほかのTips

■forwardersの利用

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

図1　想定環境

　各部門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レコードを再取得してもらう必要があります（注）。

注：ISP 1の旧DNSを停止すれば、TTLの若返りが発生しないためTTL切れとともにISP 2への問い合わせに切り替わります。

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

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

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

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

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

  • Webmin（http://www.webmin.com/）
    DNSだけでなく、Linuxサーバの設定や管理に必要な操作の多くをWebを通して行うことができます。ディストリビューションによっては、デフォルトでインストールされている場合もあります。＠ITでもLinux Tipsで何度か取り上げているので、インストールや詳細については以下を参照してください。

    　 Linux Tips
    　 　 Webminとは
    　 　 Webminをインストールするには

  • dnSQLpanel（http://dnsqlpanel.sourceforge.net/）
    MySQL sdbドライバを導入したゾーンのみ管理可能です。Webminと同様、操作はWebを通して行います。なお、Apacheなどのhttpdが必要になります。

  • dnsadmin（http://www.inter7.com/dnsadmin.html）
    ゾーン情報をMySQLで管理し、BIND起動時にゾーンファイルやnamed.confファイルを作成します。同梱のWebアプリケーションでMySQL内のデータを編集できます。

■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の話題に事欠かなかったことに驚愕しています。

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

注：BIND 9に関する質問は、引き続きLinux Square会議室にお寄せください。時間がある限り回答させていただきたいと思います。

2/2

Index
実用 BIND 9で作るDNSサーバ
　最終回　BIND 9を徹底活用するためのTips集
　 Page 1
ゾーンデータをRDBMSで管理
　sdbとは
　MySQL用sdbドライバのインストール
　sdbの設定
　sdbの動作チェック
　 Page 2
BIND標準ツールの活用
　サービスダウン時の自動回復
　性能測定ツールqueryperf
　ソースディレクトリにあるそのほかのcontribute
そのほかのTips
　forwardersの利用
　キャッシュをflushする
　GUIでゾーン情報を操作する
　digのオプション
　Dynamic DNS環境における手動ゾーン更新
DNS管理者の苦労はまだまだ続く

連載 実用 BIND 9で作るDNSサーバ

　Linux Squareフォーラム サーバ構築・運用関連記事
連載：Heartbeatでかんたんクラスタリング（連載中）
オープンソースソフトウェアの「Heartbeat」を使ってHAクラスタを実現し、サービスを「落とさない」仕組みを実現します
特集：Apache 2.2でWebサイトをパフォーマンスアップ！
最新安定版Apache 2.2は、何が変わったのか？ 最新のApacheを新機能の使い方とともに解説する
連載：実用 Apache 2.0運用・管理術（全8回）
本連載では、Apache 2.0の運用や管理方法を解説する。まず必須設定と基本的なセキュリティ対策を行い今後の運用に備える
連載：実用 BIND 9で作るDNSサーバ（全15回）
本連載では、BIND 9の構築／運用方法を解説していく。実際に役立つことを目的に、セキュリティや大規模運用などのテーマを取り上げていく
連載：実用qmailサーバ運用・管理術（全14回）
本連載を通して、qmailによるメールサーバの高度な構築・運用・管理術を紹介。SPAM対策やML管理からサーバでのウイルスチェックなどまで
特集：Samba 3.0の全貌 改訂版
Samba 3.0リリースから8カ月。ここであらためて、Samba 3.0系列の新機能、インストール方法、国際化の現状を解説する

MONOist組み込み開発フォーラムの中から、Linux関連記事を紹介します

TechTargetジャパン

Linux Square フォーラム 新着記事

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード

＠IT 新着記事

キャリアアップ



- PR -
＠IT Sepcial
→ ＠IT Special ヘ

イベントカレンダー

PickUpイベント

- PR -
もっと見る
- PR -

お勧め求人情報

ホワイトペーパー（TechTargetジャパン）

＠IT Sepcial
→ ＠IT Special ヘ
ソリューションFLASH