第3回　メール／Webサーバを効率的に動かすゾーン設定

メールサーバやWebサーバとDNSは密接につながっている。ゾーンファイルの書き方1つで、それらを効率化することも可能だ。今回は、これらのサーバとBINDの関係に着目して、ゾーン設定の妙を学んでいただきたい。（編集局）

鶴長 鎮一
2003/2/15

　BIND 9運用の要はnamed.confファイルと各ゾーンファイル（第2回 すべての基礎、マスター・ゾーンサーバの設定参照）の設定にあります。これらのファイルの記述次第で、あなたのサイトはより快適なものにも、手を煩わせるものにもなり得ます。

　今回から数回にわたり、これらの設定ファイルを詳しく見ていきます。今回はその第1弾として、メールやWebサーバを抱えたサイトのケースを紹介しましょう。

BIND 9とWebサーバ

　最初に、BIND 9とWebサーバの関係という視点から、ゾーンファイルの設定を見ていきましょう。

■CNAMEの利用

　CNAME（Canonical Name）はホスト名に別名を付けるレコードで、使い方によってはホスト情報の管理を効率化します。よく使用されるのは次のような場合です。

　あなたは、「host1.example.jp」サーバを用意しました。まずこの1台でDNSやWeb、FTPサーバを立ち上げますが、ゆくゆくはそれぞれのサービス専用のサーバを用意するつもりです。また、サービス利用者には「http://host1.example.jp」ではなくて「http://www.example.jp」でアクセスしてもらいたいと考えています。このような場合、最初に思い付くのは次のようなゾーンファイルでしょう。

$TTL 86400 @            IN      SOA dns.example.jp. root.example.jp. (                      2002122001 ; serial                      3600       ; refresh 1hr                      900        ; retry 15min                      604800     ; expire 1w                      86400      ; min 24hr )              IN      NS     host1.example.jp. host1        IN      A      192.168.10.10　（1） www          IN      A      192.168.10.10　（2） ftp          IN      A      192.168.10.10　（3）

ゾーンファイル1

　（1）（2）（3）ともに、同じアドレスに対してAレコードを複数指定しています。こうしても、ほとんどの場合はうまく動作します。ただし、host1のIPアドレスを変更したり、host1に障害が発生して別のIPアドレスで置き換えるような場合は、3行とも変更する必要が発生します。

　BINDでは、こうした管理を効率化するためにCNAMEを利用し、以下のようにゾーンファイルを置き換えることができます。

host1        IN      A      192.168.10.10　（1） www          IN      CNAME  host1.example.jp　（2） ftp          IN      CNAME  host1.example.jp　（3）

ゾーンファイル2（部分）

　これならば、host1のIPアドレスを変更した際は、（1）を書き換えるだけで済みます。

　CNAMEは便利ですが、小規模なサイトであれば、CNAMEよりも複数のAレコードを用いた方が問い合わせの負荷を減らすことができます。あるクライアントがwww.example.jpを問い合わせてきたとき、それがCNAMEの場合はいったん正規のホスト名（この場合はhost1.example.jp）を調べ、その後正規ホストのIPアドレスをクライアントに返します。つまり、ゾーンファイルを2回参照することになります。もし、www.example.jpをAレコードで定義していれば、ゾーンファイルの参照は1回で済みます。

■マルチホームホストと負荷分散

　先ほどのゾーンファイル1は、

ホスト名：実アドレス＝多数：1

でしたが、

ホスト名：実アドレス＝1：多数

のような場合も想定されるはずです。例えば、複数のNICを装着した図1のようなLinuxサーバでは、それぞれのLANインターフェイスに異なるアドレスが割り当てられます。このように、複数のNICを備えたサーバやルータなどの機器を「マルチホームホスト」と呼ぶことがあります。

図1　複数のNICを介したアクセス

　しかし、LANからでもインターネットからでも同じホスト名でアクセスできるようにしたいものです。そのような場合は、次のようなゾーンファイルを思い付くはずです。

www          IN      A      192.168.10.10　←eth0のアドレス www          IN      A      192.168.20.10　←eth1のアドレス

ゾーンファイル3（部分）

　こうすることで、BINDはwww.example.jpに対して2つのIPアドレスを返します。

$ /usr/local/bin/dig @127.0.0.1 www.example.jp （省略） ;; ANSWER SECTION: www.example.jp.   38400      IN      A       192.168.10.10　（1） www.example.jp.   38400      IN      A       192.168.20.10　（2） （省略）

　しかし、別のクライアントからwww.example.jpを引くと、返されるIPアドレスの順序が異なっています。

$ /usr/local/bin/dig @127.0.0.1 www.example.jp （省略） ;; ANSWER SECTION: www.example.jp.   38400      IN      A       192.168.20.10　（1） www.example.jp.   38400      IN      A       192.168.10.10　（2） （省略）

（1）と（2）が入れ替わっている

　これは、アドレスが返される順序がその都度変わることから「ラウンドロビン」（round robin）または「DNSラウンドロビン」と呼ばれる機能で、複数のアドレスを受け取ったクライアントは、最初に受け取ったアドレスのみを目的のホストのIPアドレスとして解釈します。例えば、「ping www.example.jp」を実行した場合、2つのIPアドレスに同時にpingを行うのではなく、ラウンドロビンによって受け取った最初のアドレスのみを使用します。

　返されるIPアドレスの順序がその都度変わるのならば、サーバの負荷分散に使えるのでは？ と考えるでしょう。実際、それは可能です。次のようなサーバ構成を考えてみましょう。

図2　ラウンドロビンを利用した負荷分散。www.example.jpのDNS問い合わせに対して、ラウンドロビンでいずれかのIPアドレスを受け取る

　このようなサイトでは、次のようなゾーンファイルを用意します。その際、各レコードのTTLを明示的に小さな値にしておくと、さらに分散効果が期待できます。

www       1h   IN      A      192.168.10.10 www       1h   IN      A      192.168.10.11 www       1h   IN      A      192.168.10.12

ゾーンファイル4（部分）。TTLに1h＝1時間を指定（注）

注：TTLは、単位を省略すると「秒」が単位として適用されます。例えば、「$TTL 86400」は86400秒になります。しかし、より直感的な分、時、日、週も指定可能です。 $TTL 30m ＝ 30分 $TTL 10h ＝ 10時間 $TTL 10d ＝ 10日間 $TTL 10w ＝ 10週間

　ラウンドロビンを利用すると、クライアントが名前解決を行うごとに違うアドレスが返されるため、結果的にアクセスするサーバ（この場合はWeb）を分散させることができます。

　ただし、注意しておくこともあります。「処理能力が高いサーバには高頻度でアクセスしてもらい、処理能力が低いサーバにはあまりアクセスしてもらいたくない」というように、サーバの処理能力に合わせてアクセス頻度のウェイトを設定することは、ラウンドロビンではできません。当然、「障害が発生したサーバのアドレスは返さない」といった耐故障性（フォールトトレランス）も備えていません。

　こうした要望に応えるため、BIND 9.2.1ではSRVレコードが採用されています。SRVレコードを使用することで、各サーバにウェイトを設定することができ、さらにサービスが類推しやすいホスト名（ftp://ftp.example.jpやhttp://www.example.jpなど）を割り当てることが可能です。ただし、クライアント側でもSRVレコードを解釈できる必要があるため、現時点では広く使えるという状況ではありません。しかしながら、将来への布石として、SRVレコードについては回を改めて本連載で紹介したいと思います。

■マルチホームホストとアドレスの順序づけ

　先ほど紹介した図1を再考してみましょう。

　ゾーンファイル3では、アドレス問い合わせの際にどちらのNICのアドレスが返されるかはそのとき次第です。例えば、ローカルのネットワークからwwwにアクセスする際はeth1側、外部からのアクセスにはeth0側のアドレスを返すようにはなっていません。つまり、ラウンドロビンに徹しています。

　確かに、Webサーバであればeth0、eth1両方でIP到達性が確保されているなら、どのインターフェイスに対し接続を試みてもパフォーマンスに大きな影響を与えることはないでしょう。しかし、クライアントから近い方のアドレスを返せるなら、それに越したことはありません。例えば、次のようなネットワークを考えます。

図3　拠点をまたいでも、それぞれの拠点にあるサーバにfileserver.example.jpでアクセスできるようにしたい

　この場合、拠点Aにいるときはfileserver.example.jpで返ってくるアドレスに192.168.10.10を、拠点Bにいるときは192.168.20.10を期待したいものです。BIND 9なら「アドレスの順序づけ」でそれが可能になります。そのためには、ゾーンファイルだけでなくnamed.confファイルにも変更を加える必要があります。

　まずはゾーンファイルから見ていきましょう。

fileserver       1h   IN      A      192.168.10.10 fileserver       1h   IN      A      192.168.20.10

ゾーンファイル5（部分）

　named.confは、options{}センテンスに次のように追加します。

options {         directory "/var/named";         pid-file "/var/run/named/named.pid";         recursion yes;         sortlist {                 { 192.168.10.0/24; 192.168.10.0/24;};　（1）                 { 192.168.20.0/24; 192.168.20.0/24;};　（2）         }; };

named.conf（部分）

（1）　クライアントが192.168.10.0/24にあるときは、192.168.10.0/24のアドレスを優先して返答する （2）　クライアントが192.168.20.0/24にあるときは、192.168.20.0/24のアドレスを優先して返答する

■やってはいけないCNAMEの使用方法

　「マルチホームホストと負荷分散」の例では、1つのホスト名に対して複数のAレコードを用意しました。CNAMEでも同じように使えないものかと、次のようなゾーンファイルを用意したとします。

www          IN      CNAME  host1.example.jp www          IN      CNAME  host2.example.jp host1        IN      A      192.168.10.10 host2        IN      A      192.168.10.11

ゾーンファイル6（部分）

　旧来のBINDでは、こうした手法で負荷分散を実現していましたが、現在のバージョンではこの記述は認められていないので注意が必要です。このゾーンファイルは、BIND 9.2.1ではエラーとなります。ほかにも、CNAMEには次のような制限があります。

●資源レコードにCNAMEを使うことはできない

　次のような記述はエラーになります。

IN      NS     dns.example.jp. dns         IN      CNAME  host1.example.jp. host1       IN      A      192.168.10.10

ゾーンファイル7（NSレコードに別名ホスト名が指定されている）

　ゾーンファイル7は、次のように修正する必要があります。

IN      NS     host1.example.jp. host1       IN      A      192.168.10.10

ゾーンファイル8（NSレコードに正規ホスト名を指定）

　同じように、SOA／MX／A／PTR／TXTなど、CNAME以外の資源レコードには別名ホストを指定しないようにします。MXレコードでのCNAME使用の不具合については、後半で解説します。

●CNAMEからCNAMEへのチェーンはほどほどに

　次のようなゾーンファイルはどうでしょうか。

www1          IN      CNAME  www2.example.jp www2          IN      CNAME  www3.example.jp www3          IN      CNAME  www4.example.jp www4          IN      CNAME  www5.example.jp www5          IN      A      192.168.10.10

ゾーンファイル9（別名ホストの先に、さらに別名ホストが指定されている）

　この記述はエラーにはなりませんが、www1.example.jpのIPアドレスを得るために、ゾーンファイルを5回も参照することになり、非常に非効率的です。明確に使用が禁止されているわけではありませんが、推奨もされていません。障害復旧時の一時的な措置など、やむを得ないときに使用するのみにとどめましょう。ループになるようなCNAMEの設定は、いうまでもなく厳禁です。

1/2

Index 実用 BIND 9で作るDNSサーバ 　第3回 メール／Webサーバを効率的に動かすゾーン設定

Page 1 BIND 9とWebサーバ 　CNAMEの利用 　マルチホームホストと負荷分散 　マルチホームホストとアドレスの順序づけ 　やってはいけないCNAMEの使用方法 　 Page 2 BIND 9とメールサーバ 　MXについて 　MXレコードによるフォールトトレランスと負荷分散 　MXレコードのCNAME

連載 実用 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系列の新機能、インストール方法、国際化の現状を解説する
	more

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

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