ホスト名からIPアドレスを調べる運用手順｜dig/host/getentの使い分け【2026年版】

名前解決の「経路」を意識することが運用の出発点

Linuxサーバーでホスト名からIPアドレスを調べる機会は、接続障害の調査、Ansible・Terraformの動作確認、監視エージェントの設定検証など、日常的な運用作業のあちこちで発生します。

問題は「どのコマンドを使えばよいか」ではなく、「どの名前解決経路を調べたいか」です。Linuxの名前解決は一枚岩ではなく、少なくとも次の3つの経路が並立しています。

• /etc/hosts（静的ホストファイル）
• DNSサーバー（/etc/resolv.conf で指定）
• /etc/nsswitch.conf が束ねるNSS（Name Service Switch）

dig と host はDNSプロトコルに直接問い合わせます。一方、getent はシステムの名前解決スタック全体（NSSを経由し、/etc/hosts も含む）を通ります。この違いを混同すると、「digでは解決できるのにアプリが接続できない」「hostsに書いたのにdigで返ってこない」といった混乱が生じます。各コマンドがどの経路を通るかを先に把握しておくことが、トラブルシューティングの速度に直結します。

各コマンドの役割と基本操作

dig — DNS応答をそのまま確認する

dig（Domain Information Groper）はDNSサーバーへの問い合わせに特化したツールです。応答のTTL、権威サーバー、レスポンスコードまで確認できるため、「DNSとして正しい答えが返っているか」を調べるときに最適です。

基本的なAレコード取得は次のように実行します。

dig example.internal A

内部DNSサーバーを明示して問い合わせたい場合は、@ でサーバーアドレスを指定します。

dig @192.168.1.53 example.internal A

出力の ANSWER SECTION に表示されるIPアドレスと status: NOERROR の組み合わせが正常な応答です。status: NXDOMAIN はレコードが存在しないことを示し、SERVFAIL はDNSサーバー側の異常を意味します。

素早く確認したい場合は +short オプションでIPアドレスだけを返させます。

dig +short example.internal A

障害対応でよく使うのが、権威DNSサーバーへの直接問い合わせです。キャッシュを経由せず、ゾーン上の正規の応答を確認できます。

# 権威NSを調べてから直接問い合わせる
dig example.com NS +short
dig @ns1.example.com example.com A

host — シンプルな名前解決確認

host コマンドは dig の簡易版と考えると分かりやすいです。DNSへの問い合わせ結果を人間が読みやすい形式で返します。スクリプトでの簡易チェックや、手早くIPを確認したいときに向いています。

host example.internal

逆引き（IPからホスト名）も同じ書き方で動作します。

host 192.168.10.5

host も dig と同様にDNSプロトコルを直接使うため、/etc/hosts の内容は参照しません。この点は混同しやすいので注意が必要です。

getent hosts — OSの名前解決スタックを通す

getent はNSSデータベースへのアクセスツールです。getent hosts を実行すると、/etc/nsswitch.conf の hosts: 行に定義された順序で名前解決を試みます。多くのディストリビューションでは files dns または files mymachines resolve [!UNAVAIL=return] dns のように設定されており、/etc/hosts が最優先されます。

getent hosts example.internal

アプリケーションが実際に行う名前解決（glibc経由）と同じ経路を辿るため、「アプリが接続できない原因を調べる」ときは getent が最も実態に近い情報を返します。

# /etc/hosts に書いたエントリが反映されているか確認する
getent hosts mydev-server

運用シナリオ：接続障害の名前解決チェックフロー

「サーバーAからサーバーBのホスト名へ接続できない」という障害を例に、3コマンドを組み合わせた調査手順を示します。

ステップ1：OSレベルの名前解決を確認する

getent hosts target-server

ここで何も返らない場合、アプリケーションも同様に解決できていません。/etc/hosts に静的エントリを追加するか、DNSへの登録状況を次のステップで確認します。

ステップ2：DNSとして登録されているかを確認する

dig target-server A +short

dig では解決できて getent では解決できない場合、nsswitch.conf の設定またはsystemd-resolvedのスタブリゾルバーに問題がある可能性があります。

ステップ3：参照しているDNSサーバーを特定する

# systemd-resolved 環境（Ubuntu 20.04以降、RHEL 9以降など）
resolvectl status

# 従来環境
cat /etc/resolv.conf

ステップ4：対象DNSサーバーへ直接問い合わせる

dig @<DNSサーバーIP> target-server A

直接問い合わせで解決できるのに通常の名前解決で失敗する場合、スタブリゾルバー（127.0.0.53）と上位DNSサーバーの間に問題があります。設定の再確認またはsystemd-resolvedの再起動を検討します。

systemd-resolved 環境での注意点（2026年現在）

Ubuntu 20.04以降、Debian 12以降、RHEL 9以降など、現在主流のディストリビューションではsystemd-resolvedがデフォルトで有効です。この環境では従来の名前解決と動作が異なる部分があるため、把握しておく必要があります。

• /etc/resolv.conf は /run/systemd/resolve/stub-resolv.conf へのシンボリックリンクとなっており、直接編集しても再起動で上書きされます。DNSサーバーの設定変更はNetworkManagerまたは /etc/systemd/resolved.conf を通じて行います。
• dig や host はスタブリゾルバー（127.0.0.53）を経由してDNSを参照します。スタブリゾルバー自体が正しいDNSサーバーを向いているかを resolvectl status で確認するのが正しいアプローチです。
• mDNS（.localドメイン）やLLMNRが有効な環境では、dig が応答を返さなくても getent で解決できるケースがあります。systemd-resolvedがnss-resolveモジュールを通じてNSSに統合されているためです。

# systemd-resolved の動作確認
resolvectl query example.internal

# 設定変更後、キャッシュをクリアしてから再確認する
resolvectl flush-caches

従来の nslookup コマンドも現役ですが、出力形式が環境によってばらつく上にsystemd-resolved環境での挙動が安定しないため、新規のトラブルシューティング手順からは外しておくのが無難です。

コマンド選択の判断基準

3つのコマンドをどう使い分けるかは、「何を確認したいか」で決まります。

• アプリケーションの接続障害を調べたい → getent hosts（OSのNSSスタック全体を通す）
• DNSレコードの内容・TTL・権威サーバーを詳細確認したい → dig
• 素早くDNS解決結果だけ見たい・シェルスクリプトで簡易チェックしたい → host または dig +short
• 内部DNSサーバーの応答をキャッシュなしで直接確認したい → dig @<サーバーIP>
• systemd-resolved 環境で参照先DNSを確認・変更したい → resolvectl status

名前解決の問題は、単一のコマンドだけで原因を特定しようとすると見誤ります。getent でOSスタック全体を確認し、dig でDNSプロトコルレベルを掘り下げ、resolvectl でsystemd-resolvedの状態を押さえる、という3段階のアプローチが現場での標準的な手順です。各ツールの担当範囲を正確に理解することで、障害の切り分けにかかる時間を大幅に短縮できます。