夜中の3時、PagerDutyの甲高いアラート音で飛び起きた経験はあるかい？「APIのレスポンスがタイムアウトする」「特定のマイクロサービスから外部への名前解決が突然コケ始めた」――。そんな修羅場で、ただ呆然と ping を叩いたり、ブラウザのリロードを繰り返したりしているうちは、一人前のインフラエンジニアとは言えない。
データセンターのNOC（ネットワークオペレーションセンター）で数々の障害を切り分けてきた私から言わせれば、DNSのトラブルシューティングにおける最強の武器、それは dig コマンド、そしてその真骨頂である +trace オプションだ。
今回は、キャッシュの温床に隠された真実を暴き、ルートネームサーバーから権威サーバーに至るまでの名前解決の全貌を丸裸にする dig +trace の世界へ君を案内しよう。
—
なぜ、いつもの nslookup や素の dig では障害が解決しないのか？
Web APIの設計やインフラ運用において、DNSはすべての通信の起点だ。アプリケーションから api.example.com のようなホスト名がリクエストされた瞬間、OSの resolver は裏側で目にも留まらぬ速さでIPアドレスへの変換を行っている。
普段、私たちは手軽に nslookup api.example.com や、オプションなしの dig api.example.com を使いがちだ。しかし、これらには大きな「罠」がある。それは、OSのキャッシュや、ローカルのフルリゾルバー（ISPや社内ネットワークのDNS、あるいは 8.8.8.8 などのパブリックDNS）が持っているキャッシュ結果をそのまま返してしまっている可能性が高いという点だ。
「ローカルのキャッシュサーバーが正常に答えを返している」状態と、「インターネットのDNS階層構造全体が正しく機能している」状態は、全く別物なのだ。
ここに障害の種がある。例えば、権威ネームサーバー側でレコードの委譲（Delegation）が壊れていたり、Glueレコードが欠落していたりする場合、ローカルキャッシュが切れた瞬間に名前解決が連鎖的に崩壊する。この「根っこから葉っぱに至るまでの全プロセス」を自分の目でライブ中継のように確認できるのが、dig +trace なのだ。
—
dig +trace が暴く、DNS再帰解決のリアルな舞台裏
dig +trace を実行すると、コマンドは通常のDNSクライアントの挙動を完全にバイパスする。ローカルのキャッシュサーバーに「答えをくれ」と頼むのではなく、自らが「フルリゾルバー（フル機能の再帰リゾルバー）」として振る舞い、DNSの階層構造をトップからボトムへと自力で辿っていくのだ。
通信のフロー（シーケンス）を大まかに分解すると、以下のようになる。
1. ルートヒント（Root Hints）への問い合わせ:
世界に13組織（実体としてはエニーキャストで数百拠点）存在するルートネームサーバー（a.root-servers.net など）のいずれかに対し、「`.（ルートドット）」の情報を要求する。ルートサーバーは「お前が探しているドメインのトップレベルドメイン（TLD）を管理しているのはこのサーバー群だ」という、TLDサーバーのリスト（NSレコード）を返す。
2. TLDサーバーへの問い合わせ:
例えば .com や .jp といったTLDを管理するサーバー（例: a.gtld-servers.net）へ直接問い合わせを行う。TLDサーバーは、「そのドメインの権威サーバー（Authoritative Name Server）はこれだ」というドメイン独自の権威DNSサーバーの情報を返す。
3. 権威サーバーへの問い合わせ:
最終的に、ドメインを実際にホストしている権威ネームサーバー（例: ns1.example.com）へ直接問い合わせ、そこで初めて A レコードや CNAME レコードといった実データを手に入れる。
この一連のステップを、すべてパケットレベルの挙動を模しながらターミナルに描き出してくれるのが dig +trace の真価である。
—
実戦投入：dig +trace の出力結果を読み解く
実際にターミナルで以下のコマンドを叩いてみよう。ここでは例として example.com をトレースしてみる。
# 最も純粋な形でルートからの再帰トレースを実行する
dig +trace example.com実行すると、流れるようなログが出力される。出力される情報の読み方を、実際の現場の視点でステップごとに解説しよう。
ステップ1：ルートサーバーからの応答（HINTS）
最初に表示されるのは、ルートヒントを使った .（ルート） ゾーンの取得だ。
; <<>> DiG 9.16.1-Ubuntu <<>> +trace example.com
;; global options: +cmd
.ゥ 518400 IN NS a.root-servers.net.
.ゥ 518400 IN NS b.root-servers.net.
...（中略：13個のルートサーバー群のNSレコード）...
;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 msここで注目してほしいのは、最下行の Received 525 bytes from 127.0.0.1#53 という部分だ。dig +trace は、まず最初にローカルの resolver（通常は 127.0.0.1 や /etc/resolv.conf に書かれたもの）からルートサーバーのIPアドレス一覧（ヒント情報）だけを取得し、そこから先はローカルのキャッシュを一切使わずに、自力で各サーバーへUDP/53番ポートで直接クエリを飛ばし始める。
ステップ2：TLDサーバー（.com）への問い合わせ
ルートサーバーから得た情報を元に、次は .com TLDを管理するサーバー群のいずれかへ直接クエリが飛ぶ。
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.
;; Received 811 bytes from 192.5.6.30#53(f.gtld-servers.net.) in 120 msここでのポイントは、192.5.6.30#53(f.gtld-servers.net.) から応答を受け取っているという点だ。ローカルのDNSサーバーを完全に経由せず、.com TLDのオーソリティと直接通信していることがこの記述から一発で分かる。
ステップ3：権威サーバーからの最終回答
最後に、example.com のゾーンを実際に握っている権威ネームサーバーとの通信が行われる。
example.com. 86400 IN A 93.184.216.34
;; Received 56 bytes from 192.0.32.10#53(a.iana-servers.net.) in 45 msこれで完全な名前解決のパスが証明された。もしこの途中でタイムアウトしたり、おかしなドメインに飛ばされたりしていれば、「どの階層のどのサーバーで名前解決が途切れているか」がピンポイントで特定できるというわけだ。
—
現場で役立つ dig の実用テクニックとパラメータ
NOCの現場やWeb APIのデバッグにおいて、+trace 以外にも知っておくべき強力な dig のオプションがある。いくつか実用的なものを紹介しよう。
1. 特定のDNSサーバーを直接指し示す（@server）
「パブリックなキャッシュサーバーではなく、特定のAWS Route 53のネームサーバーが正しい応答を返すかテストしたい」という場合は、@ を使う。
# Route 53の特定ネームサーバーに対して直接Aレコードを問い合わせる
dig @ns-123.awsdns-12.org example.com A※ +trace と @server を同時に指定すると、トレースの起点が変わってしまうため、特定のサーバーの挙動を見たいときは単体で @server を使うのが定石だ。
2. クエリのタイプを絞り込む（A, AAAA, TXT, MX, CNAME）
デフォルトでは A レコードが引かれるが、APIのドメイン認証などで TXT レコードや CNAME を追う必要があるときは明示的に指定する。
# SPFやDKIM、Let's EncryptのDNS認証などで使うTXTレコードの確認
dig +trace _acme-challenge.api.example.com TXT3. ショート出力で結果だけを綺麗に抜く（+short）
シェルスクリプトやCI/CDパイプラインの中でIPアドレスだけをサクッと取得したいときは、ノイズを一切削ぎ落とす +short が重宝する。
# 余計なヘッダーや統計情報を省き、IPアドレスの文字列のみを出力する
dig +short api.example.com—
アプリケーション開発・インフラ運用におけるコードからのDNS検証
インフラエンジニアだけでなく、Web APIを設計・開発するプログラマーにとっても、DNSの挙動をコードレベルで意識することは極めて重要だ。特に、カスタムDNSリゾルバーを使用する場合や、コネクションプーリングを行っている環境では、DNSのTTL（Time To Live）や再帰解決の挙動がそのまま可用性に直結する。
以下に、Python（dnspython ライブラリ等を使用）や、一般的なトラブルシューティングで使う curl の実用的なスニペットを示す。
Pythonによる簡易的な名前解決とTTLの検証
インフラの自動化スクリプトや、カスタムヘルスチェックツールなどで使える、DNSの応答時間とTTLを測定するコードの例だ。
import dns.resolver
def check_dns_resolution(domain: str):
"""
指定されたドメインのAレコードとTTLを安全に取得し、
DNSの応答状態を検証する実用的な関数。
"""
try:
# リゾルバーのインスタンスを生成
resolver = dns.resolver.Resolver()
# タイムアウトを2秒に設定（障害時にブロックし続けないため）
resolver.timeout = 2.0
resolver.lifetime = 2.0
# Aレコードを照会
answer = resolver.resolve(domain, 'A')
print(f"=== DNS Resolution Success: {domain} ===")
print(f"TTL: {answer.rrset.ttl} seconds")
for rdata in answer:
print(f"IP Address: {rdata.address}")
except dns.resolver.NXDOMAIN:
print(f"[ERROR] Domain not found (NXDOMAIN): {domain}")
except dns.resolver.Timeout:
print(f"[ERROR] DNS query timed out for: {domain}")
except Exception as e:
print(f"[ERROR] An unexpected DNS error occurred: {e}")
if __name__ == "__main__":
# デバッグ対象のAPIドメイン
check_dns_resolution("api.example.com")curlにおけるDNS解決の強制とデバッグ（--resolve）
APIの負荷テストや、新規に構築したロードバランサー（ALBやCloudflare等）への切り替え直前テストにおいて、「本番切り替え前に、特定のIPアドレスに対して直接HTTPリクエストを飛ばしたい」という場面は多々ある。
そんなときは curl の --resolve オプションが最高に役立つ。
# api.example.com の 443ポート への通信を、
# DNSを引かずに強制的に 192.0.2.1 にルーティングしつつ、TLSのSNIも正しく渡す
curl -v --resolve api.example.com:443:192.0.2.1 https://api.example.com/healthzこのコマンドを使えば、DNSの切り替えが完了していなくても、新しいサーバーが正しくリクエストを処理できるかを完全にテストできる。インフラエンジニアなら必ず体に叩き込んでおきたいテクニックだ。
—
シニアエンジニアからの教訓：障害対応は「足元」から疑え
ネットワークの世界では、複雑なレイヤーで障害が発生しているように見えて、その実「DNSの委譲ミス」や「TTL切れの瞬間のキャッシュ汚染」といった、非常にプリミティブな部分が原因であることが少なくない。
アプリケーションのログを何時間も睨めっこする前に、まずはターミナルを開き、dig +trace を叩いてみるんだ。パケットがルートサーバーからどのような軌跡を描いて手元の環境にたどり着いているのか、その「道筋」を自分の目でライブで確認する。
その泥臭くも確実なプロセスこそが、どんな難解な障害をも最短でシュリンク（縮小）させる、最強のスキルとなるはずだ。さあ、次のアラートが鳴る前に、手元の端末で一度トレースを試してみるといい。
コメント