反復問い合わせ（iterative query、非再帰問い合わせとも呼ばれます）は、キャッシュ DNS サーバーがルートサーバー、TLD サーバー、権威 DNS サーバーへと順に「次はどこに聞けばよいか」を教えてもらいながら答えにたどり着く問い合わせ方です。一方、パソコンがキャッシュ DNS に「最後まで調べて答えだけちょうだい」と頼むのが再帰問い合わせです。この記事では、2つの問い合わせの違いを図の代わりに具体的な流れで説明し、dig を使って反復問い合わせの各段階を自分の目で確かめる方法、名前解決のトラブル調査にどう役立つかを解説します。
名前解決に登場する4つの役
反復問い合わせを理解するには、まず登場人物を押さえておくと楽です。
- スタブリゾルバー：パソコンやサーバーの OS に組み込まれた、問い合わせを投げるだけの小さな仕組み
- キャッシュDNSサーバー（フルリゾルバー）：プロバイダの DNS、社内 DNS、Google Public DNS（8.8.8.8）や Cloudflare の 1.1.1.1 など。実際に答えを調べて回る役
- ルートサーバーとTLDサーバー：DNS の階層の上位にあり、「その名前を知っているのは誰か」を教える役
- 権威DNSサーバー：各ドメインのレコードを実際に持っている役
再帰問い合わせと反復問い合わせの違い
再帰問い合わせ：答えだけを求める
スタブリゾルバーからキャッシュ DNS への問い合わせは、再帰問い合わせです。DNS のメッセージには RD（Recursion Desired）というフラグがあり、これを立てて「最終的な答えまで調べてほしい」と依頼します。キャッシュ DNS は、答えか「その名前は存在しない」というエラーのどちらかを返します。途中経過は返しません。
反復問い合わせ：「次の相手」を教えてもらう
キャッシュ DNS からルートサーバーなどへの問い合わせは、反復問い合わせです。ルートサーバーは www.example.com の IP アドレスを知りませんが、「com のことなら、これらのサーバーに聞いてください」と、次の問い合わせ先の一覧を返します。これを「委任の応答」や「リファーラル」と呼びます。キャッシュ DNS はその一覧の中から相手を選んで次の問い合わせを送り、答えにたどり着くまでこれを繰り返します。
たとえるなら、再帰問い合わせは「窓口に用件を伝えて結果を待つ」こと、反復問い合わせは「窓口から窓口へ、案内を受けながら自分で回る」ことです。回って歩くのはキャッシュ DNS で、利用者のパソコンは待っているだけです。
www.example.comを調べる流れ
キャッシュ DNS に何もキャッシュが無い状態で www.example.com の A レコードを調べる場合、流れは次のようになります。
- パソコンのスタブリゾルバーが、キャッシュ DNS に再帰問い合わせを送る
- キャッシュ DNS が、ルートサーバーに反復問い合わせを送る。ルートサーバーは
comの TLD サーバーの一覧を返す - キャッシュ DNS が
comの TLD サーバーに問い合わせる。TLD サーバーはexample.comの権威 DNS サーバーの一覧（NS レコード）を返す - キャッシュ DNS が
example.comの権威 DNS サーバーに問い合わせる。権威 DNS は A レコードの答えを返す - キャッシュ DNS が答えを TTL の間保存し、パソコンに返す
実際には、キャッシュ DNS は com の TLD サーバーの一覧などを長い時間キャッシュしているため、毎回ルートサーバーから聞き直すわけではありません。多くの問い合わせは、途中の段階から始まるか、キャッシュだけで答えが返ります。
委任の応答に含まれるもの
ルートや TLD のサーバーが返す委任の応答では、ANSWER セクションは空で、AUTHORITY セクションに次の問い合わせ先の NS レコードが入ります。さらに、そのサーバーの IP アドレスが ADDITIONAL セクションに添えられることがあります。これを「グルーレコード」と呼びます。ns1.example.com のように、委任先のサーバー名がそのドメイン自身の中にある場合、グルーが無いと「example.com を調べるために ns1.example.com を調べる必要がある」という堂々巡りになるためです。
digで反復問い合わせを体験する
dig +traceで全体を見る
dig +trace を使うと、dig 自身がキャッシュ DNS の役になり、ルートから順に反復問い合わせを行って、各段階の応答を表示します。
dig +trace www.example.com A出力は、おおむね次の段階に分かれて表示されます（ドメインによって行数や内容は変わります）。
. NS a.root-servers.net. ← ルートサーバーの一覧
...
com. NS a.gtld-servers.net. ← ルートが教えた com の TLD サーバー
...
example.com. NS (example.com の権威DNS) ← TLD が教えた権威DNS
...
www.example.com. A (IPアドレス) ← 権威DNSからの最終的な答え各段階の最後に Received 1170 bytes from 198.41.0.4#53(a.root-servers.net) in 20 ms のような行があり、どのサーバーから応答を受け取ったかが分かります。最初の段階（ルートサーバーの一覧）だけは、パソコンに設定されたキャッシュ DNS から取得しています。バイト数や応答時間は環境によって変わります。
1段階ずつ手で問い合わせる
各段階を自分で確かめたい場合は、+norecurse を付けて RD フラグを外し、相手を指定して問い合わせます。
# ルートサーバーに聞く（委任の応答が返る）
dig +norecurse @a.root-servers.net www.example.com A
# 返ってきた com のTLDサーバーに聞く
dig +norecurse @a.gtld-servers.net www.example.com A応答のヘッダーを見ると、ANSWER が 0 件で AUTHORITY に NS レコードが並び、flags に aa（権威ある応答）が付いていないことが分かります。最後に権威 DNS へ聞いたときにだけ、ANSWER に答えが入り、aa が付きます。この違いが、委任の応答と最終的な答えの見分け方です。
トラブル調査での使いどころ
反復問い合わせの流れを知っていると、「どの段階で止まっているか」を調べられます。
- ネームサーバーを変更したのに反映されない：
dig +traceで TLD が返す NS が新しい値になっているかを見ます。古い値のままなら、レジストラでの変更が TLD に届いていないか、反映待ちです。 - 一部の環境でだけ名前解決に失敗する：TLD が返す NS の中に、応答しないサーバーや、そのドメインのことを知らないサーバー（「レイムデリゲーション」と呼ばれる状態）が混ざっていると、運悪くそのサーバーを選んだときだけ失敗します。NS の一覧にあるサーバーすべてに
dig +norecurse @サーバー名で問い合わせ、同じ答えが返るか確認します。 - 権威DNSでは正しいのに、キャッシュDNSが古い答えを返す：反復問い合わせの結果がキャッシュに残っている状態です。TTL が切れるまで待つか、キャッシュ DNS を自分で管理しているならキャッシュを消去します。
なお、最近のキャッシュ DNS ソフトウェアの多くは「QNAME minimisation」という仕組みで、ルートサーバーには com の部分だけ、TLD には example.com の部分だけを聞くようになっています。必要以上の情報を上位のサーバーに渡さないための工夫で、dig +trace の表示とは問い合わせる名前が異なる場合があります（2026年10月現在）。
まとめ
- 再帰問い合わせは「答えだけをください」という依頼で、パソコンからキャッシュ DNS へ送られる
- 反復問い合わせは「次はどこに聞けばよいか」を教えてもらいながら進む方式で、キャッシュ DNS がルート・TLD・権威 DNS へ送る
- 委任の応答は ANSWER が空で AUTHORITY に NS が入り、最終的な答えには
aaフラグが付く dig +traceで全体の流れを、dig +norecurse @サーバーで各段階を確かめられる- ネームサーバーの変更や一部だけの名前解決失敗は、どの段階で止まっているかを反復問い合わせの流れに沿って調べる