第 6 章 DNS の障害追跡 (参照情報)
この章では、DNS に関する一般的な問題とその解決方法について説明します。
クライアントは名前でマシンを見つけられるが、サーバーは見つけられない
「症状」
DNS クライアントは、IP アドレスかホスト名でマシンを見つけられますが、サーバーは IP アドレスでしか見つけることができません。
「考えられる原因と対策」
サーバーの nsswitch.conf ファイルの hosts 行から DNS を省略したために発生する可能性があります。たとえば、不完全な hosts 行は、 hosts: files のようになります。
DNS の使用時は、各マシンの nsswitch.conf ファイルの hosts レコード内に dns を入れる必要があります。たとえば :
hosts: dns nisplus files |
または
hosts: nisplus dns files |
変更が反映されないか、その効果が一定しない
「症状」
マシンやサーバーを追加または削除しても、変更が認識されないか反映されません。あるいは、変更が認識されたり認識されなかったりします。
「考えられる原因」
考えられる最初の原因は、変更を加えた後にマスターサーバー上の SOA のシリアル番号を増やし忘れたことです。新しいSOA 番号がないので、スレーブサーバーはそのデータをマスターサーバーのデータと一致させるためのデータ更新を行いません。このため、古い未変更のデータファイルを使用しています。
この他に考えられる原因は、マスターサーバー上の 1 つ以上のデータファイルの SOA のシリアル番号が、スレーブサーバー上の対応するシリアル番号よりも小さい値に設定されたことです。この状態はたとえば、マスターサーバー上のファイルを削除してから、ある種の入力ファイルを使って最初から作成し直した場合に発生します。
考えられる 3 番目の原因は、マスターサーバーのデータファイルに変更を加えた後で、HUP 信号をマスターサーバーに送信し忘れたことです。
「診断と対策」
まず、変更したデータファイルの SOA のシリアル番号とスレーブサーバー上の対応するファイルをチェックします。
-
マスターサーバーのファイルの SOA シリアル番号がスレーブサーバーのファイルのシリアル番号と同じかそれ以下の場合は、マスターサーバーのファイルのシリアル番号を増やしてスレーブサーバーのファイルの番号よりも大きくなるようにします。たとえば、両方のファイルの SOA のシリアル番号が 37 の場合は、マスターサーバーのファイルの番号を 38 に変更します。次回、スレーブサーバーがマスターサーバーをチェックすると、新しいデータがロードされます。マスターサーバーに、スレーブサーバーへのデータ転送を即座に強制するユーティリティがあります。このユーティリティがある場合には、マスターサーバーのチェックを待たずにスレーブサーバーを更新できます。
-
最新の named nnnn restarted または、named nnn reloading nameserver エントリに対する syslog 出力を確認します。そのエントリのタイムスタンプが、ファイルへの変更を終了した時間よりも前の場合には、サーバーをリブートするか、in.named に DNS データを強制的に再度読み込ませるで説明しているように、新しいデータの読み取りを強制します。
DNS クライアントが短縮名を検索できない
「症状」
クライアントは完全指定名は検索できますが、短縮名は検索できません。
「考えられる原因と対策」
クライアントの /etc/resolv.conf ファイルで、ドメイン名の最後にスペースがないかをチェックします。スペースやタブはドメイン名の最後では使用できません。
逆ドメインデータがスレーブサーバーに正しく転送されない
ゾーンのドメイン名の付いたデータは、ゾーンのマスターサーバーからゾーンのスレーブサーバーに正しく転送されますが、逆ドメインデータは転送されません。つまり、スレーブサーバーの host.rev ファイルがマスターサーバーから正しく更新されていません。
「考えられる原因」
スレーブサーバーの起動ファイルの構文エラー
「診断と対策」
スレーブサーバーの起動ファイルをチェックします。マスターサーバーの IP アドレスが、ホストデータの場合と同じように、逆ゾーンエントリに対してリストされていることを確認してください。
サーバーが失敗してゾーンが期限切れになる
スレーブサーバーがそのマスターサーバーから更新を得られないときは、「master unreachable」というメッセージがログに記録されます。問題が修正されない場合、スレーブサーバーはゾーンを期限切れにして、クライアントからの要求への応答を停止します。この状況が発生すると、「server failed」というメッセージが表示されます。
「症状」
-
syslog に「Masters for slave zone domain unreachable」というメッセージが表示される
-
ユーザーに「*** domain Can't find name: server failed」というメッセージが表示される
問題がスレーブサーバーにある場合、一部のユーザーはマスターサーバーから DNS 情報を獲得できるため問題なく操作できます。
「考えられる原因」
これらの問題に対して考えられる主な原因は 2 つあります。1 つはネットワーク障害であり、もう 1 つはスレーブサーバーの起動ファイル内に指定したマスターサーバーの IP アドレスが間違っていることです。
「診断と対策」
-
スレーブサーバーの構成ファイルに、マスターサーバーの IP アドレスが正しく設定されているかどうか確認します。次の行をチェックしてください。
zone "someone" { type slave; file "somefile": master [IPaddress; }; };
hosts ファイルで指定したマスターサーバーの IP アドレスが実際の IP アドレスと一致することを確認してください。IP アドレスが間違っている場合は、それを修正してからスレーブサーバーをリブートします。
-
マスターサーバーの IP アドレスが正しい場合は、そのアドレスを ping して、マスターサーバーが正しく起動しているかどうかを確認します。たとえば、マスターサーバーを IP アドレス 192.168.0.1 で ping する場合は、次のように入力します。
% ping 192.168.0.1 -n 10
-
マスターサーバーが ping に応答しない場合は、マスターサーバーが正しく起動しているかどうかを確認します。
-
マスターサーバーが正しく起動している場合は、ps を使用して、マスターサーバーが named を実行しているかどうかを確認します。named を実行していない場合は、リブートします。
-
マスターサーバーが named を正しく実行している場合は、ネットワークに障害が発生している可能性があります。
rlogin、rsh、ftp の問題
「症状」
「考えられる原因」
-
ユーザーが作業しているマシンの PTR レコードがマスターサーバーの hosts.rev ファイルにありません。
-
hosts.rev ファイル内のサブドメインがないか、不正な委任が行われています。
「診断と対策」
該当するhosts.rev ファイルをチェックして、ユーザーのマシン用の PTR レコードが存在することを確認します。たとえば、192.168.0.1 の IP アドレスを持つマシン altair.doc.com で作業をしている場合は、doc.com マスターサーバーの doc.rev ファイルに次のようなエントリを追加する必要があります。
46 IN PTR altair.doc.com. |
レコードがない場合は、hosts.rev ファイルに追加してからサーバーをリブートするか、in.named に DNS データを強制的に再度読み込ませるの指示に従ってデータをロードし直します。
hosts.rev ファイルの NS エントリをチェックおよび修正してから、サーバーをリブートするか、in.named に DNS データを強制的に再度読み込ませるの指示に従ってデータをロードし直します。
その他の DNS 構文エラー
「症状」
次のような表現が含まれるコンソールまたは syslog のエラーメッセージは、たいてい DNS データや起動ファイルの構文エラーによるものです。
関連ファイルにスペルや構文のエラーがないかどうか チェックしてください。
一般的な構文エラーは、ドメイン名で後ろに付く点 (ドット) の誤用 (禁じられている場合に使い、必要な場合に使わないなど) に起因します。
- © 2010, Oracle Corporation and/or its affiliates