(1/2)メールサーバやWebサーバとDNSは密接につながっている。ゾーンファイルの書き方1つで、それらを効率化することも可能だ。今回は、これらのサーバとBINDの関係に着目して、ゾーン設定の妙を学んでいただきたい。すべての基礎、マスター・ゾーンサーバの設定参照)の設定にあります。これらのファイルの記述次第で、あなたのサイトはより快適なものにも、手を煩わせるものにもなり得ます。今回から数回にわたり、これらの設定ファイルを詳しく見ていきます。今回はその第1弾として、メールやWebサーバを抱えたサイトのケースを紹介しましょう。9とWebサーバの関係という視点から、ゾーンファイルの設定を見ていきましょう。Name)はホスト名に別名を付けるレコードで、使い方によってはホスト情報の管理を効率化します。使用されるのは次のような場合です。あなたは、「host1.example.jp」サーバを用意しました。この1台でDNSやWeb、FTPサーバを立ち上げますが、ゆくゆくはそれぞれのサービス専用のサーバを用意するつもりです。サービス利用者には「http://host1.example.jp」ではなくて「http://www.example.jp」でアクセスしてもらいたいと考えています。このような場合、最初に思い付くのは次のようなゾーンファイルでしょう。(3)ゾーンファイル1(1)(2)(3)ともに、同じアドレスに対してAレコードを複数指定しています。しても、ほとんどの場合はうまく動作します。host1のIPアドレスを変更したり、host1に障害が発生して別のIPアドレスで置き換えるような場合は、3行とも変更する必要が発生します。BINDでは、こうした管理を効率化するためにCNAMEを利用し、以下のようにゾーンファイルを置き換えることができます。(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を備えたサーバやルータなどの機器を「マルチホームホスト」と呼ぶことがあります。複数のNICを介したアクセスしかし、LANからでもインターネットからでも同じホスト名でアクセスできるようにしたいものです。そのような場合は、次のようなゾーンファイルを思い付くはずです。←eth1のアドレスゾーンファイル3(部分)こうすることで、BINDはwww.example.jpに対して2つのIPアドレスを返します。(2)(省略)しかし、別のクライアントからwww.example.jpを引くと、返されるIPアドレスの順序が異なっています。robin)または「DNSラウンドロビン」と呼ばれる機能で、複数のアドレスを受け取ったクライアントは、最初に受け取ったアドレスのみを目的のホストのIPアドレスとして解釈します。www.example.jp」を実行した場合、2つのIPアドレスに同時にpingを行うのではなく、ラウンドロビンによって受け取った最初のアドレスのみを使用します。実際、それは可能です。次のようなサーバ構成を考えてみましょう。ラウンドロビンを利用した負荷分散。www.example.jpのDNS問い合わせに対して、ラウンドロビンでいずれかのIPアドレスを受け取るこのようなサイトでは、次のようなゾーンファイルを用意します。その際、各レコードのTTLを明示的に小さな値にしておくと、さらに分散効果が期待できます。192.168.10.12ゾーンファイル4(部分)。TTLに1h=1時間を指定(注)注:TTLは、単位を省略すると「秒」が単位として適用されます。86400」は86400秒になります。直感的な分、時、日、週も指定可能です。10w=10週間ラウンドロビンを利用すると、クライアントが名前解決を行うごとに違うアドレスが返されるため、結果的にアクセスするサーバ(この場合はWeb)を分散させることができます。注意しておくこともあります。「処理能力が高いサーバには高頻度でアクセスしてもらい、処理能力が低いサーバにはあまりアクセスしてもらいたくない」というように、サーバの処理能力に合わせてアクセス頻度のウェイトを設定することは、ラウンドロビンではできません。「障害が発生したサーバのアドレスは返さない」といった耐故障性(フォールトトレランス)も備えていません。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到達性が確保されているなら、どのインターフェイスに対し接続を試みてもパフォーマンスに大きな影響を与えることはないでしょう。クライアントから近い方のアドレスを返せるなら、それに越したことはありません。次のようなネットワークを考えます。拠点をまたいでも、それぞれの拠点にあるサーバにfileserver.example.jpでアクセスできるようにしたいこの場合、拠点Aにいるときはfileserver.example.jpで返ってくるアドレスに192.168.10.10を、拠点Bにいるときは192.168.20.10を期待したいものです。9なら「アドレスの順序づけ」でそれが可能になります。そのためには、ゾーンファイルだけでなくnamed.confファイルにも変更を加える必要があります。ゾーンファイルから見ていきましょう。192.168.20.10ゾーンファイル5(部分)named.confは、options{}センテンスに次のように追加します。「マルチホームホストと負荷分散」の例では、1つのホスト名に対して複数のAレコードを用意しました。CNAMEでも同じように使えないものかと、次のようなゾーンファイルを用意したとします。192.168.10.11ゾーンファイル6(部分)旧来のBINDでは、こうした手法で負荷分散を実現していましたが、現在のバージョンではこの記述は認められていないので注意が必要です。9.2.1ではエラーとなります。ほかにも、CNAMEには次のような制限があります。●資源レコードにCNAMEを使うことはできない次のような記述はエラーになります。192.168.10.10ゾーンファイル7(NSレコードに別名ホスト名が指定されている)ゾーンファイル7は、次のように修正する必要があります。192.168.10.10ゾーンファイル8(NSレコードに正規ホスト名を指定)同じように、SOA/MX/A/PTR/TXTなど、CNAME以外の資源レコードには別名ホストを指定しないようにします。MXレコードでのCNAME使用の不具合については、後半で解説します。●CNAMEからCNAMEへのチェーンはほどほどに次のようなゾーンファイルはどうでしょうか。192.168.10.10ゾーンファイル9(別名ホストの先に、さらに別名ホストが指定されている)この記述はエラーにはなりませんが、www1.example.jpのIPアドレスを得るために、ゾーンファイルを5回も参照することになり、非常に非効率的です。明確に使用が禁止されているわけではありませんが、推奨もされていません。障害復旧時の一時的な措置など、やむを得ないときに使用するのみにとどめましょう。ループになるようなCNAMEの設定は、いうまでもなく厳禁です。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。