名前解決の仕組みとゾーンファイルの設定：BINDで作るDNSサーバ（2）
今回は、BINDの設定を行う。ゾーンファイルの編集を行って正引き・逆引きが行えるようにするほか、MX、CNAMEなど各種レコードの使い方を紹介する。また、名前解決の仕組みについてもここで理解しておいてほしい。
BINDの基本的な動作
前回、DNSサーバの代表的な実装であるBINDをインストールしました。今回は設定を行います。
しかしその前に、BINDの動作を簡単に理解しておく必要があります。そうせずに、単に資料の引き写しの設定ファイルを使う方法もありますが、予期せぬ動作をしたときに対処できなくなってしまいます。
前回、「DNSは分散型データベースである」と述べました。つまり、どこかにすべてのデータを持ったサーバがあるわけではなく、あちらこちらにサーバが分散しているわけです。問題は、どうやって目的のデータを持ったサーバを見つけだすかです。
さすがに手掛かりゼロではどうしようもないので、最初の手掛かりとしてルートネームサーバが用意されています。いまのところ、ルートネームサーバは世界に13個存在します。BINDは問い合わせを受けると、まずこのルートネームサーバに照会します。すると、「そのドメイン名ならこのサーバに権限を委譲している」というデータが返ってきます。そこで、指示されたサーバに再び照会し直すと、さらに「そのドメイン名ならこのサーバに権限を委譲している」という回答が返ってきます。こうして権限を委譲されたサーバをたどっていくことで、最終的に「そのドメイン名のIPアドレスは210.xxx.xxx.xxxです」と答えてくれるサーバに行き着くわけです。
もう少し具体的に、www.atmarkit.co.jpのIPアドレスを問い合わせるとしましょう。まず、BINDはルートネームサーバに照会します。するとルートネームサーバは「jpドメインはサーバAに権限を委譲している」という答えを返します。ついでBINDはサーバAに対してwww.atmarkit.co.jpのIPアドレスを問い合わせます。するとサーバAは「co.jpドメインはサーバBに権限を委譲している」と答えます。サーバBに同じような問い合わせを行うと、「atmarkit.co.jpドメインはサーバCに権限を委譲している」と回答します。ここでサーバCに問い合わせると「www.atmarkit.co.jpのIPアドレスは211.2.252.66である」となって、無事解決できるわけです。
なお、ここでは単純にドメインごとにサーバを分けていますが、自前のDNSサーバを持たないドメインもあります。この場合は、より上位のDNSサーバが該当するドメインに対する問い合わせに答えます。
もちろん、問い合わせがあるたびにいちいちルートネームサーバから照会すると無駄なトラフィックが発生しますから、ある程度はBINDがデータをキャッシュしています。
BINDの設定
基本的な動作が分かったところで、順に設定ファイルを見ていきましょう。前提としてOCNエコノミーなどで、/28（ネットワークアドレスが28bitsでホストアドレスが4bits）のIPアドレスを割り当てられたことにします。この場合、ISPからDNSサーバのホスト名とIPアドレスを指定されるので、そのコンピュータでBINDを動かします。DNSサーバのIPアドレスは、だいたい下位4bitsだけを見て2というのが一般的なようです（0はネットワークそのもの、1はルータに対して割り当てられることが多い）。
まずは、BINDそのものの基本設定ファイルです。これは通常/etc/named.confですが、ディストリビューションによっても違ってきます。例えばLASER5 Linux 6.4はこのとおりですが、Debian GNU/Linux 2.2では/etc/bind/named.confです。
必要最小限の設定を挙げると、以下のようになります。
options {
directory "/etc/namedb";
};
zone "." {
type hint;
file "named.root";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "localhost.rev";
};
zone "atmarkit.co.jp" {
type master;
file "named.hosts";
};
zone "80.1.168.192.in-addr.arpa" {
type master;
file "named.rev";
};
上から順に説明しましょう。まずoptionsですが、ここではdirectoryを使ってBINDの設定ファイルがあるディレクトリを指定しています。/etc/bindなどでもいいでしょう。named.conf以外は、明示的に指定したこのディレクトリにまとめておいた方が分かりやすくなります。
次のzone "."は、ルートネームサーバを記述したファイルを指定します。ここではファイル名しか書いてありませんから、前述のoptionsで指定したディレクトリ内のnamed.root、すなわち/etc/namedb/named.rootを意味しています。
zone "0.0.127.IN-ADDR.ARPA"は、localhostを処理するためのおまじないです。ここはどんなサイトでも同じになります。
zone "atmarkit.co.jp"では、atmarkit.co.jpドメインのプライマリネームサーバになること、正引き（ドメイン名からIPアドレスを引くこと）のデータはnamed.hostsに記述することを指定します。
zone "80.1.168.192.in-addr.arpa"は逆引きの設定で、やはりプライマリネームサーバであることと、逆引き（IPアドレスからドメイン名を引くこと）のデータはnamed.revに収められていることを意味しています。なお、ここではIPアドレスとして192.168.1.80/28を想定しています。これはプライベートIPアドレスなので、実際には外部に向かってアナウンスすべきものではありません。実際に設定を行うときは、ISPから割り当てられたIPアドレスに適宜読み替えてください。また、zoneに続く記述ではIPアドレスを逆順に表記する点にも注意が必要です。
ルートネームサーバの設定
これは簡単です。named.confで指定したファイルに、ルートネームサーバを記述しておけばいいのです。最新のデータはftp://ftp.rs.internic.net/domain/named.rootです。これをそのままコピーすればOKです。原稿執筆時点では、1997年8月がlast updateになっています。たまにチェックするだけでよいでしょう。
正引きの設定
続けて、正引きのデータを用意します。サンプルとしては以下のようになります。
@ IN SOA dns.atmarkit.co.jp. root.atmarkit.co.jp. (
2000122401
10800
3600
604800
86400 )
;
IN NS dns.atmarkit.co.jp.
IN NS ns-tk023.ocn.ad.jp.
;
router IN A 192.168.1.81
;
sun IN A 192.168.1.82
mercury IN A 192.168.1.83
vinus IN A 192.168.1.84
earth IN A 192.168.1.85
mars IN A 192.168.1.86
jupiter IN A 192.168.1.87
saturn IN A 192.168.1.88
uranus IN A 192.168.1.89
neptune IN A 192.168.1.90
最初に、SOAレコードを記述します。冒頭の@マークは、自ドメインに置き換わります。正確を期すなら、atmarkit.co.jp.などと明示的に記述します。ここで、ドメイン名の最後にピリオドが付いていることに注意してください。
続くINはInterNetを意味しています。ほかにも指定できるパラメータはあるのですが、今日ではINしか使われていないといって差し支えないでしょう。SOAはStart Of Authorityの略です。続けて、このデータが格納されているホスト名と、このデータに責任を持つ人間の電子メールアドレスを記述します。いずれもピリオドが最後に付くこと、@を.に置き換える点に注意が必要です。
続く数字は、セカンダリネームサーバに対する指定です。最初にシリアル番号がきます。これはデータを変更したときにより大きな数値に変更することで、ほかのDNSサーバに変更があったことを知らせます。何でもいいのですが、2000122401のように年月日＋連番にしておくと、いつ変更したのか分かりやすくなります。
あとは、データを確認する間隔、失敗後再試行の間隔、データが無効になるまでの時間、データをキャッシュしておける時間を、それぞれ秒数で指定します。ここを変更する必要はほとんどありません。
コラム ピリオドの有無
BINDの正引き、逆引き設定ファイルでは、ピリオドの有無に気を付ける必要があります。それは、ピリオドがないとnamed.confで指定したドメイン名が補完されるからです。wwwとだけ書くとwww.atmarkit.co.jpになるのですが、www.atmarkit.co.jpと書くとwww.atmarkit.co.jp.atmarkit.co.jpと書いたことになってしまうのです。一般的にはFQDNを記述するよりもホスト名を記述する頻度が高いでしょうから、その手間を減らすためにこのような仕様になっているのでしょう。
SOAの次には、NSレコードを記述します。NSはName Serverの略で、ネームサーバを指定します。自分自身と、普通はISPが用意するセカンダリネームサーバを指定しておきます。ここでも、ドメイン名の最後にピリオドが付いていることに注意してください。
ようやく、個々のホスト名を記述するところまできました。ホスト名はA（Address）レコードで記述します。ここでは、ホスト名の後ろにピリオドを付ける必要はありません。IPアドレスも普通に記述します。
ホスト名の付け方に関しては、お好み次第です。小規模なうちは惑星、星座あたりを付ける人が多いようです。大規模になると、どうしても設置場所などをもとにした記号になってしまうようですが。
なお、ドメイン名が何を意味するのかは微妙です。例えばwww.atmarkit.co.jpと書いた場合、wwwがホスト名でatmarkit.co.jpがドメイン名、と考えるのが普通です。しかし、RFC 1034の2.4. Elements of the DNSあたりを読むと、どうもwww.atmarkit.co.jpでドメイン名となるようです。このあたりの誤解を避けるため、ホスト名を含んだドメイン名の記述をFQDN（Fully Qualified Domain Name：完全修飾ドメイン名 ）と呼んでいます。
逆引きの設定
正引きデータができたら、今度は逆引きデータです。サンプルは以下のとおり。
@ IN SOA sun.atmarkit.co.jp. root.atmarkit.co.jp. (
2000081501
10800
3600
604800
86400 )
;
IN NS dns.atmarkit.co.jp.
IN NS ns-tk023.ocn.ad.jp.
;
IN PTR atmarkit.co.jp.
IN A 255.255.255.240
;
81 IN PTR router.atmarkit.co.jp.
82 IN PTR sun.atmarkit.co.jp.
83 IN PTR mercury.atmarkit.co.jp.
84 IN PTR vinus.atmarkit.co.jp.
85 IN PTR earth.atmarkit.co.jp.
86 IN PTR mars.atmarkit.co.jp.
87 IN PTR jupiter.atmarkit.co.jp.
88 IN PTR saturn.atmarkit.co.jp.
89 IN PTR uranus.atmarkit.co.jp.
90 IN PTR neptune.atmarkit.co.jp.
SOAレコードとNSレコードについては、正引きのときと同じです。
逆引きのデータについては、PTR（PoinTeR）レコードで記述します。最初だけは例外的に、どこのドメイン名を扱うのかを宣言します。ここではatmarkit.co.jpを指定しますが、最後にピリオドが付くことを忘れないでください。続くAレコードでは、これも例外的にネットマスクを記述します。とりあえず、/28のネットワークでは255.255.255.240になります。
ネットマスクはBINDやDNSではなく、どちらかといえばIPネットワークの知識なのですが、簡単に説明しておきましょう。IPアドレスは2進数で書くと32けたです。そして、ネットワークを区別するためのネットワークアドレスと、ネットワーク内でホストを区別するためのホストアドレスで構成されています。このとき、上位何bitsをネットワークアドレスとして使うかを、/に続けた数値で表します。つまり192.168.1.80/28と書くと、192.168.1.80から始まる、ネットワークアドレス長が28bitsのネットワークということになります。さらにいえばホストアドレスは4（＝32−28）bitsですから16通りです。従って、192.168.1.80-192.168.1.95までがこのネットワークに所属するIPアドレスということになります。
このことを別の方法で表記するのが、ネットマスクです。こちらの方法だと、IPアドレスのうちネットワークアドレス部を1に、ホストアドレス部を0にしたものを、通常のIPアドレスの表記に従って0〜255の数値4つで記述します。これはちょうど2進数で8けたに相当する範囲です。なので、/28のネットワークだと最初の3つは255、最後の1つは2進数表記で11110000、10進数表記で240となるのです。
さて、以後は普通にIPアドレスとホスト名をPTRレコードとして記述していくだけです。ここでも、ドメイン名の最後にピリオドを付加します。また、IPアドレスは最も下位の1オクテットのみを記述するだけです。
最後に、もう1つループバック用の逆引きファイルを用意します。これでBINDを動かすために必要な最低限の設定ファイルがそろったことになります。
@ IN SOA dns.atmarkit.co.jp. root.atmarkit.co.jp. (
2000081501
10800
3600
604800
86400 )
;
0.0.127.in-addr.arpa. IN NS dns.atmarkit.co.jp.
;
1.0.0.127.in-addr.arpa. IN PTR localhost.
MXの設定
以上で基本的な設定は終了です。しかし、まだ重要な設定が残っています。それはメールサーバを指定するMX（Mail eXchanger）レコードです。OCNエコノミーでDNSサーバを自組織で用意するということは、すなわちメールサーバも自組織で用意するということです。そのため、MXレコードの設定は欠かせません。メールサーバ自体の設定は、本フォーラムの実用qmailサーバ運用・管理術などを参照してください。
MXレコードは、正引きデータを記述したファイルに
IN MX 10 sun.atmarkit.co.jp.
IN MX 20 mercury.atmarkit.co.jp.
といった形で指定します。ここでMXに続く数値はプリファレンス値といいます。この数値が小さい順に、順次メールサーバとしてアクセスするという指定になります。相対的な大きさだけが問題なので、符号なし16bits数値の範囲なら好きなように設定できます。つまり、予備のメールサーバを作っておけるわけです。
CNAMEの設定
もう1つ、便利な設定にCNAME（Canonical NAME）レコードがあります。これは、1つのIPアドレスに幾つかのホスト名を割り当てるときに使います。これもMXレコード同様に、正引きデータを記述したファイル内に記述します。例としてはこんなところでしょうか。
dns IN CNAME sun www IN CNAME sun smtp IN CNAME sun pop IN CNAME sun imap IN CNAME sun proxy IN CNAME mercury rfc IN CNAME mercury
サービス名をそのままCNAMEで設定しておくと、実際にサービスを提供しているコンピュータが変わったときに、BINDのデータを変更するだけで済みます。個々のクライアントは、一切変更する必要がないわけです。ただ、この方法は外部の悪意を持ったユーザーから容易に推察できるという点で、セキュリティ的にはやや問題のある方法です。
また、Apacheと組み合わせてバーチャルホストを使うときにも、CNAMEは欠かせません。この方法を使うと、1つのIPアドレスを割り当てた1台のホストで、見かけ上は複数のWebサーバを運用できます。
最後に、いま紹介したMXおよびCNAMEレコードを正引きファイルに反映してみましょう。以下のリストが完成版です。
@ IN SOA dns.atmarkit.co.jp. root.atmarkit.co.jp. (
2000122401
10800
3600
604800
86400 )
;
IN NS dns.atmarkit.co.jp.
IN NS ns-tk023.ocn.ad.jp.
IN MX 10 sun.atmarkit.co.jp.
IN MX 20 mercury.atmarkit.co.jp.
;
router IN A 192.168.1.81
;
sun IN A 192.168.1.82
mercury IN A 192.168.1.83
vinus IN A 192.168.1.84
earth IN A 192.168.1.85
mars IN A 192.168.1.86
jupiter IN A 192.168.1.87
saturn IN A 192.168.1.88
uranus IN A 192.168.1.89
neptune IN A 192.168.1.90
;
dns IN CNAME sun
www IN CNAME sun
smtp IN CNAME sun
pop IN CNAME sun
imap IN CNAME sun
proxy IN CNAME mercury
rfc IN CNAME mercury
簡単な動作の確認
ここまでくれば、BINDを動かし始めることができるはずです。ディストリビューションによっては、パッケージからインストールした時点で動き始めているかもしれません。psコマンドを使ってnamedを探し、ないようだったら実行します。すでに動いていれば、変更内容を反映するためにSIGHUPを該当プロセスに送ってください。実行するコマンドは、
$ kill -HUP プロセス番号
です。
ここでresolv.confを書き換えて、いきなり外のWebにアクセスする方法もあります。が、テスト用のnslookupを使った方がよいでしょう。起動後に、まずローカルなネットワークに所属するホスト名だけを打ち込んで［Enter］キーを押します。すると、対応するIPアドレスが返ってくるはずです。逆にIPアドレスを入力すると、ホスト名が返ってきます。ローカルなネットワークでうまくいったら、外部のホスト名に対しても確認してみましょう。
もう1つ、MXレコードについても確認しておきましょう。nslookupのプロンプトで、以下のように操作します。
> set type=mx > atmarkit.co.jp
すると、MXレコードの設定に応じて、以下のような出力が得られます。
atmarkit.co.jp preference = 20, mail exchanger = smtp.atmarkit.co.jp atmarkit.co.jp nameserver = ns.sunbridge.net atmarkit.co.jp nameserver = ns2.jp.psi.net atmarkit.co.jp nameserver = ns3.jp.psi.net ns2.jp.psi.net internet address = 38.8.189.2 ns3.jp.psi.net internet address = 154.33.113.22
この設定と、メールサーバの設定が正しければ、外部からSMTPでメールを受け取ることができるはずです。
もし、うまくいかなかったら……次回は不具合の発見方法をお伝えします。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。