DNSトラブルの「最後の砦」：nslookupを使い倒す現場の作法
ネットワークエンジニアとして深夜のデータセンターで戦っていると、往々にして「繋がらない」という叫び声が上がります。その原因の8割はDNSです。いや、肌感覚ではもっと多いかもしれない。アプリケーションがどれほど洗練されたAPI設計をしていても、名前解決という「入り口」でコケれば、すべては無に帰します。
今日は、現代のインフラエンジニアが避けては通れない、そして意外と奥が深いツール nslookup について、教科書には載っていない「現場の勘所」を解説します。
—
なぜ今さら nslookup なのか
「dig の方が情報量が多くて便利だろ？」という声が聞こえてきそうですね。確かにその通りです。しかし、Windows環境や、最小構成のコンテナイメージなど、dig がインストールされていない環境は現場にいくらでも存在します。
nslookup は、どんなに過酷な環境でも必ずそこにいてくれる頼もしい相棒です。このツールを使いこなすことは、どんな環境下でもトラブルの芽を即座に摘み取れる「現場力」に直結します。
—
1. 非対話モード：手っ取り早く「真実」を突く
日常の運用で最も使うのが非対話モードです。特定のレコードを一発で引きたいとき、あるいはスクリプトに組み込む際に使います。
基本的なクエリの投げ方
特定のドメインのIPを調べる（正引き）なら、以下のように叩きます。
# google.com の AレコードをデフォルトDNSに問い合わせる
nslookup google.com
# 特定のDNSサーバー（例: 8.8.8.8）を指定して問い合わせる
nslookup google.com 8.8.8.8ここで重要なのは、「どのDNSサーバーに聞いているか」を常に意識することです。/etc/resolv.conf の設定が汚染されていたり、ローカルキャッシュが毒されていたりする場合、サーバーを明示的に指定しないと、一生解決しない「ゾンビパケット」を追いかける羽目になります。
—
2. 対話モード：深淵を覗き込むための「セッション」
障害対応時、複数のレコードを連続して調査したり、クエリタイプを切り替えながらキャッシュの挙動を探りたいときは、対話モードが輝きます。
# 対話モードへの入り方
nslookup
# サーバーを切り替える
> server 1.1.1.1
# クエリタイプを MXレコード に変更して問い合わせる
> set type=mx
> gmail.com
# 逆引き（PTRレコード）を試す
> set type=ptr
> 8.8.8.8対話モードの利点は、「コンテキストを保持できること」です。一度サーバーを指定すれば、set type を変えるだけで、立て続けに様々なレコード（TXT や CNAME など）を掘り下げることができます。特に TXT レコードを用いた SPF や DKIM の検証など、メール配送トラブルの切り分けではこの連続性が命を救います。
—
3. 実務で遭遇する「罠」と解決策
罠1：デフォルトのタイムアウトとリトライ
nslookup は、応答がないと標準設定で数秒待機し、リトライします。障害時にこれを待つのは時間の無駄です。
# タイムアウトを短縮し、リトライ回数を減らす
> set timeout=1
> set retry=0現場では、応答が遅いサーバーは「死んでいる」と見なすべきです。潔く切り捨てる設定を覚えておきましょう。
罠2：アプリケーションからの名前解決とCLIの乖離
Web API開発において、「curl で繋がらないが nslookup ではIPが返る」という現象があります。これは、アプリケーションが利用するライブラリ（glibc の getaddrinfo など）と、nslookup が直接UDPポート53を叩く挙動の違いによるものです。
Pythonでこの挙動を再現・確認する場合は、以下のようにソケットレベルで確認するのが確実です。
import socket
# アプリケーションが実際に使っている名前解決をシミュレート
def check_dns(hostname):
try:
ip = socket.gethostbyname(hostname)
print(f"Resolved: {ip}")
except socket.gaierror as e:
print(f"DNS Resolution Failed: {e}")
check_dns("api.production.internal")—
最後に：シニアエンジニアからのアドバイス
ネットワークトラブルシューティングの極意は、「自分の道具を信じすぎないこと」にあります。nslookup が返す結果はあくまで「その瞬間の、そのDNSサーバーから見た回答」に過ぎません。
- 正引きができないなら？ →
PTRで逆引きを試し、ネットワークの到達性そのものを疑う。 - 特定のPCだけ解決できないなら？ →
hostsファイルを確認するか、ローカルのDNSキャッシュを疑う。 - API側でエラーが出るなら？ →
curl -vを併用し、HTTPヘッダーのHostフィールドとDNS解決されたIPが整合しているか確認する。
ツールはただの道具です。大切なのは、パケットがどのゲートウェイを通り、どのネームサーバーで足止めを食らっているのか、その「道のり」を脳内で描き出すこと。
今日の話が、あなたの深夜のトラブル解決の一助になれば幸いです。また現場でお会いしましょう。
コメント