インフラ作業支援ラボInfra Support Lab ← ガイド一覧← 戻る
トップ > ガイド > トラブル解決 > DNS名前解決できない
トラブル解決ガイド｜更新日：2026年10月11日

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側の名前解決経路を優先して確認します。

このページの対象：Linuxクライアント側でDNS・名前解決が失敗するケースです。BINDなど権威DNSサーバーの構築・ゾーン設計は対象外です。名前解決は成功しているのにSSHだけ接続できない場合は、SSH接続トラブルガイドを確認してください。

DNSトラブル早見表

最初の確認結果から、次に見る場所を決めます。1つのコマンド結果だけで原因を断定しないのがポイントです。

症状・確認結果優先して確認する範囲次の確認
getentもdigも失敗resolver設定、DNSサーバー、経路・通信resolv.conf → resolvectl → DNS指定dig
dig成功、getent失敗NSS、/etc/hosts、名前解決順序nsswitch.conf → /etc/hosts
IPアドレスなら通信できるが名前だけ失敗名前解決系getent hosts → dig
特定ホスト名だけ失敗対象レコード、検索ドメイン、hostsFQDNで確認 → DNS応答コード確認
NXDOMAIN問い合わせた名前・DNSゾーンFQDN・レコード有無を確認
SERVFAILやtimeoutDNSサーバー処理、上流、経路別DNS指定・経路・パケット確認

目的からDNSの確認先を選ぶ

確認コマンド

getent・dig・resolvectlの使い分け

OS側の名前解決とDNS直接問い合わせを比較し、次に見る場所を判断します。

コマンドを確認 →dig結果

NOERROR・NXDOMAIN・SERVFAILの見方

DNS応答コードとtimeoutを分け、別resolverやDNSSECなど次の確認へ進みます。

statusを確認 →Linux DNS設定

systemd-resolvedとresolv.conf

digで「parse of /etc/resolv.conf failed」と出る場合：名前解決結果の問題ではなく、resolv.confの解析に失敗している可能性があります。専用の確認手順で構文・不可視文字・管理元を確認してください。

127.0.0.53、resolvectl、リンク別DNS、設定管理元を確認します。

resolver設定を確認 →

まず名前解決障害かを確認する

アプリケーションのエラーだけでDNS障害と決めつけず、障害が出ている名前をLinux自身が解決できるか確認します。対象ホスト名は実際に失敗している名前へ置き換えてください。

getent hosts example.com dig example.com

getentはName Service Switch（NSS）の設定に従ってhostsデータベースを参照します。一方、digはDNS問い合わせの確認に向いています。2つを比較すると、DNSそのものとLinux側の名前解決経路を分けやすくなります。

pingだけで判定しない：ICMPが許可されていない環境もあるため、ping失敗だけでネットワークやDNSの異常を確定しません。

getentでLinuxの名前解決を確認する

getent hosts example.com

getentで結果が返るかを確認し、Linuxの通常の名前解決経路で対象名を取得できるかを判断します。返らない場合は、nsswitch.conf・/etc/hosts・resolver設定へ進みます。

コマンドの詳しい使い分け：getent ahosts、dig、resolvectl、旧環境のnslookup/hostまで比較したい場合は DNS確認コマンドの使い分け を確認してください。このページでは障害時の判断順に絞ります。

nsswitch.confと/etc/hostsを確認する

grep -E '^hosts:' /etc/nsswitch.conf grep -n 'example.com' /etc/hosts

hosts:行は環境によってfiles、dns、resolve、myhostname、mymachinesなどのNSSモジュールを含みます。利用できるモジュールは環境によって異なり、順序や条件によってDNSより先に/etc/hostsやローカル名が参照されることがあります。

dig成功・getent失敗なら：DNSサーバー自体を直す前に、hosts:行と/etc/hosts、NSSモジュールの状態を確認します。

/etc/resolv.confを確認する

ls -l /etc/resolv.conf cat /etc/resolv.conf
詳しく確認：systemd-resolvedや127.0.0.53、resolv.confの管理元を詳しく確認する場合は systemd-resolvedと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環境を確認する

systemctl is-active systemd-resolved resolvectl status

systemd-resolvedが有効なら、resolvectl statusで実際に選ばれているDNSサーバーとリンク別設定を確認します。127.0.0.53が見えるだけで誤設定とは判断しません。

設定構造を詳しく確認：/etc/resolv.confのsymlink、stub resolver、リンク別DNS、旧環境のsystemd-resolveは systemd-resolvedとresolv.conf で整理しています。

digでDNS問い合わせを確認する

dig example.com # DNSサーバーを明示して比較 dig @192.0.2.53 example.com

digでDNS問い合わせ自体が成立するかを確認します。デフォルト問い合わせだけ失敗し、DNSサーバーを明示すると成功する場合は、通常利用しているresolverやDNSサーバー選択経路を優先して確認します。

digの詳細は分離：オプションやNOERROR・NXDOMAIN・SERVFAIL・REFUSEDの読み方は digのstatusの見方、コマンド自体の使い分けは DNS確認コマンド を確認してください。

DNSサーバーへの経路・通信を確認する

DNSサーバーが分かったら、そのアドレスへのルートと、必要に応じてDNSパケットの送受信を確認します。

ip route get 192.0.2.53 # TCP/53の確認。これだけでDNS全体が正常とは判断しない nc -vz 192.0.2.53 53 # 必要な場合のみパケット確認 sudo tcpdump -ni any 'port 53'

通常の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結果などを確認。文字列だけで原因を確定しない
NXDOMAINDNSサーバーから「その名前は存在しない」という応答。名前・ゾーン・レコードを確認
SERVFAILDNSサーバーが処理を完了できていない。上流・DNSSEC・サーバー状態などサーバー側調査も必要
timeout / no servers could be reachedDNSサーバー、経路、Firewall、resolverの問い合わせ先を確認

確認結果から次の対応を決める

確認結果対処
getentもdigも失敗現在使うべきDNSサーバーを管理元（NetworkManager、systemd-resolved、DHCP/VPN、静的設定）から特定し、誤ったDNS指定や経路をその管理元で修正します。
dig成功・getent失敗nsswitch.confのhosts:順序、/etc/hosts、NSSモジュールを確認し、意図しない優先順位や誤登録を修正します。
resolv.confがstub resolverを指すstub自体を消さず、resolvectl statusで実DNSサーバーとリンクを特定し、上流のNetworkManager・networkd・DHCP/VPN設定を修正します。
特定DNS指定だけ成功通常選択されるDNSサーバーまたは経路に問題があります。正しいDNSサーバーを選ぶ設定へ直し、不要な一時dig @server依存を残しません。
問い合わせは出るが応答がないDNSサーバー側、経路、Firewall/ACL、VPN経路を確認し、53/UDPだけでなく必要に応じ53/TCPも阻害していないか修正します。
名前解決は成功するがSSHだけ失敗DNSは解決済みです。DNS設定を変更せず、SSH接続トラブルガイドへ調査範囲を移します。

修正後の再確認

設定を直したら、同じホスト名でOSの名前解決経路とDNS問い合わせを両方確認します。

getent hosts example.com dig example.com

systemd-resolved環境では必要に応じてresolvectl query example.comも確認します。期待するIPが返るだけでなく、利用しているDNSサーバーやリンクが想定どおりかも確認してください。

再確認の基準：一時的に/etc/resolv.confを書き換えて成功しただけでは完了にしません。再接続・DHCP更新・VPN再接続後も設定が維持される管理元を修正できているか確認します。

設定変更前のチェック

このページのゴール：「とりあえずDNS設定を書き換える」のではなく、NSS・resolver・DNSサーバー・通信のどこに問題があるかを確認してから、管理元に合った修正を行うことです。

参考資料

名前解決後もSSHだけ接続できない場合

DNS解決が成功しているのにSSH接続が失敗する場合は、TCP接続・sshd・認証をSSHトラブルガイドで切り分けます。

SSH接続を確認