再帰問い合わせとは、「最終的な答えまで調べてから返してほしい」とリゾルバー（キャッシュDNSサーバー）に依頼する問い合わせのことです。パソコンや WordPress のサーバーは、名前解決のたびにこの依頼を出し、リゾルバーが代わりに各地の権威DNSを回って答えを集めます。この記事では、再帰問い合わせを引き受ける側の仕組みを中心に、dig の出力にある rd ra aa フラグの読み方、自分のサーバーがどのリゾルバーを使っているかの確認方法、リゾルバーを運用するときの注意点を説明します。
再帰問い合わせを出す側と引き受ける側
名前解決には、立場の違う3者が登場します。
- スタブリゾルバー: パソコンやサーバーの OS に組み込まれた、問い合わせを出すだけの部品です。自分では調べ回らず、「最後まで調べて答えだけ返して」とリゾルバーに再帰問い合わせを送ります。
- フルサービスリゾルバー: 再帰問い合わせを引き受け、ルートサーバー、
.comなどのTLDサーバー、ドメインの権威DNSへと順に問い合わせて答えを組み立てます。プロバイダーのDNS、8.8.8.8や1.1.1.1のような公開DNS、社内のキャッシュDNSがこの役です。 - 権威DNS: 自分が管理するゾーンの情報だけを答えるサーバーです。知らない名前について、ほかへ調べに行くことはしません。
リゾルバーが各サーバーを順に回るときの問い合わせは「反復問い合わせ」と呼ばれます。つまり、利用者からリゾルバーへの依頼が再帰、リゾルバーから各権威DNSへの問い合わせが反復、という分担です。
リゾルバーが答えを返すまで
www.example.com を初めて引く場合、リゾルバーの中では次のことが起きています。
- スタブリゾルバーから再帰問い合わせを受け取る。
- キャッシュに答えがあれば、そのまま返す（ここで終わることが大半です）。
- キャッシュになければ、ルートサーバーに聞き、
.comの担当を教わる。 .comのサーバーに聞き、example.comの権威DNSを教わる。- 権威DNSに聞いて答えを得て、TTL の間キャッシュしてから利用者に返す。
DNSSEC の検証を有効にしているリゾルバーは、この過程で署名も検証し、検証に失敗すると答えの代わりに SERVFAIL を返します。「存在しない」という答え（NXDOMAIN）もキャッシュされます。新しく作ったサブドメインがしばらく引けないのは、作る前に一度引いた「存在しない」がキャッシュに残っていることが原因の場合があります。
digのフラグで再帰を読み取る
dig の出力の flags: 行を見ると、問い合わせが再帰として扱われたかどうかが分かります。
dig www.example.com A @8.8.8.8;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1rd（Recursion Desired）: 問い合わせた側が「再帰してほしい」と依頼した印です。digは標準でこのフラグを立てます。ra（Recursion Available）: 答えた側が「再帰を引き受けられる」と返した印です。リゾルバーなら付きます。aa（Authoritative Answer）: 答えたサーバーがそのゾーンの権威DNSであることを示します。リゾルバーのキャッシュから返った答えには付きません。
権威DNSに直接問い合わせると、aa が付き、ra が付かないのが普通です。このとき dig は「recursion requested but not available」という警告を表示しますが、権威DNSが再帰を引き受けない設定になっているだけなので、異常ではありません。
再帰なしで聞いてみる
+norecurse を付けると rd を立てずに問い合わせます。リゾルバーに対して使うと、キャッシュに持っている答えだけが返るので、そのリゾルバーがすでに覚えているかどうかを確かめられます。
# 再帰を依頼せず、キャッシュにあるかだけを見る
dig www.example.com A @192.0.2.53 +norecurse
# 比較: 権威DNSに直接聞く
dig www.example.com A @ns1.example-dns.net権威DNSの答えとリゾルバーの答えが違う場合、リゾルバーには変更前の値がキャッシュされていると判断できます。待つべき時間の目安は、リゾルバーの答えに表示される残りの TTL です。
自分のサーバーはどのリゾルバーを使っているか
WordPress から外部 API に接続できない、プラグインの更新確認が遅いといった症状の調査では、サーバー自身がどのリゾルバーに再帰問い合わせを送っているかを最初に確認します。
# 設定されているリゾルバー
cat /etc/resolv.conf
# systemd-resolved を使っている場合（Ubuntu など）
resolvectl status/etc/resolv.conf に nameserver 127.0.0.53 とだけある場合は、systemd-resolved が手元で中継しており、実際の問い合わせ先は resolvectl status で表示されます。レンタルサーバーやクラウドでは、事業者が用意したリゾルバーが設定されていることが一般的です。リゾルバーを変更する前に、事業者が変更を想定しているかをドキュメントで確認してください。
リゾルバーを自分で運用するときの注意
社内向けにキャッシュDNSを立てる場合、再帰問い合わせを誰から受け付けるかを制限することが重要です。インターネット上の誰からでも再帰を受け付けるサーバー（オープンリゾルバー）は、送信元を偽装した大量の問い合わせに使われ、第三者を狙った DDoS 攻撃（DNS アンプ攻撃）の踏み台になります。
BIND では、再帰を許可する相手を allow-recursion で絞ります。
options {
recursion yes;
allow-recursion { 127.0.0.1; 192.0.2.0/24; };
};Unbound では access-control で同じことを行います。
server:
access-control: 127.0.0.0/8 allow
access-control: 192.0.2.0/24 allow権威DNSとして公開するサーバーでは、再帰を無効にして役割を分けるのが基本です。1台で権威とキャッシュを兼ねると、設定の誤りがそのまま外部に影響します。設定変更は検証環境で試し、変更前に設定ファイルを控えておいてください。
トラブル調査での使いどころ
再帰問い合わせの仕組みが分かると、「人によってサイトが見えたり見えなかったりする」原因を順に切り分けられます。
- 権威DNSに直接聞き、登録内容が正しいかを確かめる（
aa付きの答え）。 - 利用者が使うリゾルバー（プロバイダーや公開DNS）に聞き、古い答えが残っていないか確かめる。
- 残っていれば TTL が切れるのを待つ。リゾルバーごとにキャッシュの持ち方は違うため、すべての利用者で同時に変わるわけではありません。
公開DNSの中には、キャッシュの削除を依頼できるページを用意しているところもあります。提供の有無や手順は変わることがあるので、各サービスの案内を確認してください（2026年10月現在）。
まとめ
- 再帰問い合わせは、利用者側が「最後まで調べて」とリゾルバーに依頼する問い合わせです。
- リゾルバーはキャッシュになければ、ルート、TLD、権威DNSへ反復問い合わせをして答えを集めます。
digのrdは依頼、raは引き受け可能、aaは権威DNSの答えを示します。- サーバーの名前解決の問題は、
/etc/resolv.confやresolvectl statusで問い合わせ先を確認するところから始めます。 - 自分でリゾルバーを運用するなら、再帰を許可する範囲を絞り、オープンリゾルバーにしないことが重要です。