再帰的DNSクエリとは何ですか？

再帰的なDNSクエリとは、ネームサーバーに対して、リファラルではなく最終的な回答またはエラーを返すよう指示するリクエストのことです。サーバーは、名前を解決するために必要に応じて他のサーバーに問い合わせを行います。クライアントは、RDフラグを設定することでこれを通知します。

再帰的DNSクエリと反復的DNSクエリの違いは何ですか？

再帰クエリではサーバーが完全な解決処理を行うのに対し、反復クエリではサーバーは既知の情報（多くの場合、リファラル）を返す。スタブリゾルバーは通常、再帰クエリを送信し、再帰リゾルバーは権威サーバーに対して反復クエリを送信する。

どのDNSサーバーが再帰クエリを受け付けるか？

再帰型リゾルバーはこれらを受け付けますが、通常は内部クライアントまたはカスタムクライアントのみに限定して設定されています。権威サーバーのみのサーバーは、一般的に再帰機能を提供しません。

DNSクエリにおけるRDフラグの役割とは？

「再帰希望（RD）」フラグは、サーバーに対し、クライアントに代わって名前を完全に解決するよう要求するものです。サーバーは、応答内で「再帰利用可能」フラグを設定することで、再帰のサポートを示します。

なぜDNSサーバーで再帰を制限すべきなのでしょうか？

無制限の再帰は、攻撃者がリフレクション攻撃や増幅攻撃に悪用できるオープンリゾルバを生み出します。再帰を信頼できるクライアントに限定することで、リゾルバの処理能力やキャッシュも保護されます。

用語集
再帰クエリとは何ですか？

DNS用語集

再帰クエリとは何ですか？

再帰クエリとは、ネームサーバーに対して、リファラルではなく完全な応答またはエラーを返すよう要求するDNSリクエストのことです。サーバーは、RFC 1034に記述されているように、必要に応じて他の権威サーバーにクエリを送信し、クライアントに代わって名前を解決します。

DDIをシンプルにしましょう

Abstract isometric UI showing network ranges, usage bars, region names (EMEA/APAC), and a purple "Deploy" button

主なポイント

再帰クエリとは、問い合わせを受けたネームサーバーがクライアントに代わって完全な名前解決を行い、リファラルではなく、最終的な回答またはエラーを返すDNSリクエストのことです。クライアントは、DNSメッセージヘッダーに再帰希望（RD）フラグを設定することでこの意図を通知し、リゾルバーは必要に応じて他の権威サーバーに問い合わせ、結果をキャッシュして最終的な結果のみを返します。再帰的リゾルバは、アプリケーションのパフォーマンスと可用性にとって極めて重要ですが、サービス拒否攻撃におけるオープンリゾルバとしての悪用を防止し、キャッシュポイズニングから保護するために、アクセス制御リスト（ACL）による慎重なセキュリティ強化が必要です。

再帰型リゾルバーは、アクセス制御リスト（ACL）を使用して再帰を既知の内部クライアント範囲に制限し、リフレクション攻撃や増幅攻撃に対するオープンリゾルバーとしての悪用を防ぐ必要があります。
エンドデバイスからのほぼすべてのDNSルックアップは、リゾルバーを経由する再帰クエリとして開始されるため、リゾルバーのキャッシュヒット率と可用性は、アプリケーションのパフォーマンスとユーザー体験を直接左右します。
よくある設定ミスには、リゾルバーの容量不足、フォワーダーへの到達不能、古くなった条件付き転送ルール、クエリログの欠落などがあり、これらはキャッシュのフラッシュ後にルックアップが遅くなったり、権威サーバーの委任が破綻した際にSERVFAILエラーが発生したりする原因となります。

再帰クエリの概要

Attribute	Value
Full name	Recursive query
Category	DNS query type
Defined in	RFC 1034 and RFC 1035, with resolver behavior updated in later RFCs
Protocol and port	DNS over UDP and TCP, port 53
OSI layer	Layer 7 (application)
Primary use	Letting stub resolvers get a final answer from a recursive resolver without following referrals themselves
Related terms	Iterative query, Recursive resolver, Stub resolver, Authoritative name server, DNS caching

再帰クエリの仕組み

再帰クエリでは、クライアントはDNSメッセージヘッダーに再帰希望（RD）フラグを設定します。受信サーバーは、再帰機能を提供している場合、名前の解決作業を引き受け、最終結果のみを返します。

クライアントがクエリを送信：クライアント上のスタブリゾルバは、RDフラグが設定されたクエリを、設定された再帰リゾルバに送信します。
リゾルバはキャッシュを確認します：再帰型リゾルバは、有効なキャッシュされた応答を探します。それが見つかった場合は、直ちにそれを返します。
リゾルバによる他のサーバーへのクエリ：キャッシュミスが発生すると、リゾルバは通常、ルートサーバーから開始して反復的なクエリを送信します。その後、トップレベルドメインサーバーへのリファラルに従い、最終的にそのゾーンの権威サーバーへとたどっていきます。
リゾルバーは結果をキャッシュします：リゾルバーは、レコードの有効期間（TTL）で指定された時間、その回答を保存します。
リゾルバはクライアントに応答します。リゾルバは、再帰利用可能（RA）フラグをセットした状態で、最終的な回答、またはNXDOMAINや SERVFAIL などのエラーを返します。

リゾルバーがいくつのサーバーに問い合わせを行っても、クライアントには1つのリクエストと1つのレスポンスしか表示されません。サーバーは再帰を拒否する場合があり、その場合は自身のデータからのみ応答するか、リファラルまたは拒否を返します。権威サーバーのみは、通常、再帰を提供しません。

エンタープライズネットワークにおいて再帰クエリが重要な理由

エンドデバイスが行うDNSルックアップのほぼすべては再帰クエリとして開始されるため、再帰リゾルバーはほぼすべてのアプリケーショントラフィックの経路上に位置しています。そのパフォーマンス、キャッシュヒット率、可用性は、ユーザーがサービスにどれほど迅速かつ確実にアクセスできるかに直接影響します。リゾルバーの動作が遅かったりダウンしていたりすると、ネットワークやサーバーが正常であっても、アプリケーションが失敗しているように見えてしまいます。

再帰にはセキュリティ上の影響もあります。インターネット上のあらゆる送信元からの再帰クエリを受け入れるリゾルバーは「オープンリゾルバー」と呼ばれ、攻撃者がリフレクション型や増幅型のサービス拒否（DoS）攻撃に悪用する可能性があります。再帰クエリを既知のクライアントネットワークに限定することは、標準的なセキュリティ強化策である。また、リゾルバーはキャッシュポイズニングの標的にもなり得るが、DNSSEC検証、送信元ポートのランダム化、およびクエリIDのランダム化によってそのリスクを軽減できる。

管理上の不備は、さまざまな形で現れます。例えば、容量が不足しているリゾルバー、到達不可能なサーバーを指すフォワーダー、古くなったり一貫性を欠いたりした条件付き転送ルール、クライアントが何を検索したかの記録が残らないクエリログの欠如などです。一般的な慣行であるように、再帰型リゾルバーと権威サーバーを分離することで、それぞれの役割のセキュリティ確保、スケーリング、監視がより簡単になります。

再帰クエリと関連用語との比較

再帰クエリと反復クエリ

再帰クエリでは、サーバーにすべての処理を行わせ、最終的な回答またはエラーを返すよう要求しますが、反復クエリでは、サーバーが別のネームサーバーへの参照など、最善の部分的な回答を返すことができます。反復（または非再帰）クエリとは何ですか？

Attribute	Recursive query	Iterative query
Who does the resolution work	The queried server	The querying client or resolver
Typical response	Final answer or error	Answer or referral to a closer name server
RD flag in query	Set	Normally not set
Typical sender	Stub resolver to recursive resolver	Recursive resolver to authoritative servers
Server must support recursion	Yes	No

再帰クエリに関する一般的な問題

任意の送信元アドレスからの再帰クエリに応答するリゾルバーは、リフレクション攻撃や増幅攻撃に悪用される可能性があります。アクセス制御リスト（ACL）を使用して再帰を内部クライアントの範囲に制限し、インターネットからアクセスできないことを確認してください。

クライアントのサブネットがリゾルバーの許可リストに含まれていない場合、クライアントは「REFUSED」応答を受け取ります。これは、新しいサブネットが展開された後、アクセスリストが更新されていない場合に頻繁に発生します。

再起動やキャッシュのフラッシュ後、すべてのクエリはキャッシュミスとなり、ルートからの完全な探索がトリガーされます。キャッシュが再び温まるまで、ユーザーはページの読み込みが遅くなるのを経験することになります。

ゾーンの権威サーバーに到達できない場合や、不十分な委任情報が返された場合、リゾルバーは解決を完了できず、SERVFAILを返します。クライアント側では単に失敗として認識されるため、リゾルバーでの反復クエリを追跡することで、この不具合を特定することができます。

リゾルバーはTTLが切れるまで応答を保持するため、レコードが変更されても一部のクライアントにはその変更が反映されない場合があります。エンジニアは、変更後、キャッシュの有効期限が切れるか、キャッシュがクリアされるまで、リゾルバー間で結果に不整合が生じているのを確認します。

統合型DDIがネットワーク運用をいかに簡素化するかをぜひご覧ください

自動化、可視性、制御機能が組み込まれた単一のプラットフォームから、DNS、DHCP、IPアドレスを管理できます。

お問い合わせ

インテリジェント・ネットワーク

再帰クエリとは何ですか？

DDIの簡素化を始めませんか？

再帰クエリの概要

再帰クエリの仕組み

エンタープライズネットワークにおいて再帰クエリが重要な理由

再帰クエリと関連用語との比較

再帰クエリと反復クエリ

再帰クエリに関する一般的な問題

統合型DDIがネットワーク運用をいかに簡素化するかをぜひご覧ください

再帰クエリに関するよくある質問

関連用語

組織のネットワーク向けに、ガバナンスが確立され、監査対応可能なIPAMワークフローおよび承認モデルを構築する

OSIモデルの理解：7層構造におけるDNSとIPアドレスの位置づけ

IPv6 およびデュアルスタック企業ネットワーク向けの DNS および IPAM のスケーリング

Embedding DNS, DHCP, and IPAM into Ansible and Git-based infrastructure-as-code pipelines

ポッドキャスト：AIがエンタープライズソフトウェア開発をどう変えているか

ポッドキャスト：ネットワーク運用においてオープンプラットフォームが重要な理由

LiveAssistを活用して、すでに保有しているLiveNXのデータから答えを引き出しましょう

LiveWire GEN3 デバイス製品ラインナップ

関連記事