ipconfig /displaydns は、DNS サーバーの「今の答え」を直接確認するコマンドではありません。Windows の DNS クライアントのリゾルバーキャッシュを表示するコマンドで、ローカルの Hosts ファイル由来のエントリと、過去の名前解決で取得したレコードを確認できます。つまり、DNS 切り替え後に一部の PC だけ古い IP を引く、特定端末だけ「名前が存在しない」と出る、といった「クライアント側に答えが残っているか」を切り分ける用途に強いコマンドです。(Microsoft Learn)
一方で、特定の DNS サーバーへ今どう返るかを見たいなら nslookup や Resolve-DnsName -Server のほうが適しています。全件ダンプではなく特定名だけローカルキャッシュで見たいときは Resolve-DnsName -CacheOnly や Get-DnsClientCache -Name を使うほうが早く、判断もぶれにくくなります。(Microsoft Learn)
ipconfig /displaydns は「クライアントの記憶」を見るコマンド
Windows の DNS Client サービスは、名前解決のたびに最初にローカルキャッシュを確認します。ローカルキャッシュには、Hosts ファイルのマッピングと過去の DNS 問い合わせ結果が入り、正の応答も負の応答も保存されます。ipconfig /displaydns を使うときは、「DNS サーバーが正しいか」を直接見るのではなく、「このクライアントが今、何を信じているか」を見るコマンドだと考えると、使いどころを誤りにくくなります。(Microsoft Learn)
まずはこの使い分けで迷わない
| 目的 | 向くコマンド | こう判断する |
|---|---|---|
| 影響が一台だけで、クライアント側の DNS キャッシュを疑う | ipconfig /displaydns / Get-DnsClientCache | ローカルキャッシュに古い答えや否定応答が残っていないかを見る |
| 特定の DNS サーバーが今どう返すか確認したい | nslookup <名前> <DNSサーバー> / Resolve-DnsName -Name <名前> -Server <IP> | キャッシュではなく、サーバーへの再問い合わせ結果で判断する |
| DNS 以外の名前解決を混ぜずに確認したい | Resolve-DnsName -DnsOnly | LLMNR や NetBIOS を切り離して DNS だけを見る |
| 対象名だけローカルキャッシュにあるか確認したい | Resolve-DnsName -CacheOnly / Get-DnsClientCache -Name <名前> | 全件ダンプを避けて、目的の名前だけ確認する |
| クライアントキャッシュを消したい | ipconfig /flushdns / Clear-DnsClientCache | 負のキャッシュや動的に追加されたエントリを捨てて再確認する |
ipconfig /displaydns と Get-DnsClientCache はローカルの DNS クライアントキャッシュを見る道具です。nslookup や Resolve-DnsName -Server は DNS サーバーへ再問い合わせする道具で、Resolve-DnsName -DnsOnly は LLMNR や NetBIOS を除外できます。ローカルキャッシュだけを一件ずつ確認するなら Resolve-DnsName -CacheOnly や Get-DnsClientCache -Name、キャッシュ削除は ipconfig /flushdns と Clear-DnsClientCache が役割分担です。(Microsoft Learn)
ipconfig /displaydns で本当に見るべきポイント
対象名がそもそも表示されるか
ローカルキャッシュは、Hosts ファイルの内容と過去の問い合わせ結果で構成されます。まだ問い合わせていない名前や、再現条件を満たしていない時点の名前は表示されないことがあります。ipconfig /displaydns に対象名が出ないだけで「DNS は正常」と決めつけず、まず症状を再現してから確認するのが基本です。(Microsoft Learn)
否定応答が残っていないか
Microsoft のトラブルシューティング資料でも、ipconfig /displaydns で失敗した名前の下に Name does not exist が見えるなら、DNS サーバーからの否定応答がクライアントにキャッシュされた状態だと説明されています。このケースは ipconfig /flushdns でいったん捨てられますが、再問い合わせしてすぐ同じ否定結果が戻るなら、根本原因はキャッシュそのものではなく、DNS サーバー側の応答やレコードの持ち方です。(Microsoft Learn)
TTL が長く残っていないか
DNS のキャッシュは TTL に従って保持されます。DNS レコードを切り替えた直後に、一部の端末だけ古い IP を引き続けるときは、ipconfig /displaydns で古いレコードが残っていないかを見る価値があります。DNS サーバーへの再問い合わせでは新しい答えが返るのに、クライアントだけ古い答えを使うなら、まず疑うべきはローカルキャッシュです。(Microsoft Learn)
レコード種別と Status を見落とさない
名前解決の調査で A レコードだけ見て終わると、見落としが出ます。Get-DnsClientCache では Type に A、NS、CNAME、SOA、PTR、MX、AAAA、SRV を指定でき、Status では Success、NotExist、NoRecords を使って絞り込めます。ipconfig /displaydns の生テキストが読みづらいときは、PowerShell の構造化出力に切り替えるだけで、誤診率がかなり下がります。(Microsoft Learn)
Hosts ファイルの影響を見落とさない
ipconfig /displaydns は、ローカルの Hosts ファイルから事前に読み込まれたエントリも表示対象に含みます。しかも Microsoft サポートは、Hosts ファイルが既定状態から変更されると通常の名前解決を上書きし、接続問題の原因になることがあると案内しています。影響が一台だけで、DNS サーバーの答えは正しいのにその端末だけ誤った宛先へ行くなら、%systemroot%\system32\drivers\etc 配下の Hosts ファイルも必ず確認してください。(Microsoft Learn)
実務で迷わない調査手順
まずは「名前解決の問題か」を切り分ける
ping app1.corp.contoso.com
ping 10.0.0.25IP 指定では通るのに名前指定で失敗するなら、まず名前解決を疑います。Microsoft の ping 解説でも、その場合はローカル Hosts ファイル、DNS クエリ、NetBIOS 名前解決を確認するよう案内しています。(Microsoft Learn)
次に DNS サーバーの今の答えを見る
nslookup app1.corp.contoso.com 10.0.0.10Resolve-DnsName -Name app1.corp.contoso.com -Server 10.0.0.10 -DnsOnlynslookup は DNS インフラの診断向けで、サーバーを明示して再問い合わせできます。Resolve-DnsName も同様の用途に使え、-DnsOnly を付ければ DNS 以外の名前解決を混ぜません。ここで誤答が返るなら、/displaydns より先に DNS サーバー側を追うべきです。(Microsoft Learn)
そのあとにクライアントのローカルキャッシュを見る
ipconfig /displaydnsResolve-DnsName -Name app1.corp.contoso.com -CacheOnly
Get-DnsClientCache -Name app1.corp.contoso.comipconfig /displaydns は全体把握向きです。対象名だけを素早く確認したいなら Resolve-DnsName -CacheOnly や Get-DnsClientCache -Name が効きます。PowerShell では Type や Status でも絞り込めるので、利用が多くキャッシュが膨らみやすい PC ではこちらのほうが実務向きです。(Microsoft Learn)
古い答えや否定応答が残っていたら、最後に消す
ipconfig /flushdnsClear-DnsClientCacheipconfig /flushdns は DNS クライアントキャッシュをリセットし、負のキャッシュや動的に追加されたエントリを捨てる用途です。PowerShell では Clear-DnsClientCache が同等です。最初にいきなり消すのではなく、現物を見てから実行すると、原因の切り分け精度が上がります。(Microsoft Learn)
再確認して、原因の場所を決める
DNS サーバーへの再問い合わせは正しいのに、ローカルキャッシュだけが古い、または否定応答を持っているなら、問題はクライアント側です。逆に、DNS サーバーへ直接聞いても誤答なら、ローカルキャッシュではなく DNS サーバー、転送先、上流側のどこかを優先して見るべきです。この順番で見ると、ipconfig /displaydns を「何でも調べられる万能コマンド」と誤解せずに済みます。(Microsoft Learn)
よくある失敗
先に flush して証拠を消してしまう
DNS トラブルでありがちなのが、症状を確認した直後に ipconfig /flushdns を打ってしまうことです。これで否定応答や古い動的エントリは消せますが、「何が残っていたのか」という証拠も消えます。再現直後は、まず ipconfig /displaydns か Get-DnsClientCache を確認する順番にしたほうが、再発時も追いやすくなります。(Microsoft Learn)
nslookup が正しいので安心してしまう
nslookup や Resolve-DnsName -Server が正しい答えを返しても、クライアントは最初にローカルキャッシュを見ます。つまり「DNS サーバーは正しいが、端末はまだ古い」という状態は普通に起こります。DNS サーバーの正しさ確認と、ipconfig /displaydns によるクライアント確認は、役割が別だと割り切るのが大切です。(Microsoft Learn)
ping の結果だけで DNS を断定してしまう
ping は切り分けの入口には便利ですが、名前解決には Hosts ファイル、DNS、NetBIOS が絡みます。DNS だけを厳密に見たいなら、Resolve-DnsName -DnsOnly を併用したほうが、調査がぶれません。特に「ping は変だが nslookup は正常」というケースでは、ipconfig /displaydns と Resolve-DnsName -DnsOnly の組み合わせが有効です。(Microsoft Learn)
まとめ
ipconfig /displaydns は、DNS サーバーの現在値を調べるコマンドではなく、影響を受けているクライアントの DNS キャッシュを可視化するコマンドです。使いどころは、一台だけ古い IP を引く、Name does not exist が残る、Hosts ファイルの影響を疑う、といった「クライアントが何を覚えているか」を確かめたい場面です。(Microsoft Learn)
次にやるべきことはシンプルです。まず問題が出ているクライアントで症状を再現し、nslookup か Resolve-DnsName -Server で DNS サーバーの現在値を確認します。そのあとで ipconfig /displaydns または Get-DnsClientCache を見て、必要なときだけ ipconfig /flushdns を実行してください。この順番を守るだけで、DNS トラブル調査の空振りはかなり減ります。(Microsoft Learn)
コメント