systemd-resolved と glibc の関係

URLをコピーしました！

Linux環境で名前解決トラブルが発生した際、

dig は引けるがアプリは名前解決できない
/etc/resolv.conf を直したのに直らない
systemd-resolved を止めたら直った

といった現象に遭遇したことはないでしょうか。

これらの多くは、systemd-resolved と glibc の役割分担を誤解していることが原因です。

本記事では、systemd-resolved と glibc がどのように連携して名前解決を行っているのかを整理し、実務での切り分け・対策まで落とし込みます。

結論：glibcが主役、systemd-resolvedは補助役

まず結論です。

glibc：名前解決の実行主体
systemd-resolved：名前解決の情報源の1つ

systemd-resolved はDNSサーバそのものではありません。 glibc が参照する「仕組みの一部」です。

glibc の役割

glibc（GNU C Library）は、 Linux上のほぼ全てのアプリケーションが利用する標準ライブラリです。

名前解決においては、

getaddrinfo()
gethostbyname()

といった関数を提供し、アプリはこれを通じて名前解決を行います。

つまり、

curl
Java
Python
systemd 自身

すべて glibc を通して名前解決しているという点が重要です。

glibc が参照する設定ファイル

glibc は以下を参照します。

/etc/nsswitch.conf
/etc/resolv.conf
/etc/hosts

この中でも systemd-resolved が関与するのが /etc/resolv.conf です。

systemd-resolved の役割

systemd-resolved は以下を提供します。

ローカルDNSスタブ（127.0.0.53）
DNSキャッシュ
Link単位のDNS制御

重要なのは、 glibc が systemd-resolved を直接呼び出しているわけではない点です。

/etc/resolv.conf の正体

systemd-resolved 有効時、/etc/resolv.conf は以下のようになります。

nameserver 127.0.0.53
options edns0 trust-ad
search example.com

glibc はここに書かれた 127.0.0.53 に問い合わせます。

その先で systemd-resolved が実DNSへ転送しています。

dig が通るのにアプリが通らない理由

よくある誤解です。

dig example.com @8.8.8.8

これは glibc を通していません。

一方、アプリは、

glibc
nsswitch.conf
resolv.conf

を必ず通ります。

つまり、

dig OK
curl NG

は glibc経路の問題です。

systemd-resolved が原因の典型トラブル

127.0.0.53 に疎通できない

ss -lntup | grep 53

systemd-resolved が停止していると、glibc の問い合わせが行き場を失います。

Link単位DNS設定の影響

resolvectl status

NICごとに異なるDNSが設定されていると、期待しないDNSに問い合わせが飛びます。

切り分け手順（実務）

① glibc経路確認

getent hosts example.com

これが最重要です。

成功 → glibc経路OK
失敗 → systemd-resolved / resolv.conf / nsswitch疑い

② systemd-resolved 状態確認

systemctl status systemd-resolved

③ resolv.conf 実体確認

ls -l /etc/resolv.conf

シンボリックリンクかどうかを必ず確認します。

対策① systemd-resolved を正しく使う

resolv.conf を直接編集しない
resolvectl で設定確認

resolvectl dns eth0 8.8.8.8
resolvectl domain eth0 example.com

期待される結果

getent が安定する
アプリと dig の結果が一致

対策② systemd-resolved を使わない

要件上不要な場合は無効化も選択肢です。

systemctl disable --now systemd-resolved

rm -f /etc/resolv.conf
echo "nameserver 8.8.8.8" > /etc/resolv.conf

期待される結果

glibc が直接DNSへ問い合わせ
挙動がシンプルになる

どちらを選ぶべきか

単一NIC・単一DNS → 無効化も可
VPN / 複数NIC → systemd-resolved推奨

重要なのは「理解して選ぶ」ことです。

まとめ

glibc が名前解決の主体
systemd-resolved は間接的存在
dig と getent は全く別経路
glibc経路確認が最優先

名前解決トラブルは、 仕組みを理解すれば再現性を持って解決できます。