2026年8月27日
2026年8月27日
OSのDNSキャッシュを確認する方法(Windows・macOS・Linux)
DNSレコードを変えたのに自分のPCだけ古いサーバーにつながるとき、まず見るべきなのはOSが持っているDNSキャッシュです。Windowsは ipconfig /displaydns や Get-DnsClientCache、Linux(systemd-resolved)は resolvectl でキャッシュの中身や統計を確認でき、macOSは中身の一覧を見る標準手段が乏しいため「OSの名前解決経路で何が返るか」を確かめる方法をとります。この記事では、OSごとの確認コマンドと、dig や nslookup の結果と食い違うときの読み方を説明します。
なぜ「OSのキャッシュ」を個別に確認するのか
名前解決の結果は、ブラウザ、OS、家庭や社内のルーター、プロバイダーやパブリックDNSのリゾルバ、と何段階にもキャッシュされます。どこか一段に古い値が残っていれば、その下流はすべて古い値を見続けます。
ここでつまずきやすいのが、調査によく使う dig と、Windowsの nslookup はOSのキャッシュを通らないという点です。どちらも設定されたDNSサーバーへ直接問い合わせるため、dig では新しいIPが返るのに、ブラウザやアプリは古いIPへつながる、という食い違いが起こります。この食い違いこそが「OSかブラウザのキャッシュが残っている」という手がかりになります。アプリと同じ経路で名前解決をした結果を見るには、後述する Resolve-DnsName、dscacheutil、getent、resolvectl query などを使います。
Windows でキャッシュの中身を確認する
Windowsでは「DNS Client」サービス(サービス名 Dnscache)がキャッシュを持っています。コマンドプロンプトで次を実行すると、キャッシュされているレコードが一覧表示されます。
ipconfig /displaydns
件数が多い場合は、目的のドメインだけを絞り込みます。
ipconfig /displaydns | findstr /i /c:"example.com" /c:"Time To Live" /c:"A (Host)"
各エントリの「Time To Live」は、そのレコードがあと何秒キャッシュに残るかを示す残り時間です。数秒おいて再実行し、値が減っていればキャッシュから返っていると分かります。表示言語が日本語の環境では項目名が日本語になることがあるため、絞り込みの文字列はご自身の表示に合わせてください。
PowerShellなら、オブジェクトとして扱えるので絞り込みが楽です。
Get-DnsClientCache | Where-Object Entry -like '*example.com*' |
Format-Table Entry, RecordType, Status, TimeToLive, Data -AutoSize
Status が Success 以外のもの(存在しない名前など)は、否定応答がキャッシュされている状態です。レコードを追加した直後に「まだ存在しない」と言われ続ける場合は、この否定キャッシュが原因のことがあります。
アプリと同じ経路の結果を見るには Resolve-DnsName を使います。-CacheOnly を付けるとキャッシュだけを参照し、-DnsOnly を付けるとhostsファイルなどを使わずDNSだけで解決します。
Resolve-DnsName example.com -CacheOnly
Resolve-DnsName example.com -DnsOnly -Server 1.1.1.1
なお、hostsファイルに書いた内容もキャッシュ一覧に表示されます。見覚えのない固定値が出てきたら、C:\Windows\System32\drivers\etc\hosts を確認してください。
macOS で確認する
macOSではmDNSResponderが名前解決とキャッシュを担っていますが、キャッシュの中身を一覧表示する分かりやすい公式コマンドはありません。かつては sudo killall -INFO mDNSResponder でログに状態を書き出す方法が知られていましたが、近年のmacOSではログの多くが伏せ字になり、実用性はバージョンによって差があります(2026年10月現在)。
そこで、実務では「OSの経路で何が返るか」と「DNSサーバーが何を返すか」を比べる方法をとります。
# OSのリゾルバ経路(キャッシュやhostsを含む)で解決
dscacheutil -q host -a name example.com
# DNSサーバーへ直接問い合わせ(OSのキャッシュを通らない)
dig +short example.com A
前者が古いIP、後者が新しいIPなら、OS側に古い情報が残っています。どのDNSサーバーが使われているかは scutil --dns で確認できます。VPNや社内プロファイルを入れている場合、特定ドメインだけ別のリゾルバへ向いていることがあるので、この出力の確認は欠かせません。
古い値が残っていると分かったら、次のコマンドでキャッシュを消します。
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Linux で確認する
Linuxはディストリビューションや構成によってキャッシュを持つ仕組みが違うため、まず誰が名前解決をしているかを確認します。/etc/resolv.conf に nameserver 127.0.0.53 とあればsystemd-resolvedが動いています。
systemd-resolved の場合
resolvectl statistics
resolvectl query example.com
statistics ではキャッシュの件数やヒット数・ミス数が分かります。query の出力末尾には、比較的新しいバージョンでは応答がキャッシュから来たのかネットワークから来たのかが表示されます。表示されない古いバージョンもあるため、その場合は statistics のヒット数の増減で判断します。
キャッシュの中身そのものは、新しめのsystemdなら resolvectl show-cache で見られます。このサブコマンドが無い環境では、sudo pkill -USR1 systemd-resolved でキャッシュ内容をジャーナルに書き出し、journalctl -u systemd-resolved で読みます。
nscd・dnsmasq など
nscdを使っている環境では nscd -g で統計を確認できます。ローカルでdnsmasqを動かしている場合は、SIGUSR1を送るとログに統計が出ます。
どの構成でも、アプリと同じ経路の結果は次のコマンドで確認できます。
getent hosts example.com
getent はnsswitch.confの設定どおりに、hostsファイル、キャッシュ、DNSの順で解決するため、ブラウザやPHPが実際に受け取るIPに近い結果になります。WordPressのサーバーから外部APIへの接続先が古いままになっている、といった調査でも役立ちます。
確認結果の読み方
ここまでの結果は、次のように整理すると判断しやすくなります。
dig(直接問い合わせ)とOS経路の結果が同じで、両方とも古い:OSより上流(ルーターやリゾルバ)にキャッシュが残っているか、DNSレコードの変更がまだ反映されていません。権威DNSサーバーに直接問い合わせて、正しい値になっているか確認します。digは新しく、OS経路だけ古い:OSのキャッシュかhostsファイルが原因です。hostsを確認したうえでキャッシュを消します。- OS経路も新しいのにブラウザだけ古い:ブラウザ自身のDNSキャッシュや、既存の接続の使い回しが原因です。ブラウザ側の対処に進みます。
TTLの残り時間が大きい場合は、待てば自然に消えます。急ぎでなければ、キャッシュを消さずに待つのも選択肢です。逆に、キャッシュを消しても上流が古い値を返す限り状況は変わらないため、消す前に「どの段で古いのか」を特定しておくと無駄な作業が減ります。
まとめ
digやWindowsのnslookupはOSのキャッシュを通らない。アプリと同じ結果を見るにはResolve-DnsName、dscacheutil -q host、getent hosts、resolvectl queryを使う。- Windowsは
ipconfig /displaydnsやGet-DnsClientCacheで中身とTTLの残り時間を確認でき、否定応答のキャッシュも見える。 - macOSは中身の一覧が見づらいため、OS経路と直接問い合わせの結果を比べて判断する。
- Linuxはまず誰がキャッシュしているかを確かめ、systemd-resolvedなら
resolvectl statisticsなどで確認する。 - 直接問い合わせとOS経路の差を見れば、古い値がどの段に残っているかを切り分けられる。