どのような問題がありますか。
DNS サーバーがクライアントに応答しません。
原因 : ドメイン ネーム システム (DNS) サーバーがネットワーク障害の影響を受けています。
解決方法 : サーバー コンピューターのネットワーク接続が正常に機能しているかどうかを確認します。まず、ネットワークとハードウェアの基本的なトラブルシューティング手順に従って、関連するクライアント ハードウェア (ケーブルおよびネットワーク アダプター) がクライアント側で正しく動作していることを確認します。
サーバー ハードウェアが正しく設置され、機能している場合は、影響を受けている DNS サーバーと同じネットワークで使用されていて利用可能な他のコンピューターやルーター (デフォルト ゲートウェイなど) に対し、ping を実行して、ネットワーク接続を確認します。
原因 : 基本的なネットワークのテストでは DNS サーバーに接続可能ですが、クライアントからの DNS クエリに応答しません。
解決方法 : DNS クライアントから DNS サーバー コンピューターに対して ping を実行できる場合は、DNS サーバーが起動されていて、クライアントの要求をリッスンしてそれに応答できるかどうかを確認します。nslookup コマンドを使用して、サーバーが DNS クライアントに応答するかどうかをテストします。
詳細については、「DNS サーバーを開始または停止する」を参照してください。
原因 : 構成されている IP アドレスのうち特定のアドレスの一覧にサービスを制限するように、DNS サーバーが構成されています。応答性のテストでもともと使用された IP アドレスは、この一覧に含まれていません。
解決方法 : クエリに応答する IP アドレスを制限するようにサーバーがもともと構成されていた場合は、クライアントがサーバーとの連絡に使用している IP アドレスが、クライアントにサービスを提供することを許可されている制限された IP アドレスの一覧に含まれていない可能性があります。
サーバーが応答するかどうか、もう一度テストします。ただし、今回は、サーバーの制限されたインターフェイス一覧に含まれていることがわかっている別の IP アドレスを指定します。DNS サーバーがそのアドレスに対して応答する場合は、不足しているサーバーの IP アドレスを必要に応じて一覧に追加します。
原因 : DNS サーバーは、自動的に作成された既定の逆引き参照ゾーンの使用を無効にするように構成されています。
解決方法 : 自動的に作成された逆引き参照ゾーンがそのサーバーに対して作成されていることを確認するか、またはサーバーに対して構成の詳細設定の変更が行われていないことを確認します。
既定では、DNS サーバーは、Request for Comments (RFC) 勧告に基づいて次の 3 つの標準逆引き参照ゾーンを自動的に作成します。
これらのゾーンは、逆引き参照検索では役立たないゾーンでカバーされる共通の IP アドレスを使用して作成されます (0.0.0.0、127.0.0.1、および 255.255.255.255)。これらのアドレスに対応するゾーンに対して権限を持つことによって、DNS サービスはルート サーバーへの不要な再帰を回避し、これらの種類の IP アドレスに対して逆引き参照が実行されないようにしています。
これらの自動的なゾーンが作成されないこともありますが、可能性は低いといえます。これは、これらのゾーンの作成を無効にするには、ユーザーがサーバー レジストリの詳細構成を手動で行う必要があるからです。
これらのゾーンが作成されていることを確認するには、次の手順を実行します。
-
DNS マネージャーを開きます。
-
[表示] メニューの [詳細設定] をクリックします。
-
コンソール ツリーで、[逆引き参照ゾーン] をクリックします。
場所 :
-
DNS/該当する DNS サーバー/Reverse Lookup Zones
-
DNS/該当する DNS サーバー/Reverse Lookup Zones
-
詳細ウィンドウで、次の逆引き参照ゾーンがあることを確認します。
-
0.in-addr.arpa
-
127.in-addr.arpa
-
255.in-addr.arpa
-
0.in-addr.arpa
原因 : セキュリティやファイアウォールが詳細に構成されている場合のように、DNS サーバーが、既定以外のサービス ポートを使用するように構成されています。
解決方法 : DNS サーバーが標準ではない構成を使用していないことを確認します。
この原因は、可能性は低いもののまったくないわけではありません。既定では、nslookup コマンドはユーザー データグラム プロトコル (UDP) ポート 53 を使用して、ターゲットの DNS サーバーにクエリを送信します。DNS サーバーが中間のホスト (たとえば、パケット フィルタリング ルーターやプロキシ サーバーなど) を介さなければ到達できない別のネットワークに存在する場合、DNS サーバーは非標準ポートを使用してクライアントの要求をリッスンし、受信することがあります。
この状況に該当する場合、中間のファイアウォールやプロキシ サーバー構成が、DNS に対して使用されている既知のサービス ポートのトラフィックを意図的にブロックするために使われていないか判断します。そうでない場合は、このようなパケット フィルターをこれらの構成に追加して、標準 DNS ポートへのトラフィックを許可できます。
また、DNS サーバー イベント ログを調べ、Event ID 414 などの重要なサービス関連イベントが発生していないかどうかを確認します。DNS サーバーが応答しない理由をこれらのイベントが示していることがあります。
DNS サーバーが名前を正しく解決しません。
原因 : DNS サーバーはクエリに応答しますが、無効なデータを提供します。
解決方法 : DNS サーバーのデータが無効である理由を判断します。
最も可能性の高い原因は次のとおりです。
-
リソース レコードがゾーンで動的に更新されていません。
-
ゾーンで静的リソース レコードを手動で追加または変更するときに、誤った操作をしました。
-
キャッシュされている参照またはゾーン レコードが最新の情報に更新されていないか、または不要になったときに削除されなかったために、DNS サーバー データベースに古いリソース レコードが残っています。
最も一般的な問題の発生を防止するには、最初にヒント集を確認して、DNS サーバーの展開と管理に関するヒントと指示を参照します。また、展開の要件に基づいて、DNS サーバーとクライアントのインストールおよび構成についての該当するチェックリストも参照します。
Active Directory ドメイン サービス (AD DS) に対して DNS を展開する場合は、新しいディレクトリ統合機能に注意します。これらの機能により、DNS データベースがディレクトリと統合される場合の DNS サーバーの既定の設定は、従来のファイル ベースの記憶域に対して使用される既定の設定と異なるものになる可能性があります。
多くの DNS サーバーの問題は、クライアントで失敗したクエリから発生しています。このため、多くの場合は、最初に DNS クライアントの問題をトラブルシューティングすることが適切です。
詳細については、「DNS クライアントのトラブルシューティング」を参照してください。
原因 : DNS サーバーが、直接接続されているネットワークの外部 (外部ネットワークやインターネット) にあるコンピューターやサービスの名前を解決しません。
解決方法 : 再帰を正しく実行する機能に関してサーバーに問題があります。ほとんどの DNS 構成では、DNS サーバーとクライアントが使用する構成済み DNS ドメイン名の内部にない名前を解決する場合、再帰が使用されます。
DNS サーバーが権限のない名前の解決に失敗した場合、その原因は通常、再帰クエリの失敗です。再帰クエリは、DNS サーバーが他の DNS ゾーンおよびサーバーに委任されたリモート名を解決する場合に頻繁に使用されます。
再帰が正常に機能するには、再帰クエリのパスで使用されるすべての DNS サーバーが応答し、正しいデータを転送できることが必要です。この条件が満たされない場合は、次のいずれかの理由で再帰クエリが失敗することがあります。
-
完了する前に、再帰クエリがタイムアウトになる。
-
リモートの DNS サーバーが応答しない。
-
リモートの DNS サーバーが無効なデータを提供する。
原因 : DNS サーバーは、クエリ解決の支援のために他の DNS サーバーを使用するように構成されていません。
解決方法 : DNS サーバーがフォワーダーと再帰の両方を使用できるかどうかを確認します。
既定では、すべての DNS サーバーは再帰を使用できるように設定されています。ただし、DNS マネージャーを使用してサーバーの詳細オプションを変更することで、再帰の使用を無効にするオプションも構成できます。また、サーバーがフォワーダーを使用するように構成されていて、その構成に対して再帰が無効に設定されている場合も、再帰は無効になります。
 | 注 |
|
DNS サーバーで再帰を無効にすると、その DNS サーバーではフォワーダーを使用できなくなります。 |
詳細については、「フォワーダーを使用するように DNS サーバーを構成する」を参照してください。
原因 : DNS サーバーの現在のルート ヒントが無効です。
解決方法 : サーバーのルート ヒントが有効かどうかを確認します。
正しく構成され使用されているルート ヒントは、ドメイン ルートとトップレベル ドメインを含むゾーンに対して権限のある DNS サーバーを常に参照します。
既定では、DNS サーバーは、DNS マネージャーでサーバーを構成するときの次の選択肢に基づき、目的の展開にとって適切なルート ヒントを使用するように構成されます。
-
DNS サーバーがネットワークの最初の DNS サーバーとしてインストールされる場合は、ルート サーバーとして構成されます。
この構成の場合、サーバーはルート ゾーンに対して権限があるので、ルート ヒントは無効になります。
-
インストールされているサーバーがネットワークの追加 DNS サーバーの場合は、DNS サーバーの構成ウィザードでネットワークの既存の DNS サーバーからルート ヒントを更新するように指定できます。
-
ネットワークに他の DNS サーバーがないにもかかわらず、インターネット DNS 名を解決する必要がある場合は、既定のルート ヒント ファイルを使用します。このファイルには、インターネット DNS 名前空間に対して権限のあるインターネット ルート サーバーの一覧が格納されています。
原因 : DNS サーバーにルート サーバーへのネットワーク接続がありません。
解決方法 : ルート サーバーへの接続をテストします。
ルート ヒントの構成が正しい場合は、失敗したクエリで使用された DNS サーバーからルート サーバーに対して IP アドレスを指定した ping を実行できるかどうかを確認します。
あるルート サーバーへの ping が失敗した場合は、そのルート サーバーの IP アドレスが変更されていることを示しています。ただし、通常はルート サーバーの再構成は行われません。
さらに可能性の高い原因として、ネットワーク接続が完全に切断されたか、または DNS サーバーと構成されているルート サーバーとの間にある途中のネットワーク リンクのネットワーク パフォーマンスが低いことが考えられます。基本的な TCP/IP ネットワークのトラブルシューティング手順に従って、接続を診断し、このような問題がないか判断します。
既定では、DNS サービスで使用される再帰クエリが失敗するまでの再帰タイムアウトは 15 秒です。通常のネットワークの状態では、このタイムアウトを変更する必要はありません。ただし、パフォーマンス上必要な場合は、この値を大きくしてもかまいません。
DNS クエリのパフォーマンスに関する詳細を確認するには、DNS サーバー デバッグ ログ ファイル Dns.log を有効にします。このファイルには、いくつかの種類のサービス関連イベントに関する広範な情報が格納されています。
原因 : ゾーンまたは動的更新に関連する問題など、DNS サーバー データの更新に関連する他の問題があります。
解決方法 : 問題がゾーンに関連しているかどうかを判断します。必要に応じて、ゾーンの転送の失敗の可能性など、この領域の問題をトラブルシューティングします。
詳細については、「動的更新のトラブルシューティング」および「ゾーンの問題のトラブルシューティング」を参照してください。
DNS サーバーがここには記述されていない問題の影響を受けています。
原因 : 問題はここでは説明されていません。
解決策 : この問題に関連する最新の技術情報については、TechNet (
インターネット接続を使用できる場合、オペレーティング システムの最新の更新プログラムを Microsoft Update (