現場の最前線でトラブルと向き合っていると、深夜の障害対応で最も頼りになるのは結局、高級な監視ツールではなく「手元の dig コマンド」だったりする。
今日は、DNSという「インターネットの心臓」を診断するための唯一無二のツール、dig の出力構造を徹底的に解剖しよう。教科書には載っていない、現場で「どこが詰まっているか」を即座に判断するための知見を共有する。
—
1. なぜ「DNSの応答メッセージ」を理解する必要があるのか
Web APIが疎通しない、あるいは特定の環境からだけ疎通が遅い。そんなとき、原因がアプリケーション側にあるのか、ネットワーク側にあるのか、それとも単なるキャッシュ汚染なのか。これを切り分けるには、OSが隠蔽しているDNSの「生データ」を見る必要がある。
dig を打ったときに返ってくるあの膨大なテキストは、単なる情報の羅列ではない。RFC 1035で定義された論理セクションであり、それぞれの役割を知ることで「パケットがどこで迷子になっているか」が透けて見えるようになる。
2. DNS応答の4つのセクション：解剖図
まずは、基本の dig を見てみよう。
# google.com のAレコードを問い合わせる
dig google.com A出力には必ず以下の4つのセクションが含まれているはずだ。
QUESTION SECTION（問い）
自分が投げたクエリそのものだ。ここが間違っていれば、以降のすべてが無意味になる。「何を解決しようとしたのか」の確認用だ。
ANSWER SECTION（答え）
本丸だ。問い合わせた名前に対する正解（IPアドレスやCNAMEなど）がここに入る。ここが空っぽ、あるいは期待しないIPを返しているなら、ゾーンファイルの設定ミスか、キャッシュサーバの誤った情報を疑うべきだ。
AUTHORITY SECTION（権威）
ここが初心者がスルーしがちなポイントだ。「誰がこのゾーンの本当の管理人なのか（権威DNSサーバ）」が記述されている。DNSの再帰解決がうまく機能していない時、このセクションを見ると「どのサーバまで問い合わせが届き、どこで止まったか」のヒントが隠されていることが多い。
ADDITIONAL SECTION（付録）
「おまけ」に見えて、実は非常に重要だ。例えば、権威サーバのドメイン名が解決できない場合に備え、そのサーバのIPアドレスをあらかじめ添えてくれている。ここでレイテンシが発生しているケースも少なくない。
—
3. 実践：デバッグで「何を見るか」
ケース1：レコード不整合の特定
Web APIのデプロイ後に「特定の環境からだけ古いIPに繋がる」という事象はよくある。そんな時は +trace オプションを使って、ルートサーバから権威サーバまでを追跡する。
# 再帰解決の経路を追跡し、どこのキャッシュが汚染されているか特定する
dig +trace example.comケース2：ゾーン転送のテスト
セカンダリDNSサーバが正しく同期されているか確認したい場合、axfr（ゾーン転送）を試す。
# 権威サーバに対してゾーン情報を要求する
dig axfr @ns1.example.com example.com※ もちろん、セキュリティ設定で許可されているサーバに対してのみ実行すること。もしこれで拒否されるなら、アクセス制御リスト（ACL）の設定ミスだと即断できる。
—
4. コードからDNSを操作する際の注意点
アプリケーションからDNSを叩く際、dig と同じ挙動を再現しなければならない場面がある。Pythonの dnspython を使うと、セクションごとの解析が容易になる。
import dns.resolver
# 特定の権威サーバを指定して問い合わせる例
resolver = dns.resolver.Resolver()
resolver.nameservers = ['8.8.8.8'] # Google Public DNSを指定
try:
# Aレコードの解決
answers = resolver.resolve('example.com', 'A')
for rdata in answers:
print(f"IPアドレス: {rdata.address}")
except Exception as e:
print(f"解決失敗: {e}")API設計の現場では、curl を使ってDNS解決時間を含めたパフォーマンス測定を行うのが定石だ。
# DNS解決時間や接続時間などをフォーマットして計測
curl -o /dev/null -s -w \
"DNS解決時間: %{time_namelookup}s\n接続時間: %{time_connect}s\n合計時間: %{time_total}s\n" \
https://api.example.com—
シニアエンジニアからのアドバイス
ネットワークトラブルの多くは「思い込み」から始まる。
「DNSサーバは動いているはずだ」「キャッシュはクリアしたはずだ」という先入観を捨て、dig の出力結果という「動かぬ証拠」だけを信じてほしい。
特に AUTHORITY SECTION に注目する癖をつけると、DNSの階層構造が見えるようになる。そうすれば、TTL（Time To Live）がなぜこれほど重要なのか、あるいは「なぜ伝播に時間がかかるのか」という疑問も、すべて論理的に説明できるようになるはずだ。
現場で困ったら、まずは dig を叩け。そこには、パケットが駆け抜けたリアルな軌跡が必ず記されている。
コメント