第3回　DNSの動作確認とセカンダリサーバ

前回設定したBINDは正しく動作しているだろうか？ 今回は動作確認の方法と、BINDをセカンダリサーバにする場合の設定を紹介する。

関野史朗
2001/2/14

ネットワークの動作確認

　前回では、ホスト名と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

リスト3　named.run

　ただし、この情報を読み取るには、それなりに知識と経験が必要になります。

セカンダリサーバの設置と設定

　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アドレスが変わるたびにルータの設定を変える必要があるので面倒ですが……。

連載 BINDで作るDNSサーバ

---

Linux Squareフォーラム サーバ構築・運用関連記事

	連載：Heartbeatでかんたんクラスタリング（連載中） オープンソースソフトウェアの「Heartbeat」を使ってHAクラスタを実現し、サービスを「落とさない」仕組みを実現します
	特集：Apache 2.2でWebサイトをパフォーマンスアップ！ 最新安定版Apache 2.2は、何が変わったのか？ 最新のApacheを新機能の使い方とともに解説する
	連載：実用 Apache 2.0運用・管理術（全8回） 本連載では、Apache 2.0の運用や管理方法を解説する。まず必須設定と基本的なセキュリティ対策を行い今後の運用に備える
	連載：実用 BIND 9で作るDNSサーバ（全15回） 本連載では、BIND 9の構築／運用方法を解説していく。実際に役立つことを目的に、セキュリティや大規模運用などのテーマを取り上げていく
	連載：実用qmailサーバ運用・管理術（全14回） 本連載を通して、qmailによるメールサーバの高度な構築・運用・管理術を紹介。SPAM対策やML管理からサーバでのウイルスチェックなどまで
	特集：Samba 3.0の全貌 改訂版 Samba 3.0リリースから8カ月。ここであらためて、Samba 3.0系列の新機能、インストール方法、国際化の現状を解説する
	more

MONOist組み込み開発フォーラムの中から、Linux関連記事を紹介します

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）