メール／Webサーバを効率的に動かすゾーン設定：実用 BIND 9で作るDNSサーバ（3）（1/2 ページ）

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

[鶴長鎮一，＠IT]

　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」でアクセスしてもらいたいと考えています。このような場合、最初に思い付くのは次のようなゾーンファイルでしょう。

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

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

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

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

　これならば、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からでもインターネットからでも同じホスト名でアクセスできるようにしたいものです。そのような場合は、次のようなゾーンファイルを思い付くはずです。

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

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

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

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

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

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

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

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

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

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

注：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ファイルにも変更を加える必要があります。

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

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

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

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

（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でも同じように使えないものかと、次のようなゾーンファイルを用意したとします。

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

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

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

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

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

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

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

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

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

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

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

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