BINDによるDNSサーバーの構築

　ここでは、DNSサーバーであるBINDについて解説していきます。BIND（Berkeley Internet Name Domain）とは、カリフォルニア大学バークリー校で開発されたDNSサーバであり、現在、広く普及しているDNSサーバーの多くはBINDを元に作られたものです。DNSサーバーを構築するには必ず2台以上のDNSサーバーを必要とし、また、それをInterNICなどの中央グループに申請しておかなければなりません。当ページでは、既に固定IPアドレスを１つ以上取得済みで、且つ独自ドメイン（DynamicDNSでも可）を取得していることを前提として解説しています。なお、勉強のために内向けDNSサーバーを構築することもできますので、是非トライしてみてください。BIND は初心者にとっては非常にとっつきにくいもので、MicrosoftDNSのような簡単設定ではありません。DNS関連の予備知識も予め身に付けておかなくてはなりません。けれども、仕組みさえ理解してしまえばあとはこっちのものです。おそらく何度か壁にぶつかると思いますが、是非、頑張ってください。

　まず、筆者の環境では固定IPアドレスをひとつ取得しているので、プライマリDNSサーバーを自前サーバーとして、セカンダリDNSサーバーは各自加入しているプロバイダ、もしくは無料のセカンダリDNSサーバー業者を利用することを前提としてすすめます。固定IPアドレスはひとつしかないため、ルータ等のNAT機能により、アドレス変換をしてWAN側IPアドレスとLAN側IPアドレスを対応づけます。では、下記図に示す環境を想定してBINDの設定を行っていきます。

◎想定するネットワーク環境

　BINDを動かすためには、ブートファイルであるnamed.conf と各ゾーンの設定を記述したファイルが必要になります。基本的な最小限構成としては、以下の６つのファイルが必要です。


■ブートファイル	named.conf

■ヒントファイル	named.ca

■kororo.jp用正引き参照ゾーン	kororo.jp.zone

■kororo.jp用逆引き参照ゾーン	218.117.219.in-addr.arpa.zone

■ループバック正引き参照ゾーン	localhost.zone

■ループバック逆引き参照ゾーン	0.0.127.in-addr.arpa.zone

　これらのファイルの内、ヒントファイルとループバック前方（正引き）参照ゾーンファイルは、共通ファイルとなっているので特に編集する箇所はありません。このふたつは、BINDインストール時にデフォルトで、/var/named 以下に格納されています。なお、named.ca には世界に13台あるルートネームサーバー（そのうちの一台は日本にあります）の情報が記述されているのですが、セキュリティ対策の一環として、何年かに一度変更されることがあるみたいなので、ときどき（？）、最新版を確認するようにしてみてください（執筆時点での最新は2002年11月5日です）。

　また、固定IPアドレスがひとつの場合、逆引きの管理は通常はプロバイダが行うため、kororo.jpゾーンの逆引きファイル（ここでいう218.117.219.in-addr.arpa.zone）も作る必要がありません。プロバイダによっては逆引きの管理はプロバイダの仕事であるとみなすところもあり、IPアドレスは提供しますが、逆引き権限の委譲は行いません、と言われてしまいます。筆者の場合、単に逆引きをした時に自分のホスト名が表示されて欲しいがために(^▽^;)、インターリンクのMOOTサービス（逆引きの設定を行うサービス）に加入していますが、どちらにしろ、逆引きの管理はプロバイダ側で行うので逆引きファイルの作成は必要ありません（一応、逆引き設定ファイルの解説も下記に記します）。

■/etc/named.confの設定例

　いよいよ、核となるnamed.confの設定方法について解説していきます。BINDではnamed.conf がブートファイルなり、各ゾーンファイルを読み込みにいくようになっています。全てを説明してると日が暮れてしまうので(・・;)、基本的な事に絞って説明していきます。詳細については後述します。

controls {
        inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};

acl localnet {
        172.16.50.0/27;
        127.0.0.1/8;
};

options {
        directory "/var/named";
        allow-transfer  {
              localnet;
              203.141.128.33;
              195.20.105.149;
        };
        version "no version";
};

zone "." {
         type hint;
         file "named.ca";
};

zone "localhost"{
         type master;
         file "localhost.zone";
         allow-update { none; };
};

zone "0.0.127.in-addr.arpa"{
         type master;
         file "0.0.127.in-addr.arpa.zone";
         allow-update { none; };
};

zone "kororo.jp"{
         type master;
         file "kororo.jp.zone";
};

zone "218.117.219.in-addr.arpa"{
         type master;
         file "218.117.219.in-addr.arpa.zone";
};

include "/etc/rndc.key";

■acl ステートメント（アクセス制御リスト）

　acl ステートメントでは、アクセスを許可してもよいネットワークを予め定義しておきます。例えば、以下のように用いることができます。


acl localnet {
        172.16.50.0/27;
        127.0.0.1/8;
};
zone "50.16.172.in-addr.arpa"{
         type master;
         file "0.50.16.172.in-addr.arpa.zone";
         allow-update { localhost; };
};

■optionsステートメント

　optionsでは数多くのオプションを指定することができます。directoryオプションは、ゾーンデータファイルのパスを指定します。デフォルトでは、/var/named となっており、特に変更する必要はありません。allow-transferは、アクセスを許可するホスト、もしくはネットワークを指定し、これによってアクセスを制限することができるのでセキュリティが向上します。また、allow-transferはzoneステートメントでも指定することができ、zoneステートメントに記述したほうが優先されるようになっています。

■includeステートメント

　ここで指定したファイルを外部から読み込むことができます。デフォルトでは、/etc/rndc.keyを読み込むように指定されています。

■kororo.jp用正引き参照ゾーン/ kororo.jp.zone


$TTL 86400
;$ORIGIN kororo.jp
@             IN   SOA    ns1.kororo.jp. root.kororo.jp. (
                                2003121401  ; Serial
                                10800          ; Refresh
                                3600           ; Retry
                                604800        ; Expire
                                86400 )       ; Minimum TTL

;Authoritative Name Servers
              IN   NS     ns1.kororo.jp.
              IN   NS     tegtan1.interlink.or.jp.
              IN   NS     ns0.xname.org.
			  
;Mail eXchanger
              IN   MX 10  mail.kororo.jp.
mx          IN   A         219.117.218.26

;Hosts
ns1          IN   A         219.117.218.26
www        IN   CNAME  ns1.kororo.jp.

　それでは、まず基本的なDNS用語から説明していきます。以下で説明していることは、BIND に限らず、他のDNSサーバーを利用する際にも頻出用語となるので是非、覚えておいてください。


$TTL	TTL（Time to Live）では、ネームサーバーがゾーンデータをキャッシュする時間を指定します。初期値は１日（86400秒）です。

$ORIGIN	対象としているドメインのドメイン名を補います。ここでは、$ORIGINをコメントアウトして無効にしていますが、仮に指定した場合は、資源レコードで「www IN CNAME ns1.kororo.jp.」を「www IN CNAME ns1」のようにドメイン名を省略することができます。

＠	ドメインを表しています。ここでの＠は「kororo.jp」と同じ意味です。" @ "は省略することも可能で、空白行で始まるレコードは、暗黙の了解で前の行と同じ名前を指定しているのと同じことになります（ここでは、「@ IN SOA ns1.kororo.jp.」）。

Serial	ゾーンを作成以来、このゾーンが何回変更されたかを表す数値です。一般的には、何年何月何日ヴァージョン名といった書式や１番から通し番号で順番に数値を上げていくなどの書式が多いようです。なお、シリアル番号を更新し忘れるとDNS情報も更新されないので注意してください（2000server はシリアルも自動更新してくれるんですけどねぇ）。必ず現在設定されている数値より大きな数字に設定してください。逆に最初から大きな数字を設定しすぎるとゾーン転送情報のキャッシュ保持期限が過ぎるまでは小さくできなくなってしまうので注意してください。

Refresh	ゾーン転送のリフレッシュ間隔を設定します。時間が長すぎてもゾーン情報の伝播が遅れてしまうし、逆に短すぎても更新頻度が早すぎて他のゾーン情報の転送に影響を与えてしまうことがあるので適度な値に設定するようにしましょう。

Retry	ゾーン転送の再試行間隔を設定します。通常は、Refresh値より小さな値に設定します。

Expire	セカンダリサーバのゾーンデータの保持期間を設定します。仮にプライマリDNSになんらかの障害が発生し、新しいゾーン情報が転送されなかった場合に、セカンダリDNSがどれくらいの期間、ゾーンデータを保持するかを設定します。

Minimum	キャッシュの最小保持時間を設定します。

次に代表的なレコードの説明をしていきます。

■NSレコード
　ネームサーバーレコードのことで、DNSサーバーを特定するために指定します。ここでは、「IN NS ns1.kororo.jp.」と指定していますが、これは、kororo.jpゾーンのネームサーバーはns1.kororo.jpですよ、ということを指し示しています。また、" @ "を省略しているので、空白行で始まっています。注意しなければならないのは、ホスト名の後ろに、" . "（ドット）を挿入しなければならないということです。"."を指定していない場合、$ORIGIN で指定したドメイン名が自動的に補完されるようになり、誤った解釈をされてしまいます。具体的には、仮に$ORIGIN にkororo.jp と指定し、ホスト名の後ろの" . "を省いた場合は、

　　　IN MX 10 mail.kororo.jp.kororo.jp

と解釈されてしまいます。$ORIGIN を指定した場合の正確な表記は、

　　　IN MX 10 mail

のように書きます。NSレコードにはネームサーバーをいくつも書いても構わないので、私の場合は、セカンダリサーバーとしてインターリンクとxnameを追記しています。

■Aレコード
　Aレコードは、ホスト名を特定することからホストレコードと呼ばれます。Aレコードの役割としてはDNS名とIPアドレスを結びつけることです。

　　　IN NS ns1.kororo.jp.
　　　ns1 IN A 219.117.218.26

上記2行はセットとして考えます。一行目でこのゾーンのネームサーバーはns1.kororo.jp であることを指定していますが、じゃぁ、そのマシンの住所（IPアドレス）はどこにあるの？ということになり、2行目でAレコードに219.117.218.26を指定してあげることでマシンの特定を行うことができるようになるのです。

■MXレコード（Mail eXchange）
　ゾーンのメールサーバーを特定します。「IN MX 10 mail.kororo.jp. 」は、kororo.jpゾーンのメールサーバーは、mail.kororo.jp ですよ、という意味になります。ここでの説明では、DNSサーバーとメールサーバーが同一マシン上で稼動しているので、ns1とmail は名前こそ違うけれど、Aレコードに219.117.218.26と指定あげることで、ネームサーバーとメールサーバーは同じマシンなんだと教えてあげることができます。要するに、ネームサーバー（ns1）の別名はmail である、ということになりますが、ここで注意しておきたいのは、MXレコードを別名を表すレコードであるCNAMEで使用してはならないということです。

X　誤った使い方

              IN   MX 10          mail.kororo.jp.
mx        IN   CNAME         219.117.218.26

○　正しい使い方

              IN   MX 10   mail.kororo.jp.
mx        IN   A         219.117.218.26

　もうひとつ、MXレコードには、優先順位というものがあります。メールサーバーが同一ドメイン内に複数ある場合に、どちらを優先させるかを指定することができます。それが、"IN MX 10"の"10"という数値です。2番目のメールサーバーを指定する場合には、"IN MX 20"のようにします。このプリファレンス値は、絶対値の大小の意味は持たず、仮にプリファレンス値が"10"のメールサーバーが5つあったとしたならば、5つのメールサーバーのどれを使っても良いという意味になります。その中で一台だけプリファレンス値に"20"の値を持つ、メールサーバーがあった場合は、バックアップメールサーバーとしての役割を果たします。

■CNAMEレコード
　CNAMEとは、Canonical Nameの略で、別名を表すレコードです。例えば、ひとつのマシンで複数の名前に対応させたい場合、CNAMEを使うことで、ns1.kororo.jp は、www.kororo.jp やftp.kororo.jp などの名前にも反応させることができます。普段、ブラウザでURLを指定するときに当たり前のように「http://www.～」と入力しますが、この時のwww はCNAMEによって別名を持ったホスト名であると考えることができるのです。ネームサーバーとWebサーバーの一人ニ役をかっているわけです。また、CNAMEを利用するとApacheのVirtualHostと連携させることで異なるURL名を持った複数のWEBサイトを持つことも可能になります。以下の例に示すように、

　　　www IN CNAME ns1.kororo.jp.
　　　tamesi IN CNAME ns1.kororo.jp

と指定し、Apacheのhttpd.conf に、

<VirtualHost *>
ServerName www.kororo.jp
以下省略
</VirtualHost>

<VirtualHost *>
ServerName tamesi.kororo.jp
以下省略
</VirtualHost>

と記述するだけで、ブラウザ上からは「www.kororo.jp」と「tamesi.kororo.jp」のふたつのサイトにアクセスすることができるようになります。DynamicDNSを利用して複数のWebサイトを運営したことがあるかたならすぐにピンとくると思いますが、example.orgというドメインを取得した場合に、xxx.example.orgやyyy.example.org、zzz.example.orgといったように業者の制限が許す限り、いくつもの名前で独自ドメインを登録することができたと思います。これはまさに、CNAMEの働きによって実現されているのです。

■kororo.jp用逆引き参照ゾーン/ 218.117.219.in-addr.arpa.zone


$TTL 86400
;$ORIGIN kororo.jp
@             IN         SOA    ns1.kororo.jp. root.kororo.jp. (
                                2003121301  ; Serial
                                10800          ; Refresh
                                3600           ; Retry
                                604800        ; Expire
                                86400 )       ; Minimum TTL

; Authoritative Name Servers
              IN    NS    ns1.kororo.jp.
              IN    NS    tegtan1.interlink.or.jp.
              IN    NS    ns0.xname.org.
; Hosts
              IN    PTR   ns1.kororo.jp.

　さて、基本的な事を説明したところで次は逆引きゾーンの作成にはいります。といっても、説明するべき事は既に正引きゾーンのところで行いました。正引きゾーンと異なる箇所はPTRレコードのみです。但し、冒頭でも述べたように固定IPアドレスがひとつの場合、逆引き権限は通常はプロバイダが有しているため、ほとんどの場合において逆引き参照ゾーンは作成する必要はありません。けれども、内向け（LAN内）で名前解決を行う場合は、逆引き参照ゾーンも必要となってきますが、ここでは敢えて割愛させていただきます。詳しい説明は、「内向けDNSと外向けDNSの構築」を参照してください。

■PTRレコード（Pointer）
　PTRレコードはAレコードと逆の働きをします。つまり、IPアドレスからホスト名へのマッピングを行います。固定IPアドレスがひとつの場合、PTRレコードは自ずとひとつになります。もしも、固定IPアドレスを8個取得し、unnumberd によりアドレス変換機能を無効にしている場合などは、以下のように、配布されたネットワークアドレスの中から有効な範囲のアドレス（数字）を指定していきます。

◎固定IPアドレスが8個の場合

IN NS ns1.kororo.jp.
IN NS tegtan1.interlink.or.jp.

100　IN PTR ns1.kororo.jp
101　IN PTR ns2.kororo.jp.
102　IN PTR www.kororo.jp.
103　IN PTR mail.kororo.jp.
104　IN PTR ftp.kororo.jp.

■ループバック正引き参照ゾーン / localhost.zone

　ループバック正引きゾーンは、共通ファイルとなるので、デフォルトで用意されているものを使用して構いません。


$TTL 86400
;$ORIGIN kororo.jp
@             IN        SOA     localhost. root.localhost. (
                                2003121101  ; Serial
                                10800          ; Refresh
                                3600           ; Retry
                                604800        ; Expire
                                86400 )       ; Minimum TTL

              IN    NS    localhost.

1             IN    PTR   localhost.

■ループバック逆引き参照ゾーン / 0.0.127.in-addr.arpa.zone

　ループバック逆引きゾーンで編集するべきなのは一箇所のみです。ns1.kororo.jp の箇所を自分のドメイン名に変更すればいいだけです。


$TTL 86400
;$ORIGIN kororo.jp
@             IN        SOA     localhost. root.localhost. (
                                2003121101  ; Serial
                                10800          ; Refresh
                                3600           ; Retry
                                604800        ; Expire
                                86400 )       ; Minimum TTL

; Authoritative Name Servers
              IN     NS    ns1.kororo.jp.
; Hosts
1             IN     PTR   localhost.

■セカンダリDNSサーバーへのゾーン転送

　ゾーン転送とは、プライマリDNSサーバーからセカンダリDNSサーバーへとゾーンデータを転送することで、TCP53番が使われます。ゾーン転送はセカンダリDNSサーバーからプライマリDNSへと要求する仕組みになっているのですが、では、セカンダリDNSサーバーが要求してくるまで更新を何時間も待たなければいけないのかと思うかもしれませんがそうではありません。こちら（プライマリDNS）から、セカンダリDNSに更新を知らせるための方法があり、そのことをNOTIFYメッセージと呼びます。NOTIFYメッセージはデフォルトで有効になっており、BINDを再起動するだけで、NOTIFYメッセージをセカンダリDNSサーバーへ送信することができます。もし、NOTIFYメッセージをnamed.confに明示的に指定する場合は、

zone "kororo.jp"{
　　　　type master;
　　　　notify yes;
　　　　file "kororo.jp.zone";
};

のように編集します。DNSはよく仕組みがわからないうちにむやみやたらにゾーン転送を行うと他のネットワークを混乱させてしまうこともあるので、まだ自分の設定に自信がない方は、「notify no; 」と指定するようにしてください。こうすることで、ゾーン転送は行われなくなります。もし、namedを再起動できない場合は、

# ps aux | grep named
named 1727 0.0 1.1 30564 3060 ? S Dec14 0:15 /usr/sbin/named -u named
# kill 1727
# /etc/rc.d/init.d/named start

と、一旦プロセスを切断してから再起動してください。もし、rndcを使用している場合は、

# rndc reload

とリロードを行うことでBINDを停止させることなく、ゾーン転送を行うことができるようになります。rndc reload はターミナル上では成功しても何も表示されませんが、syslog には、 loading configuration from '/etc/named.conf' のように表示されています。表示されていればリロードがきちんと行われていることを確認できます。

■DNSサーバーの動作確認

　それでは、ゾーンデータファイルの記述が終了したら、いよいよDNSがきちんと動作しているのかどうか確認をおこなっていきます。まず、一番不安になるのが自分が作成したゾーン情報がプロバイダ等のセカンダリＤＮＳサーバーにきちんと反映されているかどうかということですね。初めてDNSを構築する方にとっては非常にわかりづらいところです。DNSの情報が全世界に伝播するまでには、一般的に12時間～24時間（あるいはそれ以上）かかります。といっても、1日～2日間待たないと確認がとれなわけではありません。もしゾーン転送に成功した場合、セカンダリDNSサーバーには確実にゾーンデータ情報は行き渡っているのでNSLOOKUPコマンドを利用して動作の確認を行います。また、Linuxのログを閲覧することで転送されたかどうかの確認を行うことができます。NSLOOKUPコマンドの解説については「NSLOOKUPコマンドによる動作確認」に譲ることとして、ここでは実際にログを閲覧して成功例と失敗例について見ていくこととします。

　まず、namedを再起動した後で、/var/log/messageを開いてみてください。以下にゾーン転送の成功例と失敗例を載せておきますので参考にしてください。

# tail /var/log/messages

◎ ゾーン転送成功例

zone kororo.jp/IN: sending notifies (serial 20031213)
client 203.141.128.33#2285: transfer of 'kororo.jp/IN': AXFR-style IXFR started
client 195.20.105.149#1386: transfer of 'kororo.jp/IN': AXFR-style IXFR started

X ゾーン転送失敗例①

zone kororo.jp/IN: sending notifies (serial 20031213)
client 203.141.128.33#2285: transfer of 'kororo.jp/IN': denied
client 195.20.105.149#1386: transfer of 'kororo.jp/IN': denied

X ゾーン転送失敗例②

zone kororo.jp/IN: sending notifies (serial 20031213)

失敗例②では、通知はされるけど、AXFR-style IXFR started が表示されない場合です。もし、denied の結果になってしまった場合は、もう一度設定ファイルをじっくり見直し、間違っている箇所がないかどうか確認してください。また、シリアル番号を更新したかどうか今一度確認してください。その他には、named.confやゾーンデータファイルの文法チェックを行ってくれるツールもあるので是非、活用してみてください（以下後述）。

　上記の成功例のように表示された方は、NSLOOKUPコマンドを使用して以下のように表示されるか確認します。以下はWindowsマシン上からDoSプロンプトを使用した例です。

C:\>nslookup
Default Server: ns1.kororo.jp
Address: 172.16.50.2
#内向け用のDNSも作成した場合は、LAN内でも名前解決が行われます。もし外向けDNSしか作成していない場合は、

DNS request timed out.
timeout was 2 seconds.
*** Can't find server name for address 172.16.50.2: Timed out

のように解決できなかった旨が表示されます。

> server tegtan1.interlink.or.jp
Default Server: tegtan1.interlink.or.jp
Address: 203.141.128.33
#デフォルトサーバーをセカンダリDNSに指定します。

> ns1.kororo.jp
Server: tegtan1.interlink.or.jp
Address: 203.141.128.33

Name: ns1.kororo.jp
Address: 219.117.218.26

> www.kororo.jp
Server: tegtan1.interlink.or.jp
Address: 203.141.128.33

Name: ns1.kororo.jp
Address: 219.117.218.26
Aliases: www.kororo.jp
#自分のネームサーバーを指定して正引きができていれば成功です。他にもCNAMEを使って別名を定義した方は、そちらの方も確認してみてください。CNAMEの場合は、「Aliases: www.kororo.jp」のように表示されるはずです。

> 219.117.218.26
Server: tegtan1.interlink.or.jp
Address: 203.141.128.33

Name: ns1.kororo.jp
Address: 219.117.218.26
#最後に逆引き確認です。自分の固定IPアドレスを入力してホスト名が返ってくれば正常に動作していることになります。

■外部からDNSサーバーチェック

　外部から自分のDNSサーバーを詳しくチェックしてくれるサイトがあるのでご紹介します。結果表示には３段階あり、テストに成功すればPASS 、とやかくいうつもりはないけどこうした方がいいよというメッセージがWARN、テストに失敗した場合が、FAILと表示されます。もし、自分のサイトのDNSに問題があるようならすぐにゾーンデータファイルを修正しましょう。

⇒http://www.dnsreport.com/

■named.conf 、ゾーンデータファイルの文法チェック

　named.conf やゾーンデータファイルの行数が長くなってくると" } "や" ; "の付け忘れなどのミスが少なからず発生してくるものです。そこで、設定ファイルの文法チェックを行ってくれるツールも用意されているのでファイルを更新した場合はできる限りチェックを行うことをお勧めします。因みに、いまから説明するツールは文法のみのチェックを行うだけで中身についてまではチェックしません。あくまで、書式がきちんと規則にのっとって記述されているか、というところまでしかチェックしないので、「文法チェックは正常なのになんでゾーン転送が成功しないんだ！」と文句をいわないようにσ(^_^;)

チェックのためのコマンドは、named.conf とゾーンファイルでは異なっており、named.conf のチェックを行う場合は、「named-checkconf 」、ゾーンデータをチェックする場合は、「named-checkzone」です。コマンドを実行して何も表示されない場合は、文法が正常であることを示しています。

◎named.conf の文法チェック

# named-checkconf

◎ゾーンデータの文法チェック

# named-checkzone kororo.jp.zone /var/named/kororo.jp.zone
zone kororo.jp.zone/IN: loaded serial 20031220
OK

ゾーンデータの書式は、「named-checkzone [ ゾーン名 ]　[ ゾーンデータのファイル名 ] 」です。「OK」と表示されれば文法は正確に記述されています。

TOPに戻る