LinuxでDNS名前解決できない原因と確認手順｜getent・resolv.conf・dig
Linuxでホスト名をIPアドレスへ名前解決できないとき、いきなり/etc/resolv.confを書き換えず、NSS・ローカル設定・resolver・DNSサーバー・通信経路を順番に確認して原因を切り分けるページです。
このページの目的
getentとdigの結果を比較し、「Linuxの名前解決経路で失敗」「DNS問い合わせ自体が失敗」「特定の名前・DNSサーバーだけ失敗」を分けます。設定変更より先に、どこで止まっているかを確認します。
最初にやること
障害が出ているホスト名でgetent hostsを実行し、次にdigを確認します。両方の結果が違う場合は、nsswitch.confや/etc/hostsを含むLinux側の名前解決経路を優先して確認します。
DNSトラブル早見表
最初の確認結果から、次に見る場所を決めます。1つのコマンド結果だけで原因を断定しないのがポイントです。
| 症状・確認結果 | 優先して確認する範囲 | 次の確認 |
|---|---|---|
getentもdigも失敗 | resolver設定、DNSサーバー、経路・通信 | resolv.conf → resolvectl → DNS指定dig |
dig成功、getent失敗 | NSS、/etc/hosts、名前解決順序 | nsswitch.conf → /etc/hosts |
| IPアドレスなら通信できるが名前だけ失敗 | 名前解決系 | getent hosts → dig |
| 特定ホスト名だけ失敗 | 対象レコード、検索ドメイン、hosts | FQDNで確認 → DNS応答コード確認 |
NXDOMAIN | 問い合わせた名前・DNSゾーン | FQDN・レコード有無を確認 |
SERVFAILやtimeout | DNSサーバー処理、上流、経路 | 別DNS指定・経路・パケット確認 |
目的からDNSの確認先を選ぶ
getent・dig・resolvectlの使い分け
OS側の名前解決とDNS直接問い合わせを比較し、次に見る場所を判断します。
コマンドを確認 →dig結果NOERROR・NXDOMAIN・SERVFAILの見方
DNS応答コードとtimeoutを分け、別resolverやDNSSECなど次の確認へ進みます。
statusを確認 →Linux DNS設定systemd-resolvedとresolv.conf
127.0.0.53、resolvectl、リンク別DNS、設定管理元を確認します。
resolver設定を確認 →まず名前解決障害かを確認する
アプリケーションのエラーだけでDNS障害と決めつけず、障害が出ている名前をLinux自身が解決できるか確認します。対象ホスト名は実際に失敗している名前へ置き換えてください。
getentはName Service Switch（NSS）の設定に従ってhostsデータベースを参照します。一方、digはDNS問い合わせの確認に向いています。2つを比較すると、DNSそのものとLinux側の名前解決経路を分けやすくなります。
ping失敗だけでネットワークやDNSの異常を確定しません。getentでLinuxの名前解決を確認する
getentは/etc/nsswitch.confで設定されたNSS経由で問い合わせます。普段のアプリケーションがOSの名前解決機能を使う場合に近い確認として使えます。
- 結果が返る：Linuxの名前解決経路では名前を取得できています。アプリ固有のproxy・コンテナ・キャッシュなど別の経路も確認します。
- 結果が返らない：NSSの順序、
/etc/hosts、resolver設定、DNS問い合わせへ進みます。
nsswitch.confと/etc/hostsを確認する
hosts:行は環境によってfiles、dns、resolve、myhostname、mymachinesなどのNSSモジュールを含みます。利用できるモジュールは環境によって異なり、順序や条件によってDNSより先に/etc/hostsやローカル名が参照されることがあります。
dig成功・getent失敗なら：DNSサーバー自体を直す前に、hosts:行と/etc/hosts、NSSモジュールの状態を確認します。/etc/resolv.confを確認する
主に確認するのはnameserver、search、optionsです。glibc resolverではnameserverに問い合わせ先を、searchに検索ドメインを設定できます。
/etc/resolv.confはNetworkManager、systemd-resolved、DHCPクライアントなどにより生成・管理される場合があります。まずls -lでsymlinkか確認し、管理元を特定してから変更してください。短いホスト名だけ失敗する場合はsearchやoptions ndots:の影響も確認します。まずFQDNでも同じ症状になるか比較すると切り分けやすくなります。
systemd-resolved環境を確認する
systemd-resolvedを使う環境では、リンクごとのDNSサーバーや検索・ルーティングドメインをresolvectl statusで確認できます。/etc/resolv.confがローカルstub resolverを指している構成もあるため、127.0.0.53が書かれているだけで誤設定とは判断しません。
resolv.confだけでなく、どのリンクへDNS問い合わせがルーティングされるかも確認します。digでDNS問い合わせを確認する
DNSサーバーを明示したdig @DNS_SERVERで、特定のDNSサーバーへ問い合わせた結果を比較できます。デフォルト問い合わせと結果が違う場合は、実際に選ばれているDNSサーバーや経路を確認します。
| 結果 | 考え方 |
|---|---|
dig成功・getent失敗 | NSS、hosts、resolver統合部分を優先して確認 |
デフォルトdig失敗・特定DNS指定は成功 | 通常利用しているDNSサーバーや選択経路を確認 |
| どのDNS指定でもtimeout | DNSサーバー到達性、Firewall、経路を確認 |
NXDOMAIN | 問い合わせ先DNSは応答しているため、名前・ゾーン・レコードの存在を確認 |
DNSサーバーへの経路・通信を確認する
DNSサーバーが分かったら、そのアドレスへのルートと、必要に応じてDNSパケットの送受信を確認します。
通常のDNS問い合わせではUDPが使われることが多く、応答サイズや条件によってTCPも使われます。そのためncでTCP/53へ接続できることだけを根拠に「DNSは正常」とは判断しません。digの応答とパケット確認を合わせます。
よくあるエラー文字列・DNS応答
| 表示 | 最初に考えること |
|---|---|
Temporary failure in name resolution | 一時的なresolver/DNS失敗として、getent、resolver設定、DNS応答を確認 |
Could not resolve host | アプリが指定名を解決できていないため、対象名とOS側名前解決を確認 |
Name or service not known | 名前の誤り、NSS、DNS結果などを確認。文字列だけで原因を確定しない |
NXDOMAIN | DNSサーバーから「その名前は存在しない」という応答。名前・ゾーン・レコードを確認 |
SERVFAIL | DNSサーバーが処理を完了できていない。上流・DNSSEC・サーバー状態などサーバー側調査も必要 |
| timeout / no servers could be reached | DNSサーバー、経路、Firewall、resolverの問い合わせ先を確認 |
確認結果から次の対応を決める
| 確認結果 | 次に見る場所 |
|---|---|
getentもdigも失敗 | resolv.conf、resolvectl、DNSサーバー指定dig、経路 |
dig成功・getent失敗 | nsswitch.conf、/etc/hosts、NSSモジュール |
resolv.confがstub resolverを指す | resolvectl statusで実際のDNSサーバー・リンクを確認 |
| 特定DNS指定だけ成功 | 通常利用しているDNSサーバーと選択経路を確認 |
| 問い合わせは出るが応答がない | DNSサーバー、経路、Firewall、上流 |
| 名前解決は成功するがSSHだけ失敗 | SSH接続トラブルガイドへ |
設定変更前のチェック
- 障害が出ている実際のホスト名で
getentとdigを比較したか /etc/resolv.confの管理元（systemd-resolved、NetworkManager、DHCPなど）を確認したか- 複数NIC・VPN・コンテナなど、名前解決経路がホストOSと異ならないか
- DNSサーバーを変更する前に、現在選ばれているサーバーと失敗結果を記録したか
- 変更後は
getentと実際のアプリケーションの両方で再確認するか