LinuxのDNS確認コマンド｜getent・dig・resolvectl・nslookupの使い分け
Linuxで名前解決を確認するときに、getent・dig・resolvectl・nslookupをどう使い分けるかを整理します。コマンドを並べるだけでなく、結果の差から次に確認する場所を判断します。
先に結論
アプリに近いOSの名前解決経路はgetent、DNSサーバーへの直接問い合わせはdig、systemd-resolvedの実効状態はresolvectlで確認します。nslookupは簡易確認には使えますが、LinuxのNSS経路そのものを再現するコマンドではありません。
最短の確認順
getent hosts → resolvectl status（利用環境のみ）→ dig → dig @DNS_SERVERの順で比較すると、OS側かDNS問い合わせ側かを分けやすくなります。
DNS確認コマンド早見表
| コマンド | 何を確認するか | 向いている場面 |
|---|---|---|
getent hosts | NSS設定に従うホスト名解決 | OSや一般的なアプリに近い経路を確認 |
getent ahosts | getaddrinfo()相当でIPv4/IPv6候補を列挙 | 返るアドレスファミリや複数結果を確認 |
resolvectl query | systemd-resolved経由の名前解決 | systemd-resolved利用環境 |
dig | DNS問い合わせと応答コード | DNSサーバー・レコード・応答を直接確認 |
nslookup | DNSへの簡易問い合わせ | 利用可能な環境で手早くDNS応答を確認 |
getentでLinuxの名前解決経路を確認する
getentはName Service Switch（NSS）を通るため、/etc/hostsやnsswitch.conf、利用中のNSSモジュールを含むOS側の名前解決確認に向いています。ahostsはgetaddrinfo()を利用してアドレスを列挙します。
digが成功してもgetentが失敗するなら、DNSサーバーだけでなくNSS・hosts・resolver統合部分を優先して確認します。resolvectlでsystemd-resolvedの実効状態を確認する
systemd-resolvedを利用している環境では、DNSサーバーや検索・ルーティングドメインがリンク単位で設定される場合があります。複数NICやVPNでは、/etc/resolv.confだけでは実際の問い合わせ先を把握できないことがあります。
digでDNSサーバーへの問い合わせを確認する
digでは応答ヘッダーのstatus、ANSWER、問い合わせ先サーバー、応答時間を確認できます。DNSサーバーを明示して結果を比較すると、通常選択されているresolverと特定DNSサーバーの差を切り分けられます。
digはDNS問い合わせ確認には有効ですが、アプリが使うNSS経路をそのまま再現するわけではありません。getentとの比較が重要です。nslookupは簡易なDNS確認に使う
nslookupでもDNSサーバーを指定して問い合わせできます。ただしOSのNSSや/etc/hostsを含む名前解決全体の確認にはgetentを使い、詳細なDNS応答の調査にはdigを使う方が切り分けしやすくなります。
結果の差から次の確認先を決める
| 結果 | 次に確認する場所 |
|---|---|
getent成功 / dig成功 | OS側名前解決は概ね成功。問題が特定アプリだけならアプリ固有設定・proxy・コンテナ等を確認 |
getent失敗 / dig成功 | /etc/nsswitch.conf、/etc/hosts、NSSモジュール、systemd-resolved連携 |
通常dig失敗 / @DNS指定成功 | 通常選ばれているDNSサーバー、リンク、VPN、resolver設定 |
| 特定DNSでもtimeout | 経路、Firewall、DNSサーバー到達性、UDP/TCP 53 |
NXDOMAIN / SERVFAIL | digのstatus別切り分け |
実務で使う確認コマンド例
DNSサーバーを変更する前に、現在の設定・問い合わせ先・失敗結果を記録しておくと、変更前後を比較できます。
設定変更前のチェック
- 実際に失敗しているFQDNで確認したか
getentとdigの両方を比較したか/etc/resolv.confの管理元を確認したか- VPNや複数NICでDNSルートが分かれていないか
- DNSサーバー変更前の結果を記録したか