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

» 2003年11月18日 00時00分公開

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

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

スレーブサーバ側

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

options{



（省略）



    transfer-per-ns 2;　（1）

    transfers-in 10;　（2）

    max-transfer-time-in 120;　（3）

    tcp-clients 100;　（4）

    min-refresh-time 1800;　（5）

    max-refresh-time 86400;　（6）

    min-retry-time 900;　（7）

    max-retry-time 1800;　（8）



（省略）



};

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

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

server 192.168.10.10{

    transfer 2;

}

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

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

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

（3）ゾーン転送にかかる最大時間

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

zone "example.jp" {

    type slave;

    file "example.zone";

    max-transfer-time-in 120;

};

（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同様、ゾーン転送の再試行間隔を制御します。

マスターサーバ側

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

options{



（省略）



    transfers-out 10;　（1）

    max-transfer-time-out 120;　（2）

    tcp-clients 100;　（3）

    min-refresh-time 1800;　（4）

    max-refresh-time 86400;　（5）

    min-retry-time 900;　（6）

    max-retry-time 1800;　（7）



（省略）



};

（1）転送要求数の上限値

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

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

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

zone "example.jp" {

    type master;

    file "example.zone";

    max-transfer-time-out 120;

};

（3）TCP接続の最大数

（4）Refresh間隔の最小値

（5）Refresh間隔の最大値

（6）SOA中のRetryの最小値

（7）SOA中のRetryの最大値

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

$GENERATEの利用

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

（省略）

$ORIGIN example.jp.

host20      A   192.168.10.20

host21      A   192.168.10.21

host22      A   192.168.10.22

host23      A   192.168.10.23

host24      A   192.168.10.24

host25      A   192.168.10.25

host26      A   192.168.10.26

host27      A   192.168.10.27

（省略）

host250     A   192.168.10.250

（省略）

例：example.zoneファイル（A）

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

（省略）

$ORIGIN example.jp.

$GENERATE   20-250  host$   A   192.168.10.$

（省略）

例：example.zoneファイル（B）

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

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

（省略）

20.10.168.192.in-addr.arpa.         PTR     host20.example.jp.

21.10.168.192.in-addr.arpa.         PTR     host21.example.jp.

22.10.168.192.in-addr.arpa.         PTR     host22.example.jp.

23.10.168.192.in-addr.arpa.         PTR     host23.example.jp.

24.10.168.192.in-addr.arpa.         PTR     host24.example.jp.

25.10.168.192.in-addr.arpa.         PTR     host25.example.jp.

26.10.168.192.in-addr.arpa.         PTR     host26.example.jp.

27.10.168.192.in-addr.arpa.         PTR     host27.example.jp.

（省略）

250.10.168.192.in-addr.arpa.            PTR     host250.example.jp.

（省略）

例：example.revファイル（C）

（省略）

$GENERATE   20-250  $.10.168.192.in-addr.arpa.      PTR     host$.example.jp.

（省略）

例：example.revファイル（D）

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

設定ファイルの確認

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

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

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

●ゾーンファイルの確認

# /usr/local/sbin/named-checkzone ドメイン名ゾーンファイル

注：RPMなどでインストールしている場合は/usr/sbin/named-checkzone

# /usr/local/sbin/named-checkzone example.jp /var/named/example.zone

zone example.jp/IN: loaded serial 2003111103

OK

実行例

●named.confファイルの確認

# /usr/local/sbin/named-checkconf named.confファイルへのパス

注：RPMなどでインストールしている場合は/usr/sbin/named-checkconf

# /usr/local/sbin/named-checkconf /etc/named.conf

実行例

dnswalkの利用

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

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

$ wget http://www.visi.com/~barr/dnswalk/dnswalk-2.0.2.tar.gz

$ tar xvfz dnswalk-2.0.2.tar.gz

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

#!/usr/contrib/bin/perl

　　　　　↓

#!/usr/bin/perl

dnswalkファイル

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

$ wget http://www.cpan.org/modules/by-module/Net/Net-DNS-0.42.tar.gz

$ tar xvfz Net-DNS-0.42.tar.gz

$ cd Net-DNS-0.42

$ perl Makefile.PL

Do you want to enable these tests? [y] y　←「y」をタイプ



$ make

$ make test　←省略可（HMAC_MD5.pmがない場合エラーになることがあるがインストールをそのまま続ける）

$ sudo make install　←またはスーパユーザーで「# make install」

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

$ dnswalk ドメイン名.

注：必ずドメイン名に「.」を付けます。

$ dnswalk example.jp.

Checking example.jp.

Getting zone transfer of example.jp. from ns1.example.jp...done.

SOA=ns1.example.ne.jp       contact=postmaster.example.jp

0 failures, 0 warnings, 0 errors.

実行例


-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と見受けられるものもあります。

# dig @B.ROOT-SERVERS.NET. version.bind. TXT CHAOS

（省略）

;; ANSWER SECTION:

VERSION.BIND.           0       CH      TXT     "8.2.5-REL"

注：表示されているバージョンがそのままBINDのバージョンとは限りません。

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

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

「次回」へ

「実用 BIND 9で作るDNSサーバ」バックナンバー