DNSの「迷宮」を抜け出せ。nslookupを使いこなす現場のデバッグ術
夜中の3時、アラートの音が鳴り響く。監視ダッシュボードには「API接続エラー」の文字。Webエンジニアたちが「サーバーは生きてるはずなのに、なぜか名前解決でコケている」と騒いでいる。そんな修羅場で、初心者がまずやるのが「とりあえずpingを打つ」ことだ。しかし、ネットワークのプロは違う。彼らは真っ先に nslookup を叩き、その挙動をじっと観察する。
DNSはネットワークの「住所録」だ。ここが狂えば、どんなに高性能なAPIも、どんなに堅牢なロードバランサーも、ただの鉄の塊と化す。今日は、数々の障害現場で僕が頼りにしてきた nslookup の使い分けと、その裏側に隠された「通信の真実」を教えよう。
—
1. なぜ「対話モード」と「非対話モード」を使い分けるのか
nslookup には2つの顔がある。単発で投げる「非対話モード」と、セッションを張り続ける「対話モード」だ。
非対話モード：狙い撃ちの「スナイパー」
シェルから直接コマンドを叩くこの方法は、CI/CDパイプラインでのチェックや、障害切り分けの第一歩として最適だ。
# 特定のDNSサーバー(8.8.8.8)を明示して、Aレコードを問い合わせる
nslookup api.example.com 8.8.8.8このコマンドが実行されるとき、裏ではUDP 53番ポートでパケットが飛んでいる。応答がない場合、それは「名前解決の失敗」なのか、「DNSサーバー自体が落ちているのか」、あるいは「ファイアウォールで遮断されているのか」を瞬時に判断する必要がある。
対話モード：深掘りの「探索者」
一方で、対話モードは「DNSの挙動をじっくり観察したいとき」に使う。
# 対話モードへの入り方
nslookup
> server 8.8.8.8 # 問い合わせ先サーバーを変更
> set type=ANY # 取得するレコードタイプをANY（全て）に設定
> api.example.com # 連続して問い合わせる対話モードの最大の利点は、server を切り替えながら、同じドメインに対して「権威DNSサーバー」と「再帰リゾルバ」の間でどんな違いがあるかを連続して確認できる点にある。障害時に「キャッシュが汚染されているのか？」を疑う際、複数のサーバーを切り替えて比較するのは現場の常套手段だ。
—
2. 現場で使うべき「デバッグの要点」とパラメーター
ただコマンドを叩くだけでは意味がない。現場で重要なのは「何を確認しているか」だ。
応答コード（RCODE）を見逃すな
nslookup を実行した際、出力される以下のRCODEに注目してほしい。
NOERROR: 正常。NXDOMAIN: ドメインが存在しない。設定ミスか、伝播遅延か。SERVFAIL: DNSサーバー側のトラブル。上位サーバーとの通信失敗など。
また、set debug を使うと、パケットのシリアル番号やTTL（Time To Live）まで露わになる。APIのデプロイ後に旧IPが返ってくるような「DNSキャッシュ地獄」に陥ったとき、TTL値を確認するのは鉄則だ。
—
3. 実践：コードの中に潜むDNSの影
Web APIを開発する際、コード上でも名前解決は行われる。例えば、PythonでAPIを叩く際、DNSがボトルネックになるケースは少なくない。
import socket
import requests
# 運用上のTips:
# アプリ側でDNSタイムアウトを明示的に設定しないと、
# DNS障害時にプロセスがハングアップする原因になる。
try:
# 実際のリクエスト前に、名前解決の疎通確認をログに出す工夫
ip = socket.gethostbyname("api.example.com")
print(f"DEBUG: Resolved to {ip}")
response = requests.get("https://api.example.com/v1/data", timeout=5)
response.raise_for_status()
except socket.gaierror:
print("CRITICAL: DNS Resolution Failed.")もし、nslookup で名前解決ができるのに、curl やアプリから繋がらない場合は、/etc/nsswitch.conf の設定や、コンテナ環境における CoreDNS の設定ミスを疑うのが定石だ。
—
4. シニアエンジニアからの遺言：ツールに踊らされるな
最後に一つ、忘れないでほしいことがある。nslookup はあくまで「名前解決の診断ツール」に過ぎない。
最近では dig コマンドの方が詳細な情報を得られるため好まれる傾向にあるが、nslookup はほとんどの環境に標準で入っているという「可用性」こそが最大の武器だ。どんなにボロボロのサーバーにSSHで飛び込んでも、nslookup さえあれば、そこがネットワークの端点なのか、中間なのかを炙り出せる。
- まずは
nslookupで「名前解決ができるか」を切り分ける。 - 次に
pingで「経路があるか」を見る。 - 最後に
curl -vで「HTTPのハンドシェイク」を確認する。
この手順を体に叩き込んでおけば、どんな大規模障害も、恐れることはない。ネットワークはパケットの正直な結果しか返さない。画面の向こう側の「DNSの向こう側」を想像できるエンジニアを目指してほしい。
さて、コーヒーを飲み終えたら、次は君の番だ。現場で待っている。
コメント