名前解決できない・遅いときに設定ファイルから順に切り分ける手順

ホスト名で接続できない、名前解決に時間がかかるといった症状は、設定ファイルをひとつずつ順番に確認することで原因を絞り込めます。Linux の名前解決には複数の仕組みが関わっており、どこで処理が止まっているかによって対処が変わります。参照順に沿った切り分けの手順を整理します。

名前解決の参照順を把握する（/etc/nsswitch.conf）

名前解決がどの順番で行われるかは /etc/nsswitch.conf の hosts 行に定義されています。まずこのファイルを確認します。

grep ^hosts /etc/nsswitch.conf

一般的な出力は次のようになります。

hosts: files dns myhostname

files は /etc/hosts、dns は /etc/resolv.conf に書かれた DNS サーバー、myhostname は systemd-resolved が提供するローカルホスト名解決をそれぞれ指します。この並び順が切り分けの出発点です。

hosts 行が存在しない、または dns が抜けている場合は、DNS による名前解決が機能しません。files dns の順が標準的な設定です。

/etc/hosts の内容を確認する

参照順が files から始まる場合、/etc/hosts に誤ったエントリが残っていると、DNS に問い合わせる前に間違った結果が返ります。

cat /etc/hosts

確認するポイントは以下のとおりです。

• 接続しようとしているホスト名が記載されていないか
• 記載されている場合、そのアドレスが現在も正しいか
• コメントアウトし忘れた古いエントリが残っていないか

/etc/hosts に誤ったエントリがあると、DNS の設定が正しくても意図しない名前解決が起きます。開発環境の構築や移行作業のあとに古いエントリが残るのはよくある状況です。

/etc/resolv.conf を確認する

/etc/hosts に問題がなければ、次は DNS サーバーの設定を確認します。

cat /etc/resolv.conf

最低限、nameserver 行が存在し、有効な DNS サーバーのアドレスが書かれている必要があります。Ubuntu 18.04 以降など systemd-resolved を使うディストリビューションでは、次のような内容が標準です。

nameserver 127.0.0.53
options edns0 trust-ad

127.0.0.53 は systemd-resolved が提供するローカルリゾルバのアドレスです。このファイルが空だったり nameserver 行がなかったりすると、DNS 問い合わせ自体が行われません。

また、このファイルがシンボリックリンクになっているかどうかも確認します。

ls -la /etc/resolv.conf

systemd-resolved を使う環境では /run/systemd/resolve/stub-resolv.conf へのシンボリックリンクになっているのが正常な状態です。実体ファイルに書き換えられていると、systemd-resolved の設定変更が反映されなくなります。

systemd-resolved の状態を確認する

/etc/resolv.conf が 127.0.0.53 を指している環境では、実際の DNS サーバーへの問い合わせを systemd-resolved が担っています。サービスの状態を確認します。

systemctl status systemd-resolved

active (running) でなければ名前解決が機能しません。起動していない場合はログで原因を確認できます。

journalctl -u systemd-resolved --since "30 minutes ago"

実際に使われている DNS サーバーとサーチドメインは resolvectl status で確認できます。

resolvectl status

インターフェイスごとに使われている DNS サーバーが表示されます。意図しないサーバーが使われていたり、DNS サーバーの項目が空欄になっていたりする場合は、NetworkManager や systemd-networkd の設定ファイル側を確認します。

dig コマンドで DNS 問い合わせを直接テストする

設定ファイルに問題が見当たらない場合は、dig コマンドで DNS サーバーへの問い合わせを直接テストします。dig は /etc/hosts を参照せず指定した DNS サーバーに問い合わせるため、DNS 側の問題を切り分けるのに向いています。

dig example.com

ANSWER SECTION に結果が返ってくれば DNS は応答しています。主なステータスの意味は次のとおりです。

• NXDOMAIN ― ドメインが存在しない
• SERVFAIL ― DNS サーバー側のエラー
• タイムアウト ― DNS サーバーへの疎通自体に問題がある

特定の DNS サーバーに問い合わせたい場合は @ で指定できます。外部の DNS サーバーと systemd-resolved のローカルリゾルバを比較することで、問題がどちら側にあるかを絞り込めます。

# 外部の DNS サーバーに直接問い合わせる
dig @8.8.8.8 example.com

# systemd-resolved のローカルリゾルバに問い合わせる
dig @127.0.0.53 example.com

@127.0.0.53 では解決できて外部に問い合わせると解決できない場合は、キャッシュに古い情報が残っている可能性があります。resolvectl flush-caches でキャッシュを削除してから再度試します。

よくあるつまずきと確認ポイント

/etc/resolv.conf が再起動のたびに上書きされる

手動で /etc/resolv.conf を編集しても、再起動や DHCP の更新のたびに元に戻ってしまうことがあります。NetworkManager や systemd-networkd が管理している環境では、それぞれの設定ファイル側で DNS サーバーを指定する必要があります。直接編集で対応したい場合、シンボリックリンクを解除して実体ファイルにする方法もありますが、systemd-resolved との整合性が崩れる可能性があるため注意が必要です。

名前解決は通るが遅い

名前解決が成功するものの時間がかかる場合、/etc/resolv.conf に複数の nameserver が書かれていて、先頭のサーバーが応答しないためにタイムアウト後に次のサーバーへフォールバックしているケースがよくあります。先頭のサーバーへの疎通を dig @<先頭のnameserverアドレス> example.com で確認します。根本的にはアクセスできないサーバーを削除するか、正しいサーバーに変更することを検討します。

dig では解決できるがアプリケーションで失敗する

dig は /etc/nsswitch.conf の参照順を経由せず直接 DNS に問い合わせます。そのため dig では解決できてもアプリケーションで失敗する場合は、getent hosts コマンドで nsswitch.conf の参照順どおりに解決されるかを確認します。

getent hosts example.com

このコマンドはアプリケーションと同じ仕組みで名前解決を行います。dig との結果を比較することで、DNS 側の問題か /etc/hosts などの静的設定側の問題かを特定できます。