Linuxで名前解決が不安定になる原因（resolv.conf以外）

URLをコピーしました！

「pingは通るのに名前解決だけ失敗する」
「たまに名前解決できるが、再現性が低い」
「resolv.confは正しいのにDNSエラーが出る」

このようなトラブルは、resolv.conf以外の要因が絡んでいるケースが非常に多く、現場では切り分けに時間を取られがちです。

本記事では、Linuxで名前解決が不安定になる代表的な原因を、 「resolv.conf以外」にフォーカスして、調査手順・対策まで実務目線で整理します。

前提：Linuxの名前解決はresolv.confだけではない

Linuxの名前解決は、以下の要素が複合的に関与します。

/etc/nsswitch.conf
glibcの名前解決順序
systemd-resolved / NetworkManager
DNSキャッシュ
IPv6の影響
DNSサーバ側の挙動

そのため、resolv.confが正しくても不安定になることは珍しくありません。

原因①：nsswitch.confの名前解決順序

まず確認すべきは /etc/nsswitch.conf です。

hosts: files dns

この設定は、

/etc/hosts
DNS

の順で名前解決を行うことを意味します。

問題になりやすい例：

hosts: files dns myhostname

myhostname が入ることで、

ホスト名解決が内部処理に吸われる
DNS問い合わせが遅延する

結果として、一部の名前解決だけ遅い・失敗する症状が出ます。

対策

不要な解決方式を削除
順序を最小構成にする

原因②：systemd-resolvedによる名前解決の不整合

最近のLinuxでは systemd-resolved が有効なことが多く、 resolv.confが実体ではないケースがあります。

ls -l /etc/resolv.conf

以下のような場合は注意が必要です。

/etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

この場合、

実際のDNS設定はsystemd-resolvedが管理
resolv.confを直接編集しても反映されない

確認コマンド

resolvectl status

対策

systemd-resolvedの設定を正として管理
不要であればサービス自体を停止

原因③：NetworkManagerによるDNS上書き

NetworkManagerが動作している環境では、

DHCP更新
インタフェース再起動

のたびにDNS設定が上書きされます。

結果として、

一時的に名前解決できる
しばらくすると失敗する

という症状が発生します。

確認

nmcli device show | grep DNS

対策

NetworkManagerのDNS管理を無効化
static設定に切り替える

原因④：DNSキャッシュの不整合

以下のコンポーネントはDNSキャッシュを持ちます。

systemd-resolved
nscd
アプリケーション独自キャッシュ

キャッシュが壊れると、

特定の名前だけ失敗
再起動すると直る

といった典型症状が出ます。

対処

systemctl restart systemd-resolved
systemctl restart nscd

原因⑤：IPv6が絡む名前解決遅延

DNSではIPv4（A）とIPv6（AAAA）の両方を引きます。

IPv6が有効だが通信できない場合、

AAAA問い合わせでタイムアウト
結果として名前解決が遅延

確認

getent ahosts example.com

対策

IPv6を正しく設定する
不要なら無効化する

原因⑥：DNSサーバ側の応答遅延・分散

resolv.confに複数DNSサーバが設定されている場合、

nameserver 8.8.8.8
nameserver 8.8.4.4

片方が遅延・不安定だと、

問い合わせがタイムアウト
次のDNSに切り替わるまで待たされる

結果として名前解決が不安定になります。

対策

信頼できるDNSサーバのみ設定
不要なDNSを削除

切り分け時に必ず使うコマンド

# 名前解決の実体確認
getent hosts example.com

# 実際のDNS問い合わせ確認
dig example.com

# glibc経由の確認
strace -e trace=network ping example.com

まとめ

Linuxの名前解決不安定は、

resolv.confだけ見ても解決しない
複数コンポーネントの影響を受ける

という特徴があります。

重要なのは、

「どのレイヤが名前解決を握っているか」を特定すること

systemd-resolved / NetworkManager / nsswitch.conf を意識した切り分けが、最短での解決につながります。