resolvectlコマンドの使い方｜DNSキャッシュをクリアしてDNS設定を確認する手順

「DNSを変更したはずなのに、まだ古いIPアドレスで名前解決されてしまう。」「resolv.confを直接書き換えたら、なぜか設定が元に戻ってしまった。」

RHEL9やUbuntu 22.04以降では名前解決の仕組みが大きく変わり、systemd-resolvedというデーモンがDNSキャッシュと名前解決を担うようになっています。/etc/resolv.conf を直接編集しても反映されないのはそのためで、以前の手順がそのまま通用しなくなっています。

この記事では、systemd-resolvedを操作するCLIツール「resolvectl」の使い方を解説します。DNSキャッシュのクリア（flush-caches）、DNS設定の確認（status）、名前解決のテスト（query）を、RHEL 9.4 / Ubuntu 22.04 LTSの実機出力とともに紹介します。

resolvectlとsystemd-resolvedの役割を整理する

CentOS7以前では /etc/resolv.conf にDNSサーバーのIPアドレスを直接書き込むのが一般的でした。RHEL8・RHEL9・Ubuntu 18.04以降では、systemd-resolved というデーモンが名前解決を一元管理するようになり、/etc/resolv.conf の扱いが変わっています。

実際に確認してみましょう。
シンボリックリンクになっています。リンク先の中身を見ると：
nameserver に 127.0.0.53 が設定されています。これはsystemd-resolvedが待ち受けているループバックアドレスで、すべての名前解決リクエストがここを経由します。resolv.conf を直接書き換えても次のリロードで上書きされるのは、ここに戻るように設計されているためです。

resolvectl は、このsystemd-resolvedを制御するCLIコマンドです。DNS設定の確認・キャッシュ操作・名前解決テストなど、DNS関連の作業をresolvectl一本でこなせます。

systemd-resolved が起動しているかは以下で確認します。
Active: active (running) であれば正常です。

resolvectl statusでDNS設定を確認する

Global Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Link 2 (eth0) Current Scopes: DNS Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 8.8.4.4 DNS Servers: 8.8.8.8 8.8.4.4 Link 3 (wlan0) Current Scopes: none Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Link 5 (tailscale0) Current Scopes: DNS Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 100.100.100.100 DNS Servers: 100.100.100.100 fd7a:115c:a1e0::53 DNS Domain: tailcd0d62.ts.net ~0.e.1.a.c.5.1.1.a.7.d.f.ip6.arpa ~100.100.in-addr.arpa ~101.100.in-addr.arpa ~102.100.in-addr.arpa ~103.100.in-addr.arpa ~104.100.in-addr.arpa ~105.100.in-addr.arpa ~106.100.in-addr.arpa ~107.100.in-addr.arpa ~108.100.in-addr.arpa ~109.100.in-addr.arpa ~110.100.in-addr.arpa ~111.100.in-addr.arpa ~112.100.in-addr.arpa ~113.100.in-addr.arpa ~114.100.in-addr.arpa ~115.100.in-addr.arpa ~116.100.in-addr.arpa ~117.100.in-addr.arpa ~118.100.in-addr.arpa ~119.100.in-addr.arpa ~120.100.in-addr.arpa ~121.100.in-addr.arpa ~122.100.in-addr.arpa ~123.100.in-addr.arpa ~124.100.in-addr.arpa ~125.100.in-addr.arpa ~126.100.in-addr.arpa ~127.100.in-addr.arpa ~64.100.in-addr.arpa ~65.100.in-addr.arpa ~66.100.in-addr.arpa ~67.100.in-addr.arpa ~68.100.in-addr.arpa ~69.100.in-addr.arpa ~70.100.in-addr.arpa ~71.100.in-addr.arpa ~72.100.in-addr.arpa ~73.100.in-addr.arpa ~74.100.in-addr.arpa ~75.100.in-addr.arpa ~76.100.in-addr.arpa ~77.100.in-addr.arpa ~78.100.in-addr.arpa ~79.100.in-addr.arpa ~80.100.in-addr.arpa ~81.100.in-addr.arpa ~82.100.in-addr.arpa ~83.100.in-addr.arpa ~84.100.in-addr.arpa ~85.100.in-addr.arpa ~86.100.in-addr.arpa ~87.100.in-addr.arpa ~88.100.in-addr.arpa ~89.100.in-addr.arpa ~90.100.in-addr.arpa ~91.100.in-addr.arpa ~92.100.in-addr.arpa ~93.100.in-addr.arpa ~94.100.in-addr.arpa ~95.100.in-addr.arpa ~96.100.in-addr.arpa ~97.100.in-addr.arpa ~98.100.in-addr.arpa ~99.100.in-addr.arpa ~ts.net はsystemd-resolvedが認識している現在のDNS設定を一覧表示します。「どのDNSサーバーが使われているか」を最初に確認するコマンドです。

1. コマンドを実行して出力を確認する

Global セクション（全体設定）と Link セクション（インターフェース別設定）の2段構成で表示されます。

2. 出力の主要な項目の読み方

・Protocols: +/-でプロトコルが有効か無効かを示す。-LLMNRはLLMNRが無効、-mDNSはmDNSが無効を意味する
・resolv.conf mode: stub ——スタブモード（127.0.0.53を経由する）で動作中であることを示す
・Current DNS Server: 実際に名前解決に使われているDNSサーバーとインターフェース名
・DNS Servers: 設定されている全DNSサーバー（複数の場合はフェイルオーバー順）
・+DefaultRoute: このインターフェースのDNSサーバーをデフォルトルート向けに使うことを示す

インターフェースが複数ある場合は、Link 2・Link 3... と各インターフェースごとに表示されます。複数のインターフェースが有効な環境では、どのインターフェースのDNSが実際に使われているかをここで確認します。

resolvectl flush-cachesでDNSキャッシュをクリアする

DNSレコードを変更したのに古いIPアドレスで名前解決され続ける——このトラブルの原因の多くは、systemd-resolvedのDNSキャッシュが古いレコードを保持し続けているためです。

1. DNSキャッシュをクリアする

root権限（sudo）が必要です。成功時は何も表示されません。エラーが出なければキャッシュはクリアされています。

2. クリア前後をstatisticsで確認する

キャッシュの状態は で確認できます。
・Current Cache Size: 現在キャッシュに保存されているレコード数
・Cache Hits: キャッシュから応答した回数（外部DNSへの問い合わせなしで解決した回数）
・Cache Misses: 外部DNSに問い合わせた回数（キャッシュにレコードがなかった回数）

flush-caches実行後にstatisticsを確認すると、Current Cache Sizeが0になっていることが分かります。
Cache Hits/Missesはフラッシュ後もリセットされず累積値として残ります。キャッシュのレコード数（Current Cache Size）だけが0になります。統計自体もリセットしたい場合は を使います。

resolvectl queryで名前解決をテストする

はdigコマンドと同様に名前解決のテストに使えます。systemd-resolvedを経由した名前解決をテストできるため、「ブラウザでは開けるのにcurlで失敗する」「DNSキャッシュのfresh/cached判定を確認したい」という場面で役立ちます。

dig コマンドで DNS を調べる場合はdigが直接外部DNSに問い合わせるのに対して、resolvectl queryはsystemd-resolvedを経由します。この違いを意識して使い分けることで、問題の切り分けが精確になります。

1. ホスト名を解決する

・Data from: network ——外部DNSに問い合わせて解決した（キャッシュ未使用）
・Data from: cache ——キャッシュから解決した（外部DNS問い合わせなし）

flush-caches直後に同じホストを解決すると になり、その後すぐに実行すると になることが確認できます。

2. IPアドレスから逆引きする

不審な通信のログに残ったIPアドレスがどのサーバーかを確認したい場面などで使えます。

DNSトラブルシューティングでの実践的な使い方

「DNSを変更したのに反映されない」という場面でresolvectlを使った切り分け手順を整理します。Linuxサーバーのトラブル対応を体系的に学びたい方には、実機ハンズオンで習得できるLinuxサーバー構築セミナーもご参考ください。

1. DNSを変更したのに反映されない時の切り分け手順

よく起きるのが「nmcliでDNSを変更したのに古いIPのまま」というケースです。以下の順番で確認します。

手順1: resolvectl statusでDNSサーバーを確認する
ここで意図したDNSサーバーが表示されていない場合はnmcliで設定し直します。Linux DNS 設定の基本を参照してください。

手順2: キャッシュをクリアする
手順3: resolvectl queryで名前解決を確認する
手順4: まだ解決しない場合はdigで直接DNSに問い合わせる
digが正しく返答していてresolvectl queryが違う結果を返す場合は、systemd-resolvedのキャッシュかDNS設定の問題です。

2. systemd-resolvedが起動していない場合

resolvectl を実行して「Failed to connect to bus: No such file or directory」や「Failed to connect to resolve service」などのエラーが出る場合は、systemd-resolvedが停止しています。

本記事のまとめ

resolvectl コマンドでできる主要な操作をまとめます。

やりたいこと	コマンド
DNS設定とDNSサーバーを確認する	resolvectl status
DNSキャッシュをクリアする	sudo resolvectl flush-caches
キャッシュ件数・ヒット率を確認する	resolvectl statistics
ホスト名を解決してテストする	resolvectl query ホスト名
IPアドレスを逆引きする	resolvectl query IPアドレス
統計情報をリセットする	sudo resolvectl reset-statistics
ログレベルを確認する	resolvectl log-level

resolv.confを直接編集しても効かないのは設計どおりです。systemd-resolvedが動作している環境では、設定はnmcliで行い、キャッシュクリアや状態確認はresolvectlで行うのが正しい手順です。

---

• 前のページへ：ip netnsコマンドでLinuxのネットワーク名前空間を操作する方法｜仮想NIC・ルーティング分離の実践手順
• この記事の属するカテゴリ：ネットワーク管理コマンドへ戻る