みなさん、こんにちは！NOC（ネットワークオペレーションセンター）で日々、パケットの荒波と格闘しているシニアエンジニアです。
大規模なデータセンターで障害対応をしていると、「あれ、さっき直したはずのウェブサイトのIPアドレスが、なぜか古いまま変わらないぞ……？」という奇妙な現象に直面することがあります。ブラウザを変えても、ルーターを再起動してもダメ。そんなとき、私たちインフラエンジニアが真っ先に手にする魔法の杖が、DNSの調査コマンドである dig（ディグ）なんです。
今回は、この dig の中でも、ちょっと通なオプションである 「DNSキャッシュのバイパス」 と 「再帰問い合わせフラグ（RDフラグ）の制御」 について、身近な例えを交えながら優しく紐解いていきたいと思います。
難しい専門用語や複雑なパケットの仕組みで頭が痛くなる前に、まずは私たちが普段やっている「住所探しの旅」から覗いてみましょう！
—
1. 郵便配達の仕組みで理解する「DNS」と「キャッシュ」
インターネット上で「このドメインのIPアドレスを教えて！」と尋ねる仕組み、それが DNS（ドメインネームシステム） ですよね。これは、いわばインターネット上の「電話帳」や「郵便配達システム」のようなものです。
例えば、あなたが友達に手紙を送るときを想像してください。友達の家の正確な住所（IPアドレス、例えば 192.0.2.1 のような数字の羅列）が分からなければ、手紙は届きませんよね。でも、毎回「〇〇くんの家の住所を教えてください」と、全国の住民票を管理している本籍地（権威サーバー）までわざわざ問い合わせに行くのは、すごく時間がかかって非効率です。
そこで、普段私たちの近くにいる郵便局（ローカルのフルサービスリゾルバー、ISPのDNSサーバーなど）が、「一度調べた住所は、しばらくの間メモ帳（キャッシュ）に控えておこう！」 と賢くサボってくれます。これが DNSキャッシュ です。
キャッシュの功罪
- メリット: 毎回遠くまで聞きに行かなくて済むので、ウェブページの表示が爆速になる！
- デメリット: もし引っ越し（IPアドレスの変更）があった場合、メモ帳を書き換えるまでの間、古い住所に手紙を出し続けてしまう（これが「名前解決の不整合」の原因です）。
「あれ、新しいIPアドレスに切り替えたのに、手元で確認すると古いままなのはなぜ？」という疑問の答えは、大体この「ご近所の郵便局のメモ帳（キャッシュ）」が原因なんです。
—
2. ご近所の目を盗んで、直接本部に聞きに行く！ (+norecurse)
「ご近所の郵便局が持っているメモ帳のせいで、最新の正しい住所が見えない！」
そんなとき、私たちはどうすればいいでしょうか？
答えはシンプルです。「近所の郵便局を通さず、直接、その情報を一番よく知っている本家本元（権威DNSサーバー）に突撃して、最新の本当の住所を教えてもらう」のです。
ここで登場するのが、今回主役の dig コマンドのオプション、+norecurse（ノー・リカーシブ）です。
再帰問い合わせ（Recursion）ってなに？
通常、私たちがDNSに問い合わせるときは「再帰問い合わせ（Recursion）」というモードになっています。これは、
- 私：「〇〇の住所を教えて！」
- 郵便局：「任せて！私が代わりにいろんなところに聞いて、最終的な答えを持ってきてあげるから、そこで待っててね！」
という、至れり尽くせりの状態です。
しかし、+norecurse オプションをつけると、この手厚いサービスをあえて「お断り」します。
- 私：「〇〇の住所を教えて。ただし、他の場所に聞きに行かなくていいから、お前が今知っている答えだけをそのまま出して！（あるいは、知らないなら知らないって言って！）」
という、ちょっとツンデレな問い合わせ方に変わるのです。これが、再帰問い合わせフラグ（RDフラグ：Recursion Desired）をオフにする という動作になります。
—
3. 実践！ dig コマンドでキャッシュと権威サーバーを暴く
百聞は一見にしかず。実際に私たちの手元で、この挙動をコマンドを使って確認してみましょう！
（※お手元のターミナルを開いて、一緒に打ってみてくださいね。）
ステップ1：普通に問い合わせてみる（キャッシュの確認）
まずは、普段通りの方法で example.com のIPアドレスを引いてみます。
# 通常のdigコマンド（ご近所のDNSサーバーに聞きに行く）
dig example.comこのコマンドを実行すると、画面のどこかに flags: qr rd ra というような英字の羅列（フラグ情報）が出てきます。
ここで注目してほしいのが ra（Recursion Available：再帰問い合わせ可能）という文字です。これが表示されていれば、「あ、今回は近所の郵便局（フルサービスリゾルバー）が代わりに調べてくれたんだな」と分かります。
ステップ2：+norecurse を使って直接聞いてみる
次に、いよいよ本命のオプションを使ってみましょう。ここでは、インターネットの根幹を支えるルートサーバーの一つ（例として a.root-servers.net などの権威サーバー、または対象ドメインを直接管理しているサーバー）を指定して、直接問い合わせてみます。
# キャッシュをバイパスし、再帰問い合わせをせずに直接権威サーバーへ突撃する
dig @a.root-servers.net example.com +norecurseこのコマンドを実行したときの画面をよく見てみてください。
先ほどあった ra フラグが消え、代わりに flags: qr のようになっているはずです。これは、「再帰（お使いサービス）は頼んでいないよ」という意思表示になります。
そして、運が良ければ（あるいは階層のトップであれば）、権威サーバーは次のような返事をくれます。
> 「おっと、私自身はその最終的な住所までは直接知らないなぁ。でも、このドメインの本当の担当者（権威DNSサーバー）の住所なら知ってるから、そっちに直接行ってごらんよ（AUTHORITY SECTION）」
これが、パケットが世界中のDNSサーバーを駆け巡るリアルな挙動の瞬間です！
—
4. 現場のシニアエンジニアが教える！ トラブルシューティングの極意
実際のデータセンターの運用現場や、新しいシステムのリリース直後には、この仕組みがめちゃくちゃ役に立ちます。
例えば、お客様から「新しいサーバーに切り替えたのに、一部のユーザーから『繋がらない』って連絡が来るんだよ！」と泣きつかれたとします。そんなときの私たちの定番の動きはこうです。
1. まずは手元の dig で現状把握：
dig +noall +answer yourdomain.com などのコマンドで、今自分のパソコンがどのIPを見ているか確認する。
2. キャッシュの生存期間（TTL）を確認：
応答結果の中にある数字（例：3600 など）を見て、「あと1時間は古いキャッシュが残り続けるな」と予測を立てる。
3. 権威サーバーに直接突撃して真実を確認：
dig @[そのドメインの本当のネームサーバー] yourdomain.com +norecurse を実行し、「そもそも源流のサーバー側では、新しいIPに正しく書き換わっているか？」 をダイレクトに確認する。
もし源流のサーバー（権威サーバー）ですでに新しいIPになっているのに、一般ユーザーに届かないのであれば、それは「世界中のご近所郵便局のメモ帳（キャッシュ）の有効期限が切れるのを待つしかない」と判断できます。逆に、源流ですら間違っていれば、今すぐDNSレコードの設定ミスを直さなければなりません。
このように、「ご近所伝いの情報（キャッシュ）」 と 「本家本元の情報（権威サーバー）」 を切り分けて考えることができるようになると、ネットワークのトラブルシューティング能力は劇的に跳ね上がります！
—
5. おわりに
いかがでしたでしょうか？
今回は、ちょっと難しそうに見える dig コマンドの +norecurse オプションとDNSキャッシュの仕組みを、郵便配達の例えを交えてお話ししました。
- DNSキャッシュ: ご近所さんが持ってくれている便利なメモ帳。でも古い情報に注意！
+norecurse: ご近所さんの手助けを断り、本家本元に直接真実を問いに行くための強力なオプション。
インフラの世界は、一見すると複雑な黒魔術のようですが、一つひとつの機能を「現実世界の身近な仕組み」に置き換えて考えてあげると、すごくシンプルでロジカルなパズルだということが分かってきます。
みなさんも、ネットワークの向こう側でパケットがどう旅をしているのか想像しながら、ぜひ手元の端末で dig を叩いて遊んでみてくださいね。それでは、また次回のNOCテックブログでお会いしましょう！
コメント