こんにちは！NOC（ネットワークオペレーションセンター）で、日々データセンターの荒波にもまれながらネットワークの監視や障害対応をしているシニアエンジニアです。
インフラの世界へ足を踏み入れたばかりの頃って、黒い画面（ターミナル）にずらりと並ぶ文字を見るだけで「なんだか難しそう……」と気後れしてしまいますよね。でも、安心してください！どんなに複雑に見えるネットワークの仕組みも、私たちが普段使っている「郵便配達」や「道案内」のルールに置き換えてみると、驚くほどスッと頭に入ってくるものなんです。
今回は、ネットワークの裏側でこっそりと、しかしものすごいスピードで働いている「DNS（ドメインネームシステム）」の旅を覗き見してみましょう。
特に、DNSの世界でまるで探偵のように道筋を追いかけてくれる魔法のコマンド、dig +trace について、現場の泥臭いエピソードも交えながら優しく紐解いていきますよ。
—
そもそもDNSってなぁに？ 身近な例えで考えてみよう
私たちが普段、ウェブブラウザのURL欄に https://example.com のようなドメイン名を入力すると、一瞬でそのウェブサイトが表示されますよね。
でも、ルーターやサーバーといったネットワーク機器の住人たちは、実は文字の言葉が読めません。彼らが理解できるのは 192.0.2.1 のような数字の住所、つまりIPアドレスだけです。
ここで登場するのが、名前と住所の巨大な電話帳であるDNS（Domain Name System）です。
「example.com っていう名前の人の住所を教えて！」と尋ねたら、「それは 93.184.216.34 ですよ」と教えてくれる案内係のような存在ですね。
郵便配達に例えてみるよ
あなたが東京から、北海道の「〇〇市 〇〇町 1-2」に住む友人に手紙を出したいとします。
あなたはいきなり北海道のその町まで走っていきますか？ いいえ、まずは近くのポストに手紙を投函しますよね。
1. 近くのポスト（身近な郵便局）に手紙を出す。
2. 地元の郵便局が「これは北海道行きだから、中央の大きな仕分け局に送ろう」と判断する。
3. 中央の仕分け局が、北海道の局へ送る。
4. 最終的に、その町を担当する配達員さんが宛先の家を見つけ出す。
DNSの仕組みも、これとまったく同じなんです！
—
フルリゾルバと権威DNSサーバの役割分担
DNSの世界にも、この郵便配達によく似た「役割分担」があります。
- フルリゾルバ（キャッシュDNSサーバー）
- 私たちの代わりに「住所（IPアドレス）を探してきて！」と全権を握って奔走してくれる、いわば「お使いを頼まれた身近な郵便局員さん」です。インターネットプロバイダ（ISP）や、Googleの
8.8.8.8などがこれに当たります。 - 権威DNSサーバ
- 特定のドメイン（例：
example.comなど）の「本当の住所」をカプセルに入れて大切に保管している、「その地域の番地を完全に把握している本家の住人（または管理所）」です。
フルリゾルバは、私たちが「このサイトのIPを教えて！」と頼むと、自分の記憶（キャッシュ）を探します。もし知らなければ、世界中を旅して「権威DNSサーバ」を探し出し、正しい住所を聞き出してくれるのです。
—
dig +trace でDNSの旅をのぞき見してみよう！
「フルリゾルバが、どうやって世界中から正しい権威DNSサーバを見つけ出しているのか？」
その一部始終を、自分の目でリアルタイムに追跡できるのが、今回紹介する dig コマンドの +trace というオプションです。
百聞は一見に如かず、実際にターミナルを叩いてみましょう。
# example.com の名前解決の旅を、ルートサーバから順番に追いかけてみよう！
dig +trace example.comこのコマンドを実行すると、画面にたくさんの文字が流れていきます。
一体、裏側でどんなパケットのやり取り（旅）が行われているのでしょうか？ 一歩ずつ分解して見ていきましょう！
ステップ1：ルートヒント（世界に13個ある大元締めの場所を聞く）
コマンドを実行すると、一番最初に登場するのは .（ルート）と呼ばれる世界最高峰のサーバー群です。
; <<>> DiG 9.16.1-Ubuntu <<>> +trace example.com
;; global options: +cmd
.ゥ 5 IN NS a.root-servers.net.
. 5 IN NS b.root-servers.net.
...（中略）...
;; Received 525 bytes from 127.0.0.1#53(53)これは、「すべてのドメインの頂点（ルート）を知っているのは、この人たちだよ」という最初の地図を手に入れた状態です。「すみません、example.com の場所を探しているんですが、どこに行けばいいですか？」と、まずは世界の根っこに聞きに行きます。
ステップ2：TLD（トップレベルドメイン）サーバーへバトンタッチ
ルートサーバはこう答えます。「.com のことだね？ それなら .com を管理している専用の担当者（TLDサーバー）がいるから、そっちに行きなさい」と。
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.（※実際には .com を管理するサーバーのリストが返ってきます）
これで、郵便物は「大元の仕分け局」から「.com という県（TLD）の担当局」へとバトンタッチされました。
ステップ3：権威DNSサーバに到着し、最終的な住所をゲット！
旅の終盤です。.com の担当サーバーにたどり着いたフルリゾルバは、「次は example.com の本当の管理者（権威DNSサーバー）を教えて！」と尋ねます。
すると、いよいよ example.com のゾーンを管理している権威DNSサーバの住所が判明します。最後にその権威DNSサーバへ直接質問を投げかけ……
example.com. 3600 IN A 93.184.216.34
;; Received 56 bytes from 192.0.2.123#53(example-ns.com)やったー！ 93.184.216.34 というピカピカのIPアドレスを無事に手に入れることができました！
—
実務の現場で dig +trace が役立つ瞬間
「仕組みは分かったけど、これって実際の現場で何の役に立つの？」と思ったそこのあなた。
実はNOCの現場やインフラ運用において、この dig +trace は「DNSの迷子」を救い出すための最強の切り札なんです。
例えば、こんなトラブルに遭遇したことはありませんか？
- 「新しいドメインを取得してDNSの設定をしたのに、自分のパソコンからアクセスすると『サイトが見つかりません』ってエラーになる……」
- 「社内のメンバーからは繋がるのに、外のネットワーク（自宅や別拠点）からだと古いサーバーのIPに飛ばされてしまう……」
こういう時、原因はだいたい以下のどれかです。
1. 途中のDNSキャッシュサーバーが古い情報を頑なに覚えている（キャッシュ汚染やTTLの問題）
2. どこかの階層のネームサーバー（NSレコード）の設定が間違っていて、道案内が途中で途切れている
そんな時、通常の dig example.com だと、手元のフルリゾルバが持っている「キャッシュ（記憶）」の答えをそのまま返されてしまい、本当の真実が見えません。
しかし、dig +trace を使えば、キャッシュを完全に無視して、ルートサーバーから一歩一歩、自分の目で正しい道案内が機能しているかを強制的に検証できるのです。
「あれ？ .jp のサーバーまでは行けているのに、その先の自社で管理している権威サーバーで返事が途絶えているぞ……？」
そんな風に、トラブルの発生地点（ボトルネック）をピンポイントで特定できるのが、このコマンドの最高にシブいところなんですよね。
—
まとめ：一歩ずつ、ネットワークの足跡を楽しもう
今回は、dig +trace を通して、DNSの再帰的解決（リゾルブ）の仕組みを郵便配達に例えて解説してみました。
最初は黒い画面の文字の多さに圧倒されるかもしれませんが、
- 「あ、今ルートサーバーに挨拶したんだな」
- 「お、次はドメインの担当者にバトンタッチしたぞ」
と、パケットの旅を脳内でイメージできるようになると、トラブルシューティングがまるで謎解きゲームのように楽しくなってきます。
インフラやネットワークの世界は、泥臭い検証の積み重ねです。でも、こうやって仕組みの解像度を少しずつ上げていくことで、いつの間にか「頼れるエンジニア」に一歩ずつ近づいていけますよ。
それでは、また次回のNOC現場だよりでお会いしましょう！ 日々の運用作業、一緒に頑張っていきましょうね！
コメント