突然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ファイルの指定 |
修正が完了したら、nanny.plを起動します。
# perl nanny.pl |
注:# cdmod +x nanny.pl;./nanny.plでも可 |
デフォルトでは、30秒ごとにチェックを行います。ただし、異常を検知してnamedを再起動した直後は、120秒間チェックを行いません。必要な場合は修正します。
(45行目) |
チェック間隔を調整する場合 |
(54行目) |
named再起動後の無チェック時間を修正する場合 |
第10回で、rndc statusやMRTGを使ってBIND 9の統計情報を収集する方法を紹介しました。こうして収集した統計情報を解析する際、サーバの上限をあらかじめ知っておくと、よりサーバの状態を把握しやすくなります。そこで、BIND 9のソースに同梱されているqueryperfを使用します。
インストールは、BIND 9のソースディレクトリにあるcontrib/queryperfで行います。
# mysql bind_mysql |
make installは用意されていないため、必要に応じて手動で/usr/local/binなどにコピーします。
次に、測定で使用するデータファイルを用意します。例(test.data)では、測定するDNSサーバ自身が持っているゾーン情報を対象にしています。
example.jp SOA |
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 |
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として、nanny.pl、queryperf、sdbを紹介しました。ほかにも以下のようなものがあります。
第11回で、dnswalkやnamed-checkconfを紹介しました。nslintも同様にnamed.confを読み込み、named.confで指定されているゾーンファイルの検証を行います。これを使うことによって、正引きに登録されているのに逆引きに登録されていないといった矛盾を検出できます。
インストールは以下の手順で行います。
# cd contrib/slint-2.1a3/ |
以上で、/usr/local/binにインストールされます。/etc/named.confを使用しているならオプションを指定する必要はありません。それ以外のnamed.confを使用している場合は、以下のようにnamed.confをオプションで明示します。
# nslint -c /path/named.conf |
DNSサーバの設定を確認するツールとして、ほかにも「www.DNSreport.com」(http://www.dnsreport.com/)のようなサービスも提供されています。
日本語をはじめとする国際化ドメインを扱うためのツール類がidnkitです。
参考:
今すぐ使える国際化ドメイン名の理論と実践
日本語ドメイン名をPunycodeに変換するには
カーネル2.2用のパッチです。カーネル2.2使用時のマルチスレッドプログラムのコアダンプを正常なものにします。パッチ適用後にカーネルの再構築が必要です。
BIND 4の設定ファイルnamed.bootをBIND 9のnamed.confに変換します。
BIND 9は、options{};セクション内でforwardersを指定することで、DNS問い合わせを回送することができます。例えば図1の構成では、部門DNSサーバA〜Cが直接外部へ抜けられなくても、外部へ抜けられるDNSが1台あれば、DNS問い合わせを回送することで各部門も名前解決が可能となります。
各部門DNSサーバのnamed.confは以下のようになります。
options { |
(1)で、回送先DNSを指定します。この設定を行った場合でも、回送先DNSサーバのダウンなどでタイムアウト時間内に応答が得られなければ、通常の再帰問い合わせを開始します。しかし、タイムアウトが長いため、通常クライアント側はその結果を待ちません。また、図1のように直接外部へ抜けられない場合は、通常の再帰問い合わせができません。
そこで(2)を追加し、(1)で指定したDNSサーバ以外への問い合わせを制止し、回送専用とします。回送サーバを用いることで、部門A?C内の各クライアントが直接基幹DNSを使うのに比べて負荷を分散できます。部門ごとにDNSを置くほど大規模な用途だけでなく、SOHOなど中小規模でもforwardersにプロバイダのDNSを指定することで、無駄な再帰問い合わせを減少させることができます。
zone{};セクションでforwardersを指定した場合、そのゾーンのみ回送設定が有効になります。以下の場合、example.jpドメインに対する問い合わせは回送先DNSサーバに回送されます。
zone "example.jp" { |
逆に、特定ドメインのみ回送させない場合は、そのドメインのzone{};セクションを設けてforwardersの内容を無指定にします。
options { |
第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では、特定ドメインのキャッシュのみ削除できます。
ゾーン情報やDNSサーバをGUI管理できるツールには、以下のようなものがあります。
DNSだけでなく、Linuxサーバの設定や管理に必要な操作の多くをWebを通して行うことができます。ディストリビューションによっては、デフォルトでインストールされている場合もあります。@ITでもLinux Tipsで何度か取り上げているので、インストールや詳細については以下を参照してください。
Linux Tips
Webminとは
Webminをインストールするには
MySQL sdbドライバを導入したゾーンのみ管理可能です。Webminと同様、操作はWebを通して行います。なお、Apacheなどのhttpdが必要になります。
ゾーン情報をMySQLで管理し、BIND起動時にゾーンファイルやnamed.confファイルを作成します。同梱のWebアプリケーションでMySQL内のデータを編集できます。
本連載では、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オプションで確認できます。
第7回で、Dynamic DNS環境下における手動更新の併用について説明しました。Dynamic DNS環境では、ゾーンファイルを手動で修正する際にnamedを停止しておく必要があります。また、手動で更新した際はjnlファイルを削除し、その後namedを起動します。
スレーブサーバを運用している場合は、jnlファイルを削除するとゾーン情報が全転送されます。BIND 9.3では、
# rndc freeze |
および
# rndc unfreeze |
を使うことにより、動的更新の受け付けを凍結・解除できます。これにより、namedを起動した状態でも手動によるゾーンファイルの修正を行うことが可能です。
1年以上にわたり続いた本連載も、今回が最終回です。
南カリフォルニア大学で産声を上げたDNSも2004年で21年目を迎えます。いまではインターネットを支える基盤技術として欠かせない存在であり、第14回で紹介したENUMをはじめとする新しいアーキテクチャにも必要とされています。単なるホストの名前解決だけでなく、サービス名やサービスのプライオリティまでDNSで管理する方向にあるなど、DNSに求められる機能はますます増加しています。
パフォーマンスやセキュリティに特化したさまざまなDNSサーバがリリースされていますが、このような過渡期においては良くも悪くもBINDがスタンダードであり、これからもそうであること予想されます。私自身、ここまで回を重ねて紹介できるほどBIND 9の話題に事欠かなかったことに驚愕しています。
少しでも皆さんのお役に立っていることを願いつつ、本連載の結びとしたいと思います。読者の皆さん、ありがとうございました。
Copyright © ITmedia, Inc. All Rights Reserved.