DNSの「迷子」を救え！ dig +traceで覗く、インターネットという名の巨大な郵便局
こんにちは！NOCの現場で数々のネットワークトラブルと格闘してきた、筆者です。
みなさんが普段、ブラウザのアドレスバーに「google.com」と入力する瞬間。実はその裏側で、目にも留まらぬ速さで壮大な「郵便配達の物語」が繰り広げられていることをご存知でしょうか？
今日は、DNSがうまく解決できない、あるいは「なんだかWebサイトの表示が遅いな？」という時に、僕らエンジニアが真っ先に手に取る魔法の杖、dig +traceコマンドについてお話しします。
—
DNSの解決は「たらい回し」じゃない、「リレー」なんだ
DNS（Domain Name System）は、人間が理解できるドメイン名を、コンピュータが理解できるIPアドレスに変換するサービスです。
これを現実世界に例えると、「膨大な住所録を持つ巨大な郵便局のチェーン」のようなものです。
1. ルートDNSサーバ（総本山）： 「.com」の担当部署はどこかを知っている。
2. TLD DNSサーバ（.com担当）： 「google.com」の担当部署はどこかを知っている。
3. 権威DNSサーバ（google.com担当）： 「google.comの住所（IPアドレス）」そのものを知っている。
通常、皆さんのPCは「フルリゾルバ（再帰的リゾルバ）」という優秀な秘書に「住所調べておいて！」と丸投げしています。しかし、その秘書がどこで迷っているのかを知りたいとき、この+traceオプションが威力を発揮します。
—
dig +traceを叩いてみよう
まずは、実際にコマンドを打ってみましょう。手元のターミナルで以下を入力してみてください。
# google.comの名前解決プロセスを、ルートから一つずつ追跡する
dig +trace google.com実行すると、ズラズラと大量のテキストが出てきますよね。でも、怖がらないでください！ これ、実は「バケツリレーの全記録」なんです。
1. ルートサーバへの問い合わせ
一番最初に出てくるのは、.（ルート）の情報を管理しているサーバへの問い合わせです。ここで「.comを扱っているのはどこ？」と聞きます。
2. TLDサーバへの問い合わせ
次に、ルートから教わった.comの担当サーバへ飛びます。そこで「google.comの担当はどこ？」と聞きます。
3. 権威DNSサーバへの到達
最後に、google.comの管理者が設定した本当の住所録を持つサーバへ辿り着きます。ここでようやく「おっ、IPアドレスは 142.250.xxx.xxx だよ」という回答が得られるのです。
—
なぜ、このコマンドが「トラブル解決の切り札」なのか
現場で障害対応をしていると、「特定のサイトだけ繋がらない」「名前解決がやけに遅い」という相談をよく受けます。そんな時、dig +traceを使うとこんなことが分かります。
- 「たらい回し」の犯人が特定できる：
もし途中のTLDサーバからの応答が異常に遅ければ、インターネットのバックボーンや、その特定のDNSゾーンに問題がある可能性が高いと判断できます。
- キャッシュに騙されない：
PCやOSが持っている「古い記憶（キャッシュ）」を無視して、今この瞬間の「正しい住所」を一番大元から聞きに行くので、設定変更が反映されているかの確認にも最適です。
—
もっと深く知りたいあなたへ：小技のご紹介
ただの結果を見るだけじゃなくて、少しだけコマンドをカスタマイズして「現場力」を上げましょう。
# タイムアウト時間を指定して、応答の遅延をよりシビアにチェックする
dig +trace +time=2 +tries=1 google.com
# どんな種類のDNSレコード（AレコードやMXレコードなど）を追いたいか指定する
# 例：メールサーバの情報（MX）を追跡したい場合
dig +trace mx google.com-time や -tries を調整することで、「どの段階でパケットが迷子になっているのか」をより正確に切り分けることができます。
—
最後に：ネットワークエンジニアへの第一歩
dig +trace は、インターネットという見えない巨大な仕組みを「可視化」する最強のツールです。
最初は画面を流れる大量のテキストに圧倒されるかもしれません。でも、一つずつ「これはルートサーバへの手紙だな」「これは返信だな」と紐解いていけば、必ず仕組みが見えてきます。
トラブルに直面したとき、焦って設定ファイルをいじり回す前に、まずはdig +traceで「手紙はどこで止まっているのか？」を確認してみてください。その冷静な一歩が、あなたを一流のインフラエンジニアに成長させるはずです。
それでは、また次の現場でお会いしましょう！
コメント