検索
連載

BIND 9のチューニングと大規模運用実用 BIND 9で作るDNSサーバ(11)(2/2 ページ)

今回は、大規模運用において特に必要となるBIND 9のチューニング方法を中心に紹介する。また、設定ファイルをチェックするためのツールにも触れる。(編集局)

Share
Tweet
LINE
Hatena
前のページへ |       

ゾーン転送のチューニング

 マスター/スレーブサーバ間で行われるゾーン転送は、クエリー問い合わせよりもBINDに大きな負荷を強要します。そのため、ゾーン転送に多くのリソースが使用されないように、デフォルトでは低い値が設定されています。数百ものゾーンファイルを扱うサイトではより効率を上げるために、ゾーン転送に関連するパラメータの修正を行う必要があります。

スレーブサーバ側

 ゾーン情報をマスターからコピーするスレーブ側では、次のような設定が有効です。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

(1)スレーブ→マスターの転送要求数の最大値

 マスターサーバへの転送要求数の上限を設定します。デフォルトは2です。以下のようにマスターサーバごとに指定することも可能で、options{};中の指定よりも優先されます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 同時ゾーン転送数がtransfer-per-nsに達した場合でも、完了次第次のゾーン転送が開始されるようにスケジュールされます。

(2)マスターを複数持つスレーブサーバのゾーン転送要求総数の最大値

 マスターサーバを複数持つスレーブサーバの場合、単純にtransfer-per-nsを増やしても、同時に行われるゾーン転送数がtransfer-per-ns×マスターサーバ数にならない場合があります。その場合、transfers-inでトータルのゾーン転送数を上げる必要があります。デフォルトでは同時10転送に制限されています。

(3)ゾーン転送にかかる最大時間

 マスターからのゾーン情報のダウンロードに2時間以上かかる場合は、max-transfer-time-inで分数を指定します。デフォルトは120(2時間)です。ゾーンファイルごとに指定することもできます。この場合、zone{};中の指定が優先されます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

(4)TCP接続の最大数

 ゾーン転送はUDPではなくTCPが使用されます。transfer-per-nsやmax-transfer-time-inの値を大きくし、同時ゾーン転送数が100を超える場合は、大きくする必要があります。デフォルトは100です。

(5)Refresh間隔の最小値

(6)Refresh間隔の最大値

 ゾーン情報のRefresh間隔を制御します。SOA Refreshの最大値を小さくして特定のゾーン情報の伝播が遅れることを防いだり、あるゾーン情報のRefreshの値が小さいために頻繁なゾーン転送が行われ、ほかのゾーン情報の転送に影響を与える事態を防ぐために最小値を設定するなどします。

(7)SOA中のRetryの最小値

(8)SOA中のRetryの最大値SOA中のRetryの最大値

 Refresh同様、ゾーン転送の再試行間隔を制御します。

マスターサーバ側

 スレーブサーバ側の制限を拡張しても、マスターサーバ側が拡張されてないと十分なパフォーマンスが得られません。そこで、マスター側でも各制限を拡張します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

(1)転送要求数の上限値

 転送要求数の最大値を設定します。スレーブからのゾーン転送要求に無制限に応じてマスターサーバのリソースが食いつぶされないようにするには低めの値に設定し、同時転送数を上げてスレーブへのゾーン転送効率を上げるにはより大きな値を指定します。その際、スレーブサーバの項で触れたようにスレーブ側の制限も調整する必要があります。デフォルトは10です。

(2)ゾーン転送にかかる最大時間の制限

 スレーブへのゾーン情報のダウンロードに2時間以上かかる場合は、max-transfer-time-outで分数を指定します。デフォルトは120(2時間)です。ゾーンファイルごとに指定することもできます。この場合、zone{};中の指定が優先されます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

(3)TCP接続の最大数

(4)Refresh間隔の最小値

(5)Refresh間隔の最大値

(6)SOA中のRetryの最小値

(7)SOA中のRetryの最大値

 これらについては、スレーブサーバの項を参照してください。

$GENERATEの利用

 グローバルアドレスをクラスC単位で所有している方は少ないと思いますが、プライベートアドレスを社内向けDNSで引けるようにしている方は多いと思います。多量のアドレスを登録する場合、しばしば連番を伴うホスト名が利用されます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 上記のようにIPアドレスとホスト名に関連性がある場合は、次のように$GENERATEを用いることが可能です。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 $GENERATEを用いると、ゾーンファイル読み込み時にexample.zoneファイル(A)のように展開されます。

 $GENERATEの恩恵は、むしろ逆引きゾーンファイルの方が大きいでしょう。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 example.revファイル(D)のように記述した場合、named起動時にexample.revファイル(C)のように展開されます。ゾーンファイル読み込み時にファイルの展開が行われるためリソースの節約にはなりませんが、人の手で作成するよりもタイプミスを低減でき、可読性も良くなります。

設定ファイルの確認

 named.confやゾーンファイルが複雑になるほど、ミスタイプや矛盾を含んだ設定が発生しやすくなります。named起動時のログを確認することでもエラーを確認できますが、BIND 9のnamed-checkzoneをはじめとするチェックツールを利用することもできます。

BIND 9ユーティリティの利用

 BIND 9にはゾーンの整合性をチェックするnamed-checkzoneと、named.confファイルをチェックするnamed-checkconfが含まれています。

●ゾーンファイルの確認

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

●named.confファイルの確認

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

dnswalkの利用

 dnswalk(http://www.visi.com/~barr/dnswalk/)を利用すれば、より詳細な検証を行うことができます。dnswalkはNet::DNSモジュールを使ったPerlスクリプトで、別途Net::DNSモジュールのインストールが必要です。

 まず、dnswalk-2.0.2.tar.gzをダウンロードして展開します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 ファイルを展開したら、dnswalkファイルを以下のように修正します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 続いて、Net::DNSモジュールをインストールします。Net-DNS-0.42.tar.gzをCPAN(http://www.cpan.org/modules/by-module/Net/)から入手し、以下のように作業します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 インストールが完了したら、ゾーンファイルを検査します。dnswalkはローカルファイルを直接走査せず、ゾーン転送を用いてゾーンファイルを取得します。そのため、dnswalkを動かすサーバをゾーン転送可能クライアントとしてマスターサーバに登録しておく必要があります。スレーブサーバ上でdnswalkを動かせば、その手間は必要ありません。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

-r サブドメインまで再帰的に検査を実施
-i レコード中の無効文字のチェックを無視
-a 重複するAレコードに警告を出す
-d デバッグモード
-m ゾーン情報が修正された場合のみチェックを実施(dnswalkが以前に実行された場合のみ有効)
-F Aレコードチェックする際、そのIPアドレスに対する逆引きを調べてミスマッチを検出する
-l lame情報のチェック
dnswalkに指定可能なオプション

コラム BIND 8 or BIND 9

 BIND 9には先進的な機能が盛り込まれている分、パフォーマンスでBIND 8に劣ります。そこで、パフォーマンスを重視する場合はBIND 8を採用するケースがあります。rootサーバの中にはBIND 8と見受けられるものもあります。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 しかし、一般的な用途ではBIND 9でも十分なパフォーマンスを実現しています。必要なパラメータもあらかじめ適当なものが指定されているので、BIND 9を使用することをお勧めします。



 以上、大規模運用や高効率化のためのチューニング運用手法を紹介しました。BIND 9では、無駄にリソースを消費しないように足かせのように低めの値(ただし通常運用では十分)がデフォルトで指定されている場合があります。高効率を求めるあまり極端に偏った設定にならないよう、上限値を変更する際は少しずつ試しながら上げるようにしましょう。


Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       
ページトップに戻る