この節では、一般的な DNS の問題とその対策を説明します。
「症状」
DNS クライアントは、IP アドレスかホスト名でマシンを見つけられますが、サーバーは IP アドレスでしか見つかりません。
「考えられる原因と対策」
サーバーの nsswitch.conf ファイルの hosts 行から DNS を省略したために発生する可能性があります。たとえば、不完全な hosts 行は、次のようになります。
host:files |
DNS を使用中には、次のどちらかのように、すべてのマシンの nsswitch.conf ファイルの hosts レコード内に dns を含む必要があります。
hosts: dns nisplus [NOTFOUND=return] files |
hosts: nisplus dns [NOTFOUND=return] files |
「症状」
マシンまたはサーバーを追加または削除しても、変更が認識されず、その効果が現れません。またはある時は変更が認識され、別の時にはその効果が現れません。
「考えられる原因」
考えられる原因は、主マスターサーバー上の SOA のシリアル番号を増やすのを忘れた場合です。新しい SOA 番号がないので、主サーバーのものと一致させるためのデータ更新を副サーバーは行いません。このため、古い未変更のデータファイルで作業を行なっています。
この他に考えられる原因は、1 つ以上の主要なデータファイルの SOA のシリアル番号が、副サーバー上の対応するシリアル番号よりも小さい値に設定されたということです。たとえば、この状態は、主サーバー上のファイルを削除してから、ある種の入力ファイルを使って最初からそれを作成し直した場合に発生します。
考えられる 3 番目の原因は、主サーバーのデータファイルへの変更を行なった後に、HUP 信号を主サーバーに送信し忘れた場合です。
「診断と対策」
最初に、変更したデータファイルの SOA のシリアル番号と副サーバー上の対応するファイルをチェックします。
主ファイルの SOA のシリアル番号が、副ファイルのシリアル番号と同じか、またはそれ以下の場合には、主サーバーのファイルでシリアル番号を増加させて、副ファイルの番号よりも大きくなるようにします。たとえば、両方のファイルの SOA のシリアル番号が 37 の場合には、主サーバーのファイルの番号を 38 に変更します。次回、副サーバーが主サーバーをチェックすると、新しいデータがロードされます。主サーバーに、副サーバーへの転送を即座に強制するユーティリティがあります。これらユーティリティの 1 つがある場合には、主サーバーのチェックを待たずに副サーバーを更新できます。
最新の named nnnn restarted または、named nnn reloading nameserver エントリに対する syslog 出力をレビューします。そのエントリ用のタイムスタンプが、ファイルへの変更を終了した時間の前の場合には、サーバーを再起動するか、または、「in.named に DNS データを強制的に再読み込みさせる」で説明するとおりに新しいデータの読み取りを強制します。
「症状」
クライアントは完全指定名は検索できますが、短縮名は検索できません。
「考えられる原因と現象」
クライアントの /etc/resolv.conf ファイルで、ドメイン名の最後にスペースがないかをチェックします。スペースやタブはドメイン名の最後では許可されません。
「症状」
ゾーンのドメイン名の付いたデータは、ゾーンの主マスターサーバーからゾーンの副サーバーに正確に転送される一方で、リバースドメインデータは転送されません。つまり、副サーバーの host.rev ファイルが主サーバーから正確に更新されていません。
「考えられる原因」
副サーバーのブートファイルの構文エラー
「診断と対策」
副サーバーのブートファイルをチェックします。主サーバーのブートファイルの IP アドレスが、ホストデータに対するのと同じようにリバースゾーンエントリに対してリストされていることを確認してください。
たとえば、主サーバーの IP アドレスが、secondary in-addr.arpa レコードからなくなっているので、次のブートファイルは正しくありません。
; ; /etc/named.boot file for dnssecondary directory /var/named secondary doc.com 129.146.168.119 dnshosts.bakup secondary 168.146.129.in-addr.arpa doc.rev.bakup |
正しいファイルは次のようになります。
; ; /etc/named.boot file for dnssecondary directory /var/named secondary doc.com 129.146.168.119 dnshosts.bakup secondary 168.146.129.in-addr.arpa 129.146.168.119 doc.rev.bakup |
副サーバーがそのマスターから更新を得られないときは、「master unreachable」のメッセージをログに記録します。問題が修正されない場合には、副サーバーはゾーンを期限切れにして、クライアントからの要求への応答を停止します。これが発生すると、「server failed」のメッセージが表示されるようになります。
「症状」
問題が副サーバーにある場合には、一部のユーザーは、マスターから DNS 情報を獲得でき、問題なく操作できます。
「考えられる原因」
これらの問題に対して考えられる主な 2 つの原因は、副サーバーのブートファイル内のマスターに対する誤った IP アドレスとネットワーク障害があります。
「診断と対策」
副サーバーのブートファイルに、マスターに対する正しい IP アドレスがあるかをチェックします。次の行をチェックしてください。
secondary domain IPaddress hostsfile |
マスターの IP アドレスが、hosts ファイルで指定されたマスターに対するアドレスとマスターの実際の IP アドレスと一致することを確認してください。IP アドレスが誤っている場合には、それを修正してから副サーバーを再起動します。
マスターの IP アドレスが正しい場合には、マスターの IP アドレスを ping することによって、マスターが起動して、正しく実行中であることを確認します。たとえば、マスターを IP アドレス 129.146.168.119 に ping するには、次のように入力します。
% ping 129.146.168.119 -n 10 |
マスターが ping に応答しない場合には、それが起動して、正しく実行中であることを確認します。
マスターが実行中の場合には、ps を使って、それが named を実行中であることを確認します。named を実行していない場合には、再起動します。
マスターが named を正しく実行中の場合には、ネットワーク障害が発生している可能性があります。
「症状」
「考えられる原因」
主マスターサーバーの hosts.rev ファイルに PTR を持たないマシンでユーザーが作業をしています。
hosts.rev ファイル内のサブドメインがないか、または不正確な委任が行われています。
「診断と対策」
適切な hosts.rev ファイルをチェックして、ユーザーのマシンに対して PTR レコードがあることを確認します。たとえば、129.146.168.46 の 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 データを強制的に再読み込みさせる」で説明するとおりに、そのデータを再ロードします。
「症状」
次のような言い回しを伴ったコンソールまたは syslog のエラーメッセージは、たいてい DNS データとブートファイルの構文エラーによって発生します。
関連ファイルでスペルと構文のエラーをチェックしてください。
一般的な構文エラーは、ドメイン名で後ろに付く点 (ドット) の誤用 (禁じられている場合に使い、必要な場合に使わないなど) に起因します。「ドメイン名の終わりにつけるドット」を参照してください。