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

» 2003年02月15日 00時00分公開

BIND 9とメールサーバ

　続いて、メールサーバとBIND 9の相互運用を考えてみましょう。

MXについて

図4　メール送信とDNS

　user-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のゾーンファイルをのぞいてみましょう。

$TTL 86400

            @            IN      SOA dns.example-b.jp. root.example-b.jp. (

                                 2002122001 ; serial

                                 3600       ; refresh 1hr

                                 900        ; retry 15min

                                 604800     ; expire 1w

                                 86400      ; min 24hr

            )

                         IN      NS     dns-b.example-b.jp.

                         IN      MX  10 mail-b.example-b.jp.　（1）

            

            dns-b        IN      A      192.168.10.1

            mail-b       IN      A      192.168.10.11　（2）

ゾーンファイル10

参考：named.confファイル中のゾーンファイルの指定個所

zone "example-b.jp" {　（3）

                      type master;

                      file "example-b.zone";

              };

　前回紹介したゾーンファイルに、（1）の行が追加されています。第1フィールドがスペースまたはタブになっていることから、この行が「@」に等しい記述、すなわち（3）でzoneの引数に指定されている「example-b.jp」についての記述であることが分かります。

　第3フィールドにはメールサーバを指定する「MXレコード」を記述し、続いて0～65535の任意のプリファレンス値、最尾にメールサーバのホスト名を指定しています。行を変えて、新たにMXに指定されたホストのアドレス情報を追加すれば（2）、ゾーンファイルの完成です。

　MXレコードの確認にはdigコマンドを使用します。より完全を期すために、外部のDNSを使用します。

$ /usr/local/bin/dig @DNSサーバのアドレス example-b.jp mx

            （省略）

            ;; ANSWER SECTION:

            example-b.jp.           38400   IN      MX      10 mail-b.example-b.jp.　（1）

            （省略）

            ;; ADDITIONAL SECTION:

            mail-b.example-b.jp.    38400   IN      A       192.169.10.11　（2）

（1）　MXより末尾まで空白になる場合、MXは登録されていない
（2）　MXに登録されたホストのIPアドレス

　では、MXが指定されていないドメインへのメール配信はどうなるのでしょうか？例えば、メールアドレスの@以降にドメインではなく、ホスト名がFQDNで指定されていた場合はどこにメールが届くのでしょうか？

　答えは皆さんご存じのとおり、そのホストに直接配信されます。@以降のドメインパートに対するMXが返ってこない場合はAレコードを調べ、そこへメールを送ります。この場合に覚えておく必要があることは、最新のsendmailではAレコードでの配信を抑止する機能を選択できるということです。デフォルトではMXレコードだろうとAレコードだろうと配信されますが、sendmailのインストールいかんでは配信されない可能性があります。

MXレコードによるフォルートトレランスと負荷分散

　MXレコードを複数行記述することで、耐障害性（フォルートトレランス）に優れたメールサーバを構築することができます。

図5　メールを処理するサーバとメールボックスを管理するサーバを用意した構成

　耐障害性のために複数台のメールサーバを用意したとしても、ユーザーのメールボックスを分散させるわけにはいかないため、図5のような構成を考える必要があります。メールボックスを持たないメールサーバ（mail1、mail2）は、どのユーザーをどのサーバに転送するかを知っているものとします。この設定は、sendmailでは/etc/mail/aliasesに次のように記述することで実現できます。

user1: user1@mail-inner

            user2: user2@mail-inner

            user3: user3@mail-inner

            user4: user4@mail-inner

/etc/mail/aliases

　編集後、

# newaliases

の実行を忘れないでください。

　qmailであれば、/var/qmail/control/smtproutesファイルを準備します。

example.jp:mail-inner

/var/qmail/control/smtproutes

　肝心のゾーンファイルは、次のようになります。

             IN      MX  10 mail1.example.jp.

                         IN      MX  20 mail2.example.jp.

            mail1        IN      A      192.168.10.10

            mail2        IN      A      192.168.10.11

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

　MXレコードのプリファレンス値（編注）は、mail1 < mail2になっています。大小関係さえはっきりしていれば、「100と200」でも「1と2」でも振る舞いに変わりはありません。こうすることで、mail1に障害が発生してメールを処理できなくなることがない限り、外部のサーバはmail1に対してメールを送信します。mail1に障害が発生した場合は、次にプリファレンス値が低いMX（この場合はmail2）を探し、メールの送信を行います。仮にmail-innerに障害が発生したとしても、mail1やmail2でいったん処理されるため、外部から送信を試みるユーザーにエラーメールが返る心配はなく、mail-innerが回復次第、mail1、mail2からのメッセージを受け取ります。

編注：プリファレンス値は、少々ややこしいので注意が必要。数値の小さい方が優先度は高く、数値の大きい方は優先度が低くなる。そのため、プリファレンス値の小さい方を指して「プリファレンス値が高い方」と表現する場合もある。

　では、同じプリファレンス値が指定された場合はどのような振る舞いになるのでしょうか？

             IN      MX  10 mail1.example.jp.　（1）

                         IN      MX  10 mail2.example.jp.　（2）

ゾーンファイル12（部分）。（1）（2）ともに同じプリファレンス値「10」が指定されている

　この場合、DNSラウンドロビンと同じように、問い合わせごとに順序を変えてMXの値を返します。そのため、MXの負荷分散としても利用可能です（注）。ゾーンファイル4と同じように、TTLに明示的に短い値を指定するとより効果的でしょう。

         1h    IN      MX  10 mail1.example.jp.

                     1h    IN      MX  10 mail2.example.jp.

ゾーンファイル13（部分）。TTLに1時間を指定した場合

注：同じプリファレンス値のMXがあった場合、どちらを使用するかはメールを送信するサーバの実装による場合もあります。

　ちなみに、プリファレンス値「0」も使用可能で、当然最優先を意味します。

MXレコードのCNAME

　前述した「やってはいけないCNAMEの使用方法」で、CNAME以外の資源レコードで別名を使うことは避けるように説明しました。MXレコードも例外ではありません。次のようなゾーンファイルは使用可能ですが、お勧めできません。

             IN      MX  10 mail.example.jp.　（1）

            

            mail         IN      CNAME  host1.example.jp　（2）

            host1        IN      A      192.168.10.1

ゾーンファイル14（部分）。MXに別名ホストを指定している

　あるクライアントがexample.jpドメインのメールサーバを問い合わせてきた際、次のようなやりとりが行われます。

問い合わせ（1）：	example.jpのメールサーバは？
↓
返答（1）：	mail.example.jpです。

問い合わせ（2）：	mail.example.jpのIPアドレスは？
↓
返答（2）：	host1.example.jpへの別名です。

問い合わせ（3）：	host1.example.jpのIPアドレスは？
↓
返答（3）：	192.168.10.1です。
注：実際には、返答（2）（3）は同時に返されることがほとんどですが、それでもゾーンファイルの無駄な参照が行われます。

　見てのとおり、無駄な処理が発生していることが分かります。さらに、host1.example.jpのアドレスを変更する場合は、さらに悲惨な結果が待ち受けています。ゾーンファイル14のhost1のアドレスを変更しても、DNSのキャッシュ機能によってexample.jpドメインのメールサーバは古いアドレスが残ってしまう可能性もあります。

　今回は、BIND 9とメール／Webサーバを相互運用する際のゾーンファイルの設定を見てきました。たかだか数行の設定ファイルですが、そこに詰め込める可能性は無限大でないかと感じたことと思います。こうした奥深さはゾーンファイルだけでなくnamed.confファイルにも秘められています。BIND運用の真骨頂は、こうした設定ファイルのチューニングにあることを実感していただけたと思います。

　次回は、逆引き用ゾーンファイルの作成とDNSキャッシュサーバを運用する際のnamed.confの記述について紹介します。

「次回」へ

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