DNSを外してhostsに書いたのにnslookupで名前解決できない原因と対処法【Windows】

「DNSサーバーを外して hosts に書いたのに nslookup が『IP not resolved』になる」。Windows サーバーやクライアントで非常によく出会うトラブルです。本記事では、なぜそうなるのかという仕組みから、DNSなしで hosts だけを使う場合／DNSを使う場合それぞれの実務的な手順、チェックポイントまでをまとめて解説します。

想定しているトラブルの状況

まずは、よくある相談パターンを整理します。

サーバーから DNS サーバーの役割を外した、もしくは DNS サーバーが停止している
接続したいホストの IP アドレスを C:\Windows\System32\drivers\etc\hosts に追記した
ping app.example.local は通る、もしくは IP アドレスに解決されている
しかし nslookup app.example.local を実行すると 「IP not resolved」や「Non-existent domain」 などのエラーになる

この動作は一見すると矛盾しているように見えますが、実は Windows の仕様通りであり、故障でもバグでもありません。原因を理解するには、まずツールごとの「名前解決の経路」の違いを押さえる必要があります。

なぜ hosts に書いたのに nslookup が失敗するのか

nslookup は「DNS専用クライアント」である

nslookup は「DNS サーバーに直接問い合わせる」ためのツールです。DNS 以外の名前解決方式（hosts、NetBIOS、LLMNR など）は一切参照しません。そのため、DNS サーバーが使えない構成では、必ず失敗します。

逆に ping や多くのアプリケーションは、Windows が提供する「標準の名前解決 API（getaddrinfo）」を利用します。この API は hosts → DNS → その他（LLMNR / NetBIOS など） の順に問い合わせるため、hosts に正しく書いてあれば、DNS がなくても名前解決できます。

コマンド / アプリ	主な用途	参照する名前解決	DNSサーバーなしのとき
`nslookup`	DNSレコードの確認、トラブルシュート	DNSサーバーのみ	必ず失敗（hostsは見ない）
`Resolve-DnsName`（PowerShell）	DNSクエリの実行	DNSサーバーのみ	nslookup と同様に失敗
`ping`	疎通確認	Windows標準解決（hosts → DNS → そのほか）	hostsが正しければ成功
`Test-Connection`（PowerShell）	詳細な疎通確認	Windows標準解決	hostsが正しければ成功
ブラウザ / 各種アプリ	Webアクセスなど	多くはWindows標準解決	hostsが正しければ成功

したがって、次のように整理できます。

DNS を使わない（使えない）環境では、nslookup は必ず失敗するのが仕様
hosts を使った疎通確認は ping / Test-Connection / 実際のアプリ で行う
nslookup を成功させたい＝DNS を使う構成にする必要がある

Windows の名前解決の流れ（ざっくりイメージ）

Windows では、アプリケーションからの名前解決要求はおおむね次のような順番で処理されます（細かい例外はありますが、ここでは簡略化しています）。

優先順位	仕組み	説明
1	`hosts` ファイル	`C:\Windows\System32\drivers\etc\hosts` に書かれた静的な名前と IP の対応表。
2	DNS クライアント	NIC に設定された DNS サーバーに問い合わせて A/AAAA レコードなどを取得。
3	LLMNR / mDNS など	同一セグメント内での名前解決（Windows の設定による）。
4	NetBIOS など	古い方式だが、ワークグループ環境などでは今も使われることがある。

ping app.example.local などはこの流れで名前解決するのに対し、nslookup は「2. DNS クライアント」に直接問い合わせるイメージ、つまり 1. hosts を飛ばしていきなり DNS に聞きにいく ため、DNS がいない環境では当然失敗します。

DNSなしで hosts だけで運用したい場合の実務手順

まずは「DNS サーバーは使わない」「一時的に hosts だけで疎通を確認したい」ケースの手順です。

hosts ファイルの場所と基本的な書き方

Windows の hosts ファイルはここにあります。

C:\Windows\System32\drivers\etc\hosts

編集時の基本ルールは次の通りです。

項目	ポイント
権限	メモ帳などのエディタを「管理者として実行」して開くこと。
ファイル名	拡張子なしの `hosts`。`hosts.txt` にしない。
書式	行頭に IP アドレス、続けて空白またはタブ区切りで FQDN、必要なら短縮名（別名）を書く。
コメント	`#` から行末まではコメントとして無視される。
文字	スペースは半角を使う。全角スペースや不可視文字に注意。

典型的な記述例は次の通りです。

10.10.10.50  app.example.local  app
10.10.10.51  db.example.local   db

FQDN（app.example.local）と同時に、短縮名（app）も書いておくと便利です。
ユーザーが app とだけ入力してアクセスする場合、ここに短縮名を書いておかないと名前解決できません。

IPv6 を使う場合は AAAA 用の行も追加する

Windows では環境によって IPv6 が優先されることがあります。その場合、IPv4 のみを書いていると、次のような現象が起こります。

ping app.example.local → IPv6 で名前解決を試みて失敗
ping -4 app.example.local → IPv4 固定で試すと成功

そのため、IPv6 を利用している（もしくは OS の既定で IPv6 が有効な）環境では、必要に応じて IPv6 用の行も追加します。

10.10.10.50   app.example.local  app
fe80::1234:5678:abcd:ef01  app.example.local  app

もっとも、内部サーバーで IPv6 を積極的に使わないポリシーであれば、NIC の設定やポリシーで IPv6 を無効化してしまうのも現実的な運用です（ただし、既存システムへの影響には要注意です）。

DNSキャッシュをクリアする

hosts を書き換えた直後は、クライアント側の DNS キャッシュに古い情報が残っている場合があります。そのため、必ずキャッシュをクリアしてからテストしてください。

ipconfig /flushdns

キャッシュ内容を確認したければ、次のコマンドで表示できます。

ipconfig /displaydns

ただし hosts の内容は displaydns にそのまま出てくるとは限らないため、表示されないからといって hosts が効いていないとは限らない点に注意してください。

hosts が効いているかを確認するおすすめコマンド

hosts の動作確認には「DNS専用ではない」次のようなコマンドを使います。

ping app.example.local
ping -4 app.example.local   # IPv4に固定して確認
tracert app.example.local

PowerShell が使える場合は、Test-Connection がとても便利です。

Test-Connection app.example.local -Count 3

# IPv4だけ試したい場合（PowerShell 7以降）
Test-Connection app.example.local -AddressFamily IPv4 -Count 3

これらのコマンドで

ホスト名が正しく IP アドレスに変換されている
かつ、応答が返ってくる（タイムアウトしない）

のであれば、hosts の設定としては問題なく、DNSなしでも通信に必要な名前解決はできていると判断できます。

逆に、nslookup や Resolve-DnsName は DNS にしか問い合わせません。DNS を外している構成で実行するとエラーになるのは当然であり、「エラー＝設定ミス」とは限りません。

nslookup でも成功させたい場合（DNS を使う構成にする）

次に、「やっぱり nslookup でも成功させたい」「DNS としても正しく運用したい」という場合の手順です。

NIC に DNS サーバーを設定する

まず、クライアント（もしくは問題のサーバー）の NIC に、利用する DNS サーバーを設定する必要があります。

社内 DNS サーバーを使う場合：そのサーバーの IP アドレス
インターネット向けだけなら：1.1.1.1 や 8.8.8.8 などの公開 DNS（ただし内部ホスト名は引けません）

GUI から設定しても良いですが、PowerShell でまとめて設定しておくと構成管理がしやすくなります。

Set-DnsClientServerAddress `
  -InterfaceAlias "Ethernet" `
  -ServerAddresses 10.10.10.10,1.1.1.1

10.10.10.10 が社内 DNS、1.1.1.1 がインターネット向けの公開 DNS という想定です。
インターネットに出ない閉域網の場合は、社内 DNS のみを設定します。

DNS に A / AAAA レコードを登録する

内部ホスト名を DNS でも解決させたい場合は、DNS サーバーにそのホストのレコードを登録します。Windows Server の DNS であれば、DNS マネージャーから該当ゾーンを開き、ホスト (A) レコード（必要なら AAAA レコード）を作成します。

例：ゾーン example.local に対して app.example.local を登録する場合

項目	設定例
名前	`app`
FQDN	`app.example.local`（自動表示）
IPアドレス	`10.10.10.50`
レコードの種類	ホスト (A)

DNS レコード登録後は、クライアント側でキャッシュをクリアしてから確認します。

ipconfig /flushdns
nslookup app.example.local

ここで、DNS サーバーから正しく IP アドレスが返ってくれば、DNS の設定としても問題なしと判断できます。

hosts と DNS のどちらを使うかの考え方

内部環境では、次のような使い分けがおすすめです。

場面	推奨	理由
一時的な疎通テスト	hosts	DNS の設定を変えなくても、すぐに試せるため。
本番運用の名前解決	DNS	クライアント台数が多いほど、hosts では管理しきれないため。
AD ドメイン参加 / Kerberos 認証	DNS	Active Directory は DNS を前提としているため。
シンプルな開発用スタンドアロンPC	hosts でも可	少数の PC で、対象ホストも少ない場合は hosts でも現実的。

nslookup で成功させたい＝DNS にレコードを持たせたいということなので、本番運用であれば DNS への移行（もしくは正常動作の確認）を強くおすすめします。

ありがちなつまずきポイントとチェックリスト

「hosts に書いたのに効かない」「nslookup も ping もダメ」というときに、まず確認したいポイントを一覧にしました。

症状 / 状況	よくある原因	確認・対処
ping も nslookup も解決しない	hosts ファイル名が `hosts.txt` になっている	エクスプローラーで「拡張子を表示」を有効にし、`hosts`（拡張子なし）に修正する。
特定行だけ効かない	行頭や行中に全角スペースや不可視文字が紛れている	メモ帳以外のエディタ（VS Code など）で表示し、空白を削除して書き直す。
`app.example.local` は解決するが `app` が解決しない	hosts に FQDN だけ書いている	短縮名（別名）も同じ行に追加する。
`ping` は通るが `nslookup` は失敗	DNS サーバーそのものがいない、もしくは内部ホスト名を登録していない	DNS を使うなら DNS サーバーを設定し、A/AAAA レコードを登録する。DNS を使わないなら nslookup の結果は無視する。
`ping app.example.local` は失敗するが `ping -4` は成功	IPv6 が優先されており、IPv6 の設定やルーティングが不完全	IPv6 の設定を見直すか、hosts に IPv6 用の行を追加する、あるいは環境ポリシーに沿って IPv6 を無効化する。
書き換える前の IP に解決される	DNS キャッシュに古い情報が残っている	`ipconfig /flushdns` を実行してから再テストする。

設計上の注意：hostsだけで運用すべきでないケース

hosts ファイルは便利ですが、次のような環境では恒久的な運用手段として使うべきではありません。

Active Directory ドメイン（AD DS）を利用している環境
サーバー台数、クライアント台数が多い（数十台以上）
クラスタ構成、ロードバランサーなど IP が動的に変わる構成
リモートワーク / VPN クライアントが多数存在する

これらの環境で hosts を多用すると、次のような問題が発生しやすくなります。

1台ずつ hosts を書き換える必要があり、設定漏れ・ミスの温床になる
IP 変更時に全端末の hosts 更新が必要で、計画的な切り替えが難しくなる
チーム内で「どれが正なのか」がわからなくなり、トラブル調査が極端に複雑化する

特に Active Directory を利用している環境では、DNS はドメインコントローラーと密接に結びついており、DNS サーバーの適切な設計・運用は必須です。「とりあえず hosts で何とかする」は、あくまで一時的な緊急回避としてとどめておくことを強くおすすめします。

トラブルシューティングの具体的な進め方（例）

実際に「IP not resolved」などのエラーに出会ったとき、次のような流れで切り分けていくと効率的です。

ステップ1：環境の前提条件を確認する

DNS サーバーを使う設計か？それとも一時的に DNS を外しているだけか？
問題のホスト名は「内部向け」か「インターネット向け」か？
クライアントの DNS サーバー設定はどうなっているか？

ここで「DNS サーバーを使わない構成」だとわかったら、nslookup の結果にこだわる必要はありません。

ステップ2：hosts の設定を確認する

ファイルパスが C:\Windows\System32\drivers\etc\hosts であること
拡張子なしの hosts になっていること
行頭の IP アドレス・FQDN・短縮名の並びが正しいこと
半角スペース／タブのみを使用していること

必要に応じて、別マシンから同じ内容をコピーし、改行コードや文字コードの違いも疑ってみてください。

ステップ3：キャッシュをクリアし、ping で確認する

次の順に実行します。

ipconfig /flushdns

ping app.example.local
ping -4 app.example.local

名前が正しい IP に解決されるか（応答の 1 行目）
タイムアウトにならず応答が返ってくるか

ここで名前が正しく解決され、通信もできているのであれば、少なくとも hosts ベースでの運用には問題ありません。nslookup の結果は「DNS を使っていないなら失敗して当然」と割り切って構いません。

ステップ4：DNS を使う構成にするなら、DNS の設定・登録を進める

もし、「監視ツールや他チームから nslookup の結果も要求される」「将来的に AD や他システムとの連携を考えている」といった理由で DNS を使う方針であれば、次の手順を進めます。

DNS サーバーの設計（ゾーン名、複製方式、フォワーダーなど）を決める
クライアント・サーバーの NIC に DNS サーバーを設定する
必要な A / AAAA / CNAME レコードを登録する
nslookup や Resolve-DnsName でレコードを確認する

このとき、hosts にも同じ名前を併記していると、後で「DNS の値が効いているのか、hosts が効いているのか」がわかりにくくなります。本番移行時には、hosts に書かれている重複エントリを整理・削除していくことも大切です。

「nslookup の成功」と「通信できること」は別物と理解する

現場でしばしば混同されるポイントとして、「nslookup が成功している＝通信も必ず成功する」「ping が通る＝DNS にも必ず登録済み」という誤解があります。

nslookup 成功かつ通信失敗 … DNS のレコードは正しいが、ファイアウォールやルーティング、サービス自体の状態に問題があるケース。
nslookup 失敗だが通信成功 … hosts で名前解決している、あるいはアプリ側が別の名前や IP を使っているケース。

そのため、目的に応じて次のように使い分けるのが重要です。

目的	メインで使うべきコマンド	補足
DNS レコードの状態を確認したい	`nslookup` / `Resolve-DnsName`	DNS サーバーがどう答えているかを直接確認する。
アプリが実際に到達できるか確認したい	`ping` / `Test-Connection` / 実アプリのアクセス	名前解決だけでなく、ルーティングやファイアウォールも含めた確認。
hosts が効いているか確認したい	`ping` / `Test-Connection`	nslookup は hosts を見ないので、確認用としては不適切。

まとめ：DNSを外した状態でnslookupが失敗するのは仕様

ここまでの内容を一度整理します。

nslookup は DNS 専用のツールであり、hosts ファイルなどのローカルな名前解決は参照しない。
DNS サーバーを外した構成では、nslookup は必ず失敗する（「IP not resolved」など）。
一方で、ping や多くのアプリは Windows 標準の名前解決（getaddrinfo）を使うため、hosts が正しければ名前解決できる。
DNS を使わず hosts だけで運用する場合は、hosts の正しい書き方・キャッシュクリア・ping 等による確認を行う。
nslookup を成功させたい場合は、DNS サーバーを構成し、目的のホスト名の A / AAAA レコードを DNS に登録する必要がある。
Active Directory や大規模環境では、hosts ではなく 適切に設計された DNS による運用が必須。

結論として、「DNSを外した状態で nslookup が失敗する」のは仕様であり、必ずしも異常ではありません。通信ができるかどうかの確認には ping や実アプリでの接続を使い、「何を確認したいのか」に応じてツールを使い分けることが、トラブルシューティングの近道になります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。