DNSの動作確認とセカンダリサーバ：BINDで作るDNSサーバ（3）
前回設定したBINDは正しく動作しているだろうか？ 今回は動作確認の方法と、BINDをセカンダリサーバにする場合の設定を紹介する。
ネットワークの動作確認
前回では、ホスト名とIPアドレスの対応などを設定しました。間違いなく動いていれば問題はないのですが、1度できちんと動くとは限りません。うまく動かない場合は、いろいろと試行錯誤を繰り返していくことになります。
まず真っ先に確認するのは、きちんと外部のネットワークにつながっているかどうかです。pingコマンドやtracerouteコマンドなどで確認します。例えばpingコマンドなら、
$ ping -c 211.2.252.66
などで
PING 211.2.252.66 (211.2.252.66): 56 data bytes 64 bytes from 211.2.252.66: icmp_seq=0 ttl=238 time=34.504 ms 64 bytes from 211.2.252.66: icmp_seq=1 ttl=238 time=43.662 ms 64 bytes from 211.2.252.66: icmp_seq=2 ttl=238 time=34.942 ms 64 bytes from 211.2.252.66: icmp_seq=3 ttl=238 time=35.834 ms 64 bytes from 211.2.252.66: icmp_seq=4 ttl=238 time=36.500 ms --- 211.2.252.66 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 34.504/37.088/43.662/3.359 ms
といった表示が出ればOKです。
5 packets transmitted, 0 packets received, 100% packet loss
となったら、外部のネットワークにはつながっていません。このときは、同じセグメントにあるホストに対してpingコマンドを実行します。これでもうまくいかないときは、そもそもネットワークにきちんとつながっていないのです。ケーブルがきちんと接続されているか、NICがきちんと装着されているかどうかから確認します。コネクタが外れかけていたり、ケーブルが踏まれて断線したりという可能性もあります。
同じセグメントのホストとは通信できる場合、デフォルトゲートウェイなどの設定を間違えているか、忘れている可能性があります。linuxconfコマンドや、/etc/init.d/networkファイルなどを見直してみましょう。
このようにして、IPアドレスによるネットワークアクセスがきちんとできるようになったら、ようやくBINDそのものの設定を見直す段階になります。
設定ファイルの見直し
基本は設定ファイルの見直しです。SOAレコードの括弧やAレコード、PTRレコードのピリオドを忘れるといったところが間違えやすい部分です。ただ、自分で書いた設定ファイルというのは、意外と間違いを見つけにくいもの。できれば、ほかの人にチェックしてもらうといいでしょう。
それでもミスが見つからないときには、データベースダンプを使います。root権限を持ったユーザーとして、BINDにINTシグナルを送ると、キャッシュしたものも含めて記憶しているデータを/etc/namedb/named_dump.dbに書き出します。これを見ることで、実際にBINDが把握しているデータを検討しましょう。きちんと動いている場合のデータは、こうなります。
リスト1 named_dump_ok.db
ここで、例えばnamed.rev（逆引きファイル）でuranus（登録されているホスト）に対するPTRレコードで最後のピリオドを忘れたとします。すると、
リスト2 named_dump_ng.db
となります。注目すべきは、
88 86400 IN PTR saturn.atmarkit.co.jp. ;Cl=6 89 86400 IN PTR uranus.atmarkit.co.jp.80.1.168.192.in-addr.arpa. ;Cl=6
の部分です。saturnの方は「jp.」で終わっていますが、uranusの方は余分な情報が付いています。このように、明らかに前後と表示が違うものがあれば、そこに関係した記述をチェックすればいいわけです。
さらに、BINDにはデバッグモードがあります。起動時に-dオプションを使うことで、BINDをデバッグモードで動かせます。このとき、デバッグレベルも指定できます。レベルが高くなるほどより多くの情報が得られます。が、最初は一番低いレベル1で十分でしょう。
$ kill -KILL 117 $ named -d 1
などとして、いったんBINDを止めてから、デバッグオプション付きで起動します。もちろん、killコマンドで指定するプロセス番号はpxコマンドなどで調べて、動いているnamedのものにします。最近のディストリビューションだと、/var/run/named.pidというファイルにBINDのプロセス番号が記録されていたりするので、
$ kill -KILL `cat /var/run/named.pid`
としてもいいかもしれません。これで、/etc/namedb/namedr.runにデバッグ用のログができます。
また、動作中のBINDをデバッグモードにするには、USR1シグナルを送ります。シグナルを送るたびにデバッグレベルが高くなっていきます。デバッグが終了したら、USR2シグナルを送ります。
$ kill -USR1 `cat /var/run/named.pid` $ ping -c 5 www.atmarkit.co.jp $ kill -USR2 `cat /var/run/named.pid`
としたときの結果が、次のとおりです。
Debug level 1
Version = named 8.2.2-P5 Wed Apr 12 17:54:07 JST 2000
kengo@rpm2:/home/kengo/src/redhat/BUILD/bind-8.2.2_P5/src/bin/named
conffile = /etc/named.conf
sysquery: send -> [192.168.1.85].53 dfd=4 nsid=32990 id=0 retry=981222092
sysquery: send -> [198.41.0.4].53 dfd=4 nsid=985 id=0 retry=981222092
Sent NOTIFY for "atmarkit.co.jp IN SOA" (atmarkit.co.jp); 1 NS, 1 A
datagram from [198.41.0.4].53, fd 4, len 273
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 985
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 6
;; ns-tk023.ocn.ad.jp, type = A, class = IN
JP. 2D IN NS DNS0.SPIN.AD.JP.
JP. 2D IN NS NS-JP.SINET.AD.JP.
JP. 2D IN NS NS.WIDE.AD.JP.
JP. 2D IN NS NS0.IIJ.AD.JP.
JP. 2D IN NS NS0.NIC.AD.JP.
JP. 2D IN NS NS-JP.NIC.AD.JP.
DNS0.SPIN.AD.JP. 2D IN A 165.76.0.98
NS-JP.SINET.AD.JP. 2D IN A 150.100.2.3
NS.WIDE.AD.JP. 2D IN A 203.178.136.63
NS0.IIJ.AD.JP. 2D IN A 202.232.2.34
NS0.NIC.AD.JP. 2D IN A 202.12.30.131
NS-JP.NIC.AD.JP. 2D IN A 61.120.151.100
resp: nlookup(ns-tk023.ocn.ad.jp) qtype=1
resp: found 'ns-tk023.ocn.ad.jp' as 'ad.jp' (cname=0)
resp: forw -> [202.12.30.131].53 ds=4 nsid=21568 id=0 4ms
datagram from [202.12.30.131].53, fd 4, len 125
sysquery: send -> [203.139.160.105].53 dfd=4 nsid=28099 id=0 retry=981222094
Sent NOTIFY for "80.1.168.192.in-addr.arpa IN SOA" (80.1.168.192.in-addr.arpa); 1 NS, 1 A
datagram from [203.139.160.105].53, fd 4, len 43
resend(addr=0 n=1) -> [192.168.1.85].53 ds=4 nsid=32990 id=0 -1ms
resend(addr=0 n=2) -> [192.168.1.85].53 ds=4 nsid=32990 id=0 -1ms
Debug off
ただし、この情報を読み取るには、それなりに知識と経験が必要になります。
セカンダリサーバの設置と設定
DNSは、現代のインターネットにおいてその根幹をつかさどっています。DNSサーバが止まると、事実上インターネットにおけるアクセスがまひしてしまいます。そこで、予備のサーバとして準備するのがセカンダリサーバです。
その目的からして、セカンダリサーバはプライマリサーバと同じネットワークセグメントにあるのでは無意味です。というのも、そのネットワークセグメントが外部から切り離されてしまったとき、外からDNSサーバにアクセスできなくなってしまうからです。最低でも別のネットワークセグメント、できれば完全に別のネットワークに設置したいところです。OCNエコノミーなどでは、ISP側にセカンダリサーバを設置してもらえます。このように、ISPに設置してもらえるなら管理の手間も省けて、一石二鳥です。
このときに注意するのは、/etc/named.confに記述する逆引き用のzone情報です。自宅にOCNエコノミーを引いた当初、筆者はこれを間違えてデータの転送に失敗しました。割り振られたIPアドレスはx.y.z.80/28だったのですが、うっかり
zone "1.z.y.x.in-addr.arpa" {
type master;
file "named.rev";
}
としてしまったのです。正確には、
zone "80.z.y.x.in-addr.arpa" {
type master;
file "named.rev";
}
となります。このあたりは、割り振られたIPアドレスによっても違うので、ISP側に確認をとった方が確実です。
自前でセカンダリサーバを設置する場合は、/etc/named.confでzoneの設定を書き換えます。プライマリサーバで
zone "atmarkit.co.jp" {
type master;
file "named.hosts";
};
zone "80.1.168.192.in-addr.arpa" {
type master;
file "named.rev";
};
となっているところを、
zone "atmarkit.co.jp" {
type slave;
masters 192.168.1.82;
};
zone "80.1.168.192.in-addr.arpa" {
type slave;
masters 192.168.1.82;
};
と書き換えます。type slaveがセカンダリサーバであることを意味し、mastersでコピーすべきデータを持っているサーバのIPアドレスを指定します。これはプライマリサーバである必要はなく、セカンダリサーバでもよいため、両者を併せてマスターサーバと呼んでいます。これに合わせてnamed.hostsとnamed.revは不要になります。ただ、localhostに関しては変わりないので、マスターサーバから転送するよりも、ローカルにファイルとして持っていた方がいいでしょう。
セキュリティに注意
連載1回目でセキュリティホールに関して触れました。実際、スタックオーバーフローに関する問題など、2001年2月3日現在でバージョン8.2.2p7までに幾つかのセキュリティホールが確認されています。まだ8.2.3以前のバージョンを使っている方は、最新版である8.2.3のソースコードを持ってきてコンパイルするか、各ディストリビュータのサイトから該当するパッケージをダウンロードしましょう。
さらに、ルータの持っているパケットフィルタリング機能を併用するといいかもしれません。外部ネットワークからDNSへの問い合わせがあるのは、本質的には上位のDNSサーバからだけです。ポート番号は53ですから、ルータのログを調べて該当するホストからのパケットだけを通過させるようにすればよいのです。上位ホストを特定するのが面倒ですし、そのIPアドレスが変わるたびにルータの設定を変える必要があるので面倒ですが……。
Copyright © ITmedia, Inc. All Rights Reserved.