次の方法で共有

DNS トラブルシューティング のガイダンス

  • [アーティクル]

仮想エージェントを試す - 一般的な DNS の問題をすばやく特定して修正するのに役立ちます。

このソリューションは、ドメイン ネーム システム (DNS) シナリオのトラブルシューティングに役立つよう設計されています。 DNS トラブルシューティングの問題をサーバー側とクライアント側のカテゴリに並べ替えることができます。

トラブルシューティング チェックリスト

サーバー側の問題

  • IP 構成
  • DNS サーバー
  • 権限のあるデータ
  • 再帰
  • ゾーン転送

クライアント側の問題

  • IP 構成
  • ネットワーク接続

共通の問題と解決策

DNS クライアントでの DNS クライアント側キャッシュのサポート ポリシー

Windows には、クライアント側の DNS キャッシュが含まれています。 DNS クライアントで DNS クライアント側キャッシュを無効にしないことをお勧めします。 DNS クライアント側のキャッシュが無効になっている構成はサポートされていません。

Microsoft では、サポートされていないデバイスまたは構成に関連する問題に対して解決が見つかるという保証はありません。 解決策が見つからない場合、インシデントに対する調査のコストは払い戻されません。 ソリューションが保証されていないことが合意されていない場合、Microsoft サポートは問題を解決せず、インシデント調査のコストを払い戻します。

DNS ゾーンに DNS レコードがありません

この問題には、次のいずれかの原因が考えられます。

DNS の清掃が正しく構成されていません

DNS レコードが DNS ゾーンに存在しない場合は、清掃が最も一般的な原因です。 静的に割り当てられた DNS サーバーを持つ Windows ベースのコンピューターでも、24 時間ごとにレコードが登録されます。 更新なし間隔と更新間隔が低すぎるかどうかを確認します。 たとえば、これらの値がどちらも 24 時間未満の場合、DNS レコードは失われます。

この問題のトラブルシューティングを行い、更新と更新の間隔を理解するには、「 DNS のエージングと清掃の使用」を参照してください。

IP アドレスが変更されると、ホスト "A" レコードが削除されます

ホスト "A" レコードが新しく構成された DNS サーバー IP アドレス (Active Directory 統合 DNS) に登録された後、ホスト "A" レコードが元の DNS サーバーで削除されることがあります。 ユーザーの観点からは、名前解決に依存するものは何でも壊れています。 クライアントで DNS サーバーの IP アドレスが変更されると、クライアントは機関の開始 (SOA) 更新を送信して、前の DNS サーバーから "A" レコードを削除します。 次に、"A" レコードを新しい DNS サーバーに登録する別の更新プログラムを送信します。

この問題は、Active Directory 統合ゾーンで発生します。 クライアントで DNS サーバーの IP アドレスが変更されると、問題が発生します。 IP アドレスが変更されると、クライアントは登録要求を新しいサーバーに送信し、削除要求を前のサーバーに送信します。 両方のサーバーが既に同期されているため、レコードは登録されません。 前のサーバーでは、DNS サービスによって "A" レコードが削除され、削除が新しいサーバーにレプリケートされます。 その結果、レコードは両方のサーバーで削除されます。

DHCP オプション 81 を使用する DHCP クライアントは、ホスト "AAAA" 登録中にホスト "A" レコードを登録解除します

この問題は、DHCP クライアント コンピューターが ISATAP または 6to4 ネットワーク アダプターを使用し、DNS クライアントと DNS サーバーの両方が DNS レコードを動的に更新するように構成されている場合に発生します。 この構成により、DHCP オプション 81 ( クライアント FQDN オプションとも呼ばれます) は、クライアントとサーバーの両方で有効になります。 このような場合、DHCP サーバーはクライアントの DNS "A" レコード (IPv4) を作成する可能性があります。 その後、クライアントは "AAAA" (IPv6) レコードを作成します。 ただし、この操作の一環として、クライアントは最初に、有効期間 (TTL) が 0 の更新された "A" レコードを送信します。 その結果、DNS サーバーはクライアントの "A" レコードを削除し、"AAAA" レコードを登録します。

この動作を回避するには、DHCP サーバーが既に構成されている場合に、これらのアダプターを使用して DNS レコードを動的に更新する DHCP クライアントを構成しないようにします。

注:

DHCP オプション 81 の詳細については、「 DHCP サーバーで "常に動的に DNS レコードを更新する" を使用している場合の予期しない DNS レコードの登録動作」を参照してください。 この記事では、別の問題について説明しますが、DHCP オプション 81 の詳細について説明します。

既存の DNS レコードへの DNS 動的更新プロトコルの更新が失敗する

既存のレコードに対する DNS 動的更新プロトコルの更新が失敗します。 この問題のため、DNS 清掃プロセスではレコードが期限切れであると見なされ、削除されます。

SRV レコードを必要とするサービスの場合、ローカル Netlogon サービスは、SRV レコードを登録できない場合に"イベント ID 577X" イベントをログに記録します。 たとえば、ドメイン コントローラーの Netlogon サービスが LDAP SRV レコードの動的更新をトリガーし、その更新が失敗した場合、Netlogon サービスはドメイン コントローラーでイベントをログに記録します。 ホスト "A" レコードと PTR レコードの登録エラーに関するその他のイベントがログに記録されます。 DNS サーバーとその他の影響を受けるコンピューターのシステム イベント ログで、これらのエラーを確認します。 これらのレコードを登録するクライアントは、このようなイベントをログに記録するか、クライアントの代わりにレコードを登録する DHCP サーバーがログに記録する可能性があります。 これらの追加イベントは、エラーの原因に関する分析情報を提供できます。

アクティブな動的リースを予約に変換すると、そのクライアントの "A" レコードと PTR レコードが削除されます

この動作は仕様です。 DNS レコード ("A" または PTR) は、クライアントからの次の DHCP 更新要求中に自動的に更新されます。

不要なネットワーク アダプターを DNS に登録しないようにする

ネットワーク アダプターが DNS に接続アドレスを登録するように構成されている場合、DHCP/DNS クライアント サービスは DNS にレコードを登録します。 コンピューターに登録しないネットワーク アダプターがある場合は、次の手順に従います。

  1. [ネットワーク Connections] で、不要なネットワーク アダプターのプロパティを開き、TCP/IP プロパティを開き、[高度な>DNS] を選択して、[この接続アドレスを DNS に登録する] チェック ボックスをオフにします。
  2. 左側のウィンドウで、DNS サーバー コンソールを開き、サーバーを強調表示して、[ アクション>のプロパティ] を選択します。
  3. [ インターフェイス ] タブで、 次の IP アドレスのみをリッスンするを選択します。 不要な IP アドレスを一覧から削除します。
  4. [ ゾーン のプロパティ] ページで、[ ネーム サーバー ] タブを選択します。このタブには、ドメイン コントローラーの FQDN に加えて、ドメイン コントローラーに関連付けられている IP アドレスが一覧表示されます。 不要な IP アドレスが一覧表示されている場合は削除します。
  5. ドメイン コントローラーの既存の不要なホスト "A" レコードを削除します。

DNS クエリ応答の遅延

DNS サーバーが到達できないフォワーダーまたはルート ヒントにクエリを転送すると、DNS クエリ要求がタイムアウトすることがあります。 この問題をトラブルシューティングするには、次の手順に従います。

  1. DNS サーバーで DNS コンソールを開き、フォワーダーまたは条件付きフォワーダーに到達できるかどうかをチェックします。 フォワーダーのいずれかに到達できない場合は、それらを削除します。
  2. DNS サーバーでフォワーダーとルート ヒントを使用する必要がない場合は、DNS サーバーで DNS コンソールを開き、サーバーの [プロパティ ] ウィンドウを開き、[ 詳細設定] を選択してから、[ 再帰の無効化] をオンにします。 (この設定ではフォワーダーも無効になります)。

イベント ID 4004 とイベント ID 4013

イベント メッセージ:

DNS サーバーが Active Directory を開くことができませんでした。 この DNS サーバーはディレクトリ サービス情報を使用するように構成されており、ディレクトリにアクセスしないと動作できません。 DNS サーバーは、ディレクトリの起動を待機します。 DNS サーバーが起動されていても、適切なイベントがログに記録されていない場合、DNS サーバーはディレクトリの起動を待機しています。

この問題をトラブルシューティングするには、「 AD DS のトラブルシューティング」を参照し、DNS サーバー サービスを再起動します。

DNS サーバーの地理的な場所のポリシーが期待どおりに機能しない

次のような状況で問題が発生します。

  • "contoso.com" という名前の Active Directory 統合ゾーン (既定のゾーン スコープ) を使用します。
  • 特定のサブネットに関連付けられている geo ロケーション ゾーン スコープを使用します。
  • Windows PowerShell Add-DnsServerQueryResolutionPolicy コマンドレットを使用して、DNS 解決ポリシーを構成します。

このシナリオでは、クライアントが要求されたリソースを最初にローカル ゾーン スコープで検索し、次に既定のゾーン スコープで検索しようとします。 ただし、organizationでこれらのポリシーを構成した後、定義されたサブネットのクライアントは、既定のゾーン スコープ (contoso.com) でホストされているレコードを正常に解決できません。 たとえば、クライアントは hostA.contoso.com を解決できません。 DNS サーバーは、このような要求を受信すると、"サーバー エラー" メッセージを返します。

この問題をトラブルシューティングするには、「 DNS サーバーの地理的な場所のポリシーが期待どおりに機能しない」を参照してください。

デュアルスタック クエリで転送された DNS 名解決が失敗する

サード パーティの DNS サーバー ソリューションを使用しており、条件付き転送を使用するときに名前を一貫して解決することはできません。

ローカル DNS サーバー (10.100.100.70) は、条件付きフォワーダー (10.133.3.250) として構成されている DNS サーバーに接続できます。 DNS サーバーから条件付きフォワーダーへの最初の要求では、名前 (たとえば、nbob1.contoso.com) が正常に解決されます。 しばらくすると、名前解決が機能しなくなります。 条件付きフォワーダーに対する nslookup クエリは、"存在しないドメイン" というエラー メッセージを返します。

転送コンピューター (ローカル DNS サーバー) の DNS サーバー キャッシュをクリアすると、名前解決が再開されます。 ただし、この修正は一時的なものです。

この問題をトラブルシューティングするには、「 デュアルスタック クエリの転送 DNS 名解決が失敗する」を参照してください。

DNS サーバーの NIC チーミング構成が失われる

次のような状況で問題が発生します。

  • DNS サーバー コンピューターには、NIC チーミング構成で使用する複数のネットワーク アダプターがあります。
  • チーミング ネットワーク アダプターの IP アドレスをリッスンするように DNS サーバーを構成します。
  • DNS マネージャーの [DNS サーバーのプロパティ] ダイアログ ボックスの [ インターフェイス ] タブで、使用する IP アドレスを構成できます。

DNS サーバーを再起動すると、Windows によって設定が削除されます。 DNS サーバーは、すべての IP アドレスのリッスンを再度開始します。

この変更が発生すると、Windows は DNS サーバー イベント ログにイベント ID 410 を記録します。

制限付きインターフェイスの DNS サーバーの一覧には、サーバー コンピューターの有効な IP アドレスが含まれていません。 DNS サーバーは、コンピューター上のすべての IP インターフェイスを使用します。 DNS サーバーがリッスンする必要がある IP アドレスを確認およびリセットするには、[DNS マネージャー サーバーのプロパティ]、[インターフェイス] ダイアログ ボックスを使用します。 詳細については、オンライン ヘルプの「選択したアドレスでのみリッスンするように DNS サーバーを制限するには」を参照してください。

この問題をトラブルシューティングするには、「 DNS サーバーが、構成された NIC チーミング IP アドレスではなく、すべての IP アドレスをリッスンするように戻す」を参照してください。

DHCP サーバーが動的 DNS 更新を管理する場合の DNS レコード登録の動作

Windows 動的ホスト構成プロトコル (DHCP) クライアントと Microsoft DHCP サーバーを使用して IP アドレスを割り当て、管理するインフラストラクチャがあります。 DHCP サーバーでは、 以下の設定に従って [DNS 動的更新を有効にする] と [ 常に動的に DNS レコードを更新する] を選択します。 この構成では、DHCP サーバーが "A" レコードと "PTR" レコードの動的 DNS 更新を管理することを想定しています。 ただし、クライアントとサーバーの両方で DNS レコードが作成されます。 構成に応じて、この動作には次の効果があります。

  • セキュリティで保護されていない動的更新の DNS ゾーンを構成すると、DHCP サーバーによってレコードが作成され、DHCP クライアントによって同じレコードが削除されて再作成されることがわかります。
  • 動的更新のみをセキュリティで保護するように DNS ゾーンを構成すると、DNS レコードに不整合が生じる可能性があります。 DHCP サーバーと DHCP クライアントの両方でレコードが作成されます。 ただし、DHCP サーバーは DHCP クライアントが作成したレコードを更新できません。また、DHCP クライアントは DHCP サーバーによって作成されたレコードを更新できません。

この問題をトラブルシューティングするには、 DHCP サーバーが "常に動的に DNS レコードを更新する" に設定されている場合の DNS レコード登録の動作に関するページを参照してください。

データ収集

Microsoft サポートに連絡する前に、問題に関する情報を収集できます。

前提条件

  • ローカル システムに対する管理者権限を持つアカウントのセキュリティ コンテキストで TSS を実行します。 TSS を初めて実行するときは、EULA に同意します。 (EULA に同意した後、TSS から再度メッセージが表示されることはありません)。
  • スコープで LocalMachine PowerShell 実行ポリシーをRemoteSigned使用することをお勧めします。

注:

現在の PowerShell 実行ポリシーで TSS の実行が許可されていない場合は、次のアクションを実行します。

  1. コマンドレット Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSignedをRemoteSigned実行して、プロセス レベルの実行ポリシーを設定します。
  2. 変更が有効であることを確認するには、コマンドレットを実行します Get-ExecutionPolicy -List 。

これらのプロセス レベルのアクセス許可は、現在の PowerShell セッションにのみ適用されます。 TSS が実行されている PowerShell ウィンドウを閉じると、プロセス レベルに割り当てられたアクセス許可が以前に構成された状態に戻ります。

Microsoft サポートに連絡する前に重要な情報を収集する

  1. すべてのノードで TSS をダウンロードし、ファイルを C:\tss フォルダーに展開します。

  2. 管理者特権の PowerShell コマンド プロンプト ウィンドウで C:\tss フォルダーを開きます。

  3. 次のコマンドレットを実行して、クライアントとサーバーでトレースを開始します。

    • クライアント：

      TSS.ps1 -Scenario NET_DNScli

    • サーバー：

      TSS.ps1 -Scenario NET_DNSsrv

  4. トレースがサーバーまたはクライアントで初めて実行される場合は、EULA に同意します。

  5. 記録を許可する (PSR またはビデオ)。

    注:

    クライアントとサーバーの両方でログを収集する場合は、問題を再現する前に、このメッセージが両方のノードに表示されるのを待ちます。

  6. 問題を再現します。

  7. 問題を再現したら、「 Y 」と入力して、データのログ記録を完了します。

TSS は、 C:\MS_DATA フォルダー内の圧縮ファイルにトレースを格納します。 分析のためにファイルをワークスペースにアップロードできます。

関連情報