9の相互運用を考えてみましょう。メール送信とDNSuser-b@example-b.jpにメールが送信される仕組みを見てみましょう。Bさんあてのメールを受け取ったメールサーバmail-aは、example-b.jpドメインに対するメール送信先をDNSサーバdns-aを使って検索します。dns-aはドメインツリーをたどり、example-b.jpドメインをつかさどるDNSサーバdns-bにたどり着き、example-b.jpドメインに対するメール送信先を問い合わせます。dns-bはゾーンファイル中のMXレコードに登録されているホスト名を返します。dns-aは受け取ったホスト名を再度dns-bに問い合わせてIPアドレスを取得し、mail-aに結果を返してメールの送信先を決定します。以上の手続きが短時間に行われ、AさんからのメールがBさんのメールボックスに届けられるというわけです。それでは、DNSサーバdns-bのゾーンファイルをのぞいてみましょう。"example-b.zone";};前回紹介したゾーンファイルに、(1)の行が追加されています。第1フィールドがスペースまたはタブになっていることから、この行が「@」に等しい記述、すなわち(3)でzoneの引数に指定されている「example-b.jp」についての記述であることが分かります。第3フィールドにはメールサーバを指定する「MXレコード」を記述し、続いて0〜65535の任意のプリファレンス値、最尾にメールサーバのホスト名を指定しています。行を変えて、新たにMXに指定されたホストのアドレス情報を追加すれば(2)、ゾーンファイルの完成です。MXレコードの確認にはdigコマンドを使用します。完全を期すために、外部のDNSを使用します。メールアドレスの@以降にドメインではなく、ホスト名がFQDNで指定されていた場合はどこにメールが届くのでしょうか?答えは皆さんご存じのとおり、そのホストに直接配信されます。@以降のドメインパートに対するMXが返ってこない場合はAレコードを調べ、そこへメールを送ります。この場合に覚えておく必要があることは、最新のsendmailではAレコードでの配信を抑止する機能を選択できるということです。デフォルトではMXレコードだろうとAレコードだろうと配信されますが、sendmailのインストールいかんでは配信されない可能性があります。MXレコードによるフォルートトレランスと負荷分散MXレコードを複数行記述することで、耐障害性(フォルートトレランス)に優れたメールサーバを構築することができます。耐障害性のために複数台のメールサーバを用意したとしても、ユーザーのメールボックスを分散させるわけにはいかないため、図5のような構成を考える必要があります。メールボックスを持たないメールサーバ(mail1、mail2)は、どのユーザーをどのサーバに転送するかを知っているものとします。この設定は、sendmailでは/etc/mail/aliasesに次のように記述することで実現できます。newaliasesの実行を忘れないでください。qmailであれば、/var/qmail/control/smtproutesファイルを準備します。example.jp:mail-inner/var/qmail/control/smtproutes肝心のゾーンファイルは、次のようになります。mail2になっています。大小関係さえはっきりしていれば、「100と200」でも「1と2」でも振る舞いに変わりはありません。することで、mail1に障害が発生してメールを処理できなくなることがない限り、外部のサーバはmail1に対してメールを送信します。mail1に障害が発生した場合は、次にプリファレンス値が低いMX(この場合はmail2)を探し、メールの送信を行います。仮にmail-innerに障害が発生したとしても、mail1やmail2でいったん処理されるため、外部から送信を試みるユーザーにエラーメールが返る心配はなく、mail-innerが回復次第、mail1、mail2からのメッセージを受け取ります。編注:プリファレンス値は、少々ややこしいので注意が必要。数値の小さい方が優先度は高く、数値の大きい方は優先度が低くなる。そのため、プリファレンス値の小さい方を指して「プリファレンス値が高い方」と表現する場合もある。(2)ゾーンファイル12(部分)。(1)(2)ともに同じプリファレンス値「10」が指定されているこの場合、DNSラウンドロビンと同じように、問い合わせごとに順序を変えてMXの値を返します。そのため、MXの負荷分散としても利用可能です(注)。ゾーンファイル4と同じように、TTLに明示的に短い値を指定するとより効果的でしょう。mail2.example.jp.ゾーンファイル13(部分)。注:同じプリファレンス値のMXがあった場合、どちらを使用するかはメールを送信するサーバの実装による場合もあります。ちなみに、プリファレンス値「0」も使用可能で、当然最優先を意味します。MXレコードのCNAME前述した「やってはいけないCNAMEの使用方法」で、CNAME以外の資源レコードで別名を使うことは避けるように説明しました。MXレコードも例外ではありません。次のようなゾーンファイルは使用可能ですが、お勧めできません。192.168.10.1ゾーンファイル14(部分)。MXに別名ホストを指定しているあるクライアントがexample.jpドメインのメールサーバを問い合わせてきた際、次のようなやりとりが行われます。mail.example.jpです。host1.example.jpへの別名です。192.168.10.1です。注:実際には、返答(2)(3)は同時に返されることがほとんどですが、それでもゾーンファイルの無駄な参照が行われます。見てのとおり、無駄な処理が発生していることが分かります。host1.example.jpのアドレスを変更する場合は、さらに悲惨な結果が待ち受けています。ゾーンファイル14のhost1のアドレスを変更しても、DNSのキャッシュ機能によってexample.jpドメインのメールサーバは古いアドレスが残ってしまう可能性もあります。9とメール/Webサーバを相互運用する際のゾーンファイルの設定を見てきました。数行の設定ファイルですが、そこに詰め込める可能性は無限大でないかと感じたことと思います。した奥深さはゾーンファイルだけでなくnamed.confファイルにも秘められています。BIND運用の真骨頂は、こうした設定ファイルのチューニングにあることを実感していただけたと思います。次回は、逆引き用ゾーンファイルの作成とDNSキャッシュサーバを運用する際のnamed.confの記述について紹介します。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。