外部名の名前検索を実行するように構成されたフォワーダー、条件付きフォワーダー、またはルート ヒントがあります。 ただし、 nslookup または Resolve-DnsNameを使用して、クライアントからの外部名を解決することはできません。 この記事では、ドメイン ネーム システム (DNS) フォワーダー関連の名前解決エラーのトラブルシューティング方法について説明します。
症状の分析
名前を解決できないクライアントが外部か内部かを確認します。
問題が内部ドメインまたは外部名に固有の場合、この情報は DNS サーバー上のドメイン固有の構成を確認するのに役立ちます。すべてのクライアントが問題に直面しているか、特定のクライアントのみが問題に直面しているかどうかを確認します。
これにより、問題が DNS 転送サーバーに固有であるかどうかを特定するのに役立ちます。DNS サーバーを確認します。
- クライアントから名前解決が失敗した場合は、構成されている優先 DNS サーバーからも名前解決が失敗するかどうかを確認します。
- DNS サーバー自体から解決が失敗するかどうかを確認します。 その場合は、クライアントまたはクライアントと DNS サーバーの間のネットワークに関する問題を除外できます。
トラブルシューティング フローチャート
トラブルシューティングの手順
手順 1: クライアントと DNS サーバー間のネットワーク接続を確認する
DNS 構成を確認します。 クライアントで
ipconfig /allを実行し、正しい DNS サーバー IP が構成されていることを確認します。 正しくない場合は、次のコマンドを使用して構成します。Set-DnsClientServerAddress -InterfaceAlias "Interface-Name" -ServerAddresses ("IP1")UDP ポート 53 通信を確認します。 クライアントと DNS サーバー間の UDP ポート 53 通信が許可されていることを確認します。
基本的なネットワーク接続を確保するために、クライアントから DNS サーバーへの ping テストを実行します。その逆も同様です。
手順 2: DNS サーバーの構成を確認する
ローカルではない名前をそれ自体に解決できるように、この DNS サーバーが正しく構成されているかどうかを検証するには、次の手順に従います。
対象のドメインに対して条件付きフォワーダーが構成されているかどうかを確認します。
Get-DnsServerZone -Name <domainname>条件付きフォワーダーが見つからない場合は、一般的なフォワーダーが構成されているかどうかを確認します。
Get-DnsServerForwarderUseroothintsが TRUE に設定されていることを確認します。
フォワーダーが構成されていない場合は、ルート ヒントを確認します。
Get-DnsServerRootHint
いずれも構成されていない場合、名前解決は失敗する必要があります。 内部ドメインの場合は条件付きフォワーダーの作成に進む必要があります。外部ドメインの場合はフォワーダーを作成する必要があります (できれば)。
Note
条件付きフォワーダーまたは DNS サーバーであるフォワーダーは、名前のレコードを持っているか、名前を解決するように構成する必要があります。
手順 3: DNS サービスの状態と接続を確認する
DNS サーバー サービスが転送 DNS サーバーとフォワーダー DNS サーバーの両方で実行されていることを確認します。
Get-Service -Name DNSサービスが実行されていない場合は、次の手順を実行します。
Start-Service -Name DNSDNS 転送サーバーとフォワーダー サーバー間の UDP ポート 53 通信が許可されていることを確認します。
手順 4: ネットワーク キャプチャを収集して DNS パケットを追跡する
クライアント コンピューターでネットワーク キャプチャを実行する前に、常に DNS クライアント側キャッシュをクリアすることをお勧めします。
ipconfig /flushdns
次の手順を使用して、ネットワーク キャプチャを収集します。
- クライアント、DNS サーバー、フォワーダーでネットワーク キャプチャ ツール (Wireshark など) を起動します。
- クライアントで
nslookup <name>を実行して、エラーを再現します。 - キャプチャを停止し、トレースを確認します。 UDP ポート 53 をフィルター処理して、関連する DNS トラフィックを表示します。
シナリオを分析します。
次のセクションでは、発生する可能性があるいくつかのシナリオを示します。 これらのシナリオには条件付きフォワーダー構成が含まれますが、標準的なフォワーダーを処理する場合のトラブルシューティング手順は同じです。
シナリオ 1: ネットワーク待機時間またはタイムアウト
DNS ネーム サーバー 192.168.10.10 は、最初のフォワーダー 192.168.5.5 にクエリを転送します。 ネットワーク待機時間または中間ネットワークの問題により、応答は ForwarderTimeout 期間内に DNS サーバーに到達しません。 そのため、DNS サーバーは、クエリを構成された次のフォワーダー (192.168.5.6) に転送します。 ここでも、待機時間または中間ネットワークの問題により、応答が DNS サーバーに到達しません。 DNS サーバーはクエリ nodeA.contoso.comの応答をフェッチできないため、クライアントに "サーバーエラー" 応答を送信します。
解決策: ネットワーク チームと共同作業して待機時間に対処します。 待機時間が予想される場合は、条件付きフォワーダーからの応答を待機するのに十分な時間が DNS サーバーに与えられていることを確認してから、 ForwarderTimeout と RecursionTimeout 期間を長くしてタイムアウトします。
これを行うには、「 NET: DNS: フォワーダーと条件付きフォワーダーの解決タイムアウトを参照してください。
シナリオ 2: フォワーダーによって拒否されたクエリ
DNS ネーム サーバー 192.168.10.10 は、条件付きフォワーダー 192.168.5.5 にクエリを転送します。 このサーバーで、特定のレコードまたはゾーンに対するクエリを拒否または拒否するように構成されているポリシーがある場合、条件付きフォワーダーは転送 DNS ネーム サーバーに "拒否" 応答で応答します。 これで、DNS サーバーはこのエラーをサーバー障害としてクライアントに転送します。 DNS サーバーは、最初の条件付きフォワーダーから既に応答を受け取ったため、2 番目の条件付きフォワーダーに接続しません (エラー応答であっても)
解決策: フォワーダーが Microsoft Windows DNS サーバーの場合は、条件付きフォワーダーで構成されている DNS クエリ解決ポリシーを調べて、ゾーン fab.com または特定のレコード ( NodeA.fab.com など) のクエリを "拒否" します。 コマンド get-dnsserverqueryresolutionpolicyを使用して、構成済みのポリシーの一覧を取得できます。 これを行うには、 Get-DnsServerQueryResolutionPolicy を参照してください。
そのようなポリシーを配置すべきではない場合は、それらを削除して問題を解決してください。
サードパーティの DNS サーバーの場合は、それぞれのベンダーにお問い合わせください。
シナリオ 3: フォワーダーにレコードがない
DNS ネーム サーバー 192.168.10.10 は、クエリを最初の条件付きフォワーダー 192.168.5.5 に転送します。 条件付きフォワーダーには、fab.com ゾーンの下にNodeA名前のホスト A レコードがありません。 この場合、条件付きフォワーダーは"名前エラー" 応答で DNS サーバーに応答します。 その後、DNS サーバーは同じ応答をクライアントに転送します。 DNS サーバーは、最初のフォワーダーから既に応答を受け取ったので、ここで 2 番目の条件付きフォワーダーに接続しません。 通常、このシナリオが発生した場合、特定の名前に対して解決が失敗するという現象が発生します。必ずしも、 fab.com ドメインのすべての名前であるとは限りません。
解決策: 問題のゾーンのフォワーダーに不足しているレコードを静的または動的に登録します。
データ収集
Microsoft サポートからのサポートが必要な場合は、Microsoft サポートに連絡する前に問題に関する情報を収集することをお勧めします。
- トラブルシューティング ツールセット (TSS) に関するページに記載されている手順に従って、TSS ツールを使用してログをダウンロードして収集します。
- 影響を受けるコンピューターでログ収集を有効にするには、次のコマンドを実行します。
DNS サーバーの場合:
.\TSS.ps1 -Scenario NET_DNSsrvDNS クライアントの場合:
.\TSS.ps1 -Scenario NET_DNScli