【実録】nslookupは正常なのにpingが飛ばない？DNSの仕組みと「hostsの罠」をプロが徹底解説

インフラエンジニアとして18年、大規模なシステム運用に携わってきましたが、現場で最も「原因の切り分け」を難しくさせる技術の一つがDNS（Domain Name System）です。

「設定は正しいはずなのに、なぜかサイトが表示されない」「切り替えたはずのIPアドレスに飛ばない」……。そんな時、あなたはどこを調査しますか？この記事を読めば、原因不明の名前解決トラブルで徹夜するリスクを激減させ、プロとしての確実な調査スキルが身につきます。

なぜインフラのトラブルは「DNS」に集約されるのか？

エンジニアの間には「It’s always DNS（原因はいつだってDNSだ）」という格言があるほど、DNSはトラブルの火種になりやすい技術です。

その理由は、DNSが単一のサーバーではなく、世界中のサーバーが連携して動く「分散型データベース」であり、さらに各所に「キャッシュ」が存在するからです。仕組みを表面だけで理解していると、思わぬ「見えない壁」にぶつかることになります。

DNSの仕組み：名前解決の「バケツリレー」

DNSの役割は、ドメイン名をIPアドレスに変換することですが、その実態は壮大な「バケツリレー」です。ブラウザにURLを打ち込んだ瞬間、以下のプロセスが走ります。

1. スタブリゾルバ（あなたのPC）： 「このURLのIPを教えて！」とリクエストを発信。
2. キャッシュサーバー（司令塔）： プロバイダ等が提供するサーバー。過去の回答を覚えていなければ、権威DNSサーバーへ聞きに行きます。
3. 権威DNSサーバー（情報の持ち主）：
   • ルートサーバーが「次は .jp へ行け」と指示。
   • .jpサーバーが「次は example.jp へ行け」と指示。
   • example.jpサーバーが「正解は 192.0.2.1 です！」と回答。

この「再帰問い合わせ」と「反復問い合わせ」の構造を理解しておくと、「どこまで回答が届いていて、どこで止まっているのか」を冷静に切り分けられるようになります。

現場で差がつく「レコード設定」と「TTLキャッシュ」の勘所

実務でDNSを扱う際、絶対に避けて通れないのがレコードの種類とキャッシュ（TTL）の概念です。

主要なレコードの種類

• Aレコード： ホスト名をIPv4アドレスに紐付ける基本。
• CNAMEレコード： ホスト名の「別名」を定義。ロードバランサーの配下などで多用します。
• MXレコード： メールの配送先を指定。
• TXTレコード： SPF設定など、ドメインの所有証明やセキュリティ設定に必須。

「DNSの浸透」という誤解

よく「設定が反映されるまで数時間待つ（浸透待ち）」と言われますが、これは正確には「古いキャッシュの有効期限（TTL）が切れるのを待っている」状態です。 移行作業の前には、あらかじめTTLを短く（例：300秒など）設定しておく。これが、ダウンタイムを最小限にするプロの作法です。

【現場の失敗談】nslookupの結果を信じてはいけない理由

ここからが本題です。私が以前、サーバーの移行作業をしていた時に起きた、ある「矛盾」の物語をお話しします。

発生した事象：検証結果の食い違い

新サーバーへの切り替えのため、DNSのAレコードを新IPアドレスに変更しました。確認のため、エンジニアお馴染みの調査コマンドを叩きます。

nslookup server.example.jp → 結果：新IPアドレス（192.0.2.100）が表示。 「よし、DNSの反映は完了したな！」と確信しました。

しかし、いざアプリケーションから接続しようとするとエラーが発生。なぜか旧サーバーに繋がってしまいます。不審に思い、ホスト名指定でpingを打ってみると……。

ping server.example.jp → 結果：旧IPアドレス（198.51.100.50）に対して応答している！

「nslookupでは新しいIPなのに、実際の通信（ping）は古いIPを見ている」という、魔法のような矛盾が発生したのです。

盲点となる「hostsファイル」の優先度と運用ルール

この矛盾を解く鍵は、OSが名前を解決する際の「絶対的な優先順位」にありました。

実は、PCがIPアドレスを調べる際、いきなりDNSサーバーに聞きに行くわけではありません。以下の順序で確認を行います。

1. ブラウザやアプリの独自キャッシュ
2. OSのDNSキャッシュ（ipconfig /displaydns で確認可能）
3. hostsファイル（← 今回の犯人はこれ！）
4. DNSサーバーへの問い合わせ（nslookupが参照する場所）

なぜ矛盾が起きたのか？

調査の結果、検証用端末の hosts ファイル（Windowsなら C:\Windows\System32\drivers\etc\hosts）に、過去のテストで書き込まれた古いIPアドレスの記述が残っていたのです。

• nslookup： OSのロジックを無視して、直接DNSサーバーに正解を訊ねるコマンドです。だから「サーバー上の正しい新IP」を返しました。
• ping やアプリ： 標準的なOSのルールに従います。DNSよりも優先される hosts ファイルの内容を「絶対的な正義」として信じ込んでいたのです。

明日から使える！DNSトラブルを最短で解決する「調査の型」

インフラエンジニアとして、同じ罠にハマらないための「調査の型」を伝授します。

1. 「解決」と「疎通」を分離する： nslookup が成功しても、それは「DNSサーバーが正常であること」の証明にしかなりません。実際の通信がどのIPに向かっているかを ping や curl -v で必ず確認しましょう。
2. キャッシュを疑う： 設定変更後は ipconfig /flushdns でOSのキャッシュをクリアする癖をつけましょう。
3. hostsファイルを確認する： 「自分は書いていない」と思っても、前の担当者や過去の自分が残した「足跡」が潜んでいることがあります。
4. 作業のクリーンアップを徹底する： テストでhostsを書き換えたら、作業完了後に即座に削除（またはコメントアウト）する。これがチームメンバーを救うことに繋がります。

まとめ：仕組みを知れば「見えない壁」は壊せる

DNSは一見シンプルですが、hostsファイルや複数のキャッシュが絡み合うことで、時に複雑な挙動を見せます。しかし、今回解説した「名前解決の優先順位」を頭に入れておけば、どんなトラブルが起きても冷静に最短ルートで解決できるはずです。

「It’s always DNS」。その中には、私たちの手元にある1枚のテキストファイル（hosts）も含まれていることを忘れないでください。

仕組みを深く理解し、推測ではなく根拠に基づいた調査ができる「頼れるインフラエンジニア」を一緒に目指していきましょう！