Linuxで「DNSは正しいはずなのに名前解決がおかしい」「環境によって挙動が違う」 といった問題に直面したことはないでしょうか。
これらの多くは、glibc（GNU C Library）の名前解決処理を理解すると説明がつきます。 本記事では、glibcがどのような順序・仕組みで名前解決を行っているのかを、 実務で役立つ視点で整理します。
glibcとは何か（なぜ名前解決に関係するのか）
glibcはLinux上の多くのアプリケーションが利用する標準Cライブラリです。
curl、ssh、ping、Java、Pythonなど、ほぼすべてのアプリケーションは、 glibc経由で名前解決を行っています。
つまり、
- DNS設定が正しくても
- ネットワークが問題なくても
glibcの設定次第で「名前解決できない」「遅い」「環境差が出る」ことがあります。
glibc名前解決の全体フロー
glibcの名前解決は以下の順で進みます。
- アプリが getaddrinfo() を呼び出す
- glibc が nsswitch.conf を参照
- 指定された順序で各解決手段を試行
- 最初に成功した結果を返却
/etc/nsswitch.conf が挙動を決める
名前解決の順序は /etc/nsswitch.conf に定義されています。
hosts: files dnsこの設定の場合、以下の順で解決されます。
- /etc/hosts
- DNS
この「順序」が障害の温床になります。
files（/etc/hosts）の処理
glibcはまず /etc/hosts を読み込みます。
- 完全一致で検索
- 大文字・小文字は区別しない
- 最初に見つかったエントリが採用
ここでIPが見つかると、DNS問い合わせは一切行われません。
dns（libresolv）による問い合わせ
filesで見つからなかった場合、DNS問い合わせに進みます。
この時に参照されるのが以下です。
- /etc/resolv.conf
- search / domain
- options（timeout, attempts, rotateなど）
searchドメインの影響
search example.com localdomainこの場合、glibcは以下の順で問い合わせます。
- hostname.example.com
- hostname.localdomain
- hostname
これが名前解決遅延の原因になることがあります。
IPv4 / IPv6 の解決順
glibcはIPv6を優先する挙動を持ちます（環境依存）。
# 両方確認
getent ahosts example.com結果の順番が、実際にアプリが使う接続順になります。
よくある問題
- IPv6は引けるが通信できない
- IPv6接続でタイムアウト
nscd / systemd-resolved との関係
nscd
glibcの名前解決結果をキャッシュします。
- 古い結果が残る
- hosts変更が即時反映されない
# キャッシュ確認
systemctl status nscd
# キャッシュクリア
systemctl restart nscdsystemd-resolved
DNS問い合わせ自体をsystemdが肩代わりする構成です。
glibc → systemd-resolved → DNS
# 実際の解決状況
resolvectl status
resolvectl query example.comglibc起因の典型トラブルパターン
- /etc/hosts による意図しない固定
- searchドメイン多重指定による遅延
- IPv6優先による接続失敗
- nscdキャッシュ残留
- 環境差（Docker / chroot / minimal OS）
名前解決トラブル時の実務チェック手順
- getent hosts / ahosts でglibc結果を確認
- /etc/nsswitch.conf の順序確認
- /etc/hosts の有無確認
- searchドメイン確認
- IPv6影響確認
- キャッシュ（nscd / resolved）確認
まとめ
- Linuxの名前解決は「DNSだけ」ではない
- glibcが最終的な判断をしている
- getentは最重要デバッグコマンド
glibcの動作を理解すると、
「なぜこのサーバだけおかしいのか」を論理的に説明できるようになります。
