DNSプロキシとは、端末やアプリケーションから送られるDNS問い合わせをいったん受け取り、必要に応じて別のDNSサーバーへ転送したり、キャッシュから応答したり、フィルタリングやログ取得などの制御を行ったりする仕組みです。
簡単に言うと、DNSプロキシは「DNS問い合わせの代理人」です。
通常、PCやスマートフォンがWebサイトにアクセスするとき、まず「このドメイン名に対応するIPアドレスは何か」をDNSに問い合わせます。
DNSプロキシがある環境では、端末は外部のDNSサーバーへ直接問い合わせるのではなく、まずDNSプロキシに問い合わせます。
その後、DNSプロキシが上流のDNSサーバーへ問い合わせたり、すでに持っている情報から応答したりします。
つまりDNSプロキシは、端末とDNSサーバーの間に入って、名前解決を中継・管理・制御する役割を持っています。
DNSは、ドメイン名をIPアドレスに変換する仕組みです。
人間にとっては、Webサイトを「example.com」のようなドメイン名で覚えるほうが簡単です。
しかし、インターネット上の通信では、実際にはIPアドレスを使って相手のサーバーに接続します。
この「人間が読みやすいドメイン名」と「コンピュータが通信に使うIPアドレス」を対応させる仕組みがDNSです。
よく「DNSはインターネットの電話帳」と表現されます。
ドメイン名という名前をもとに、接続先のIPアドレスを調べる役割を持っているからです。
Webサイトへアクセスするとき、ブラウザはいきなり目的のサーバーに接続するわけではありません。
まず、アクセスしたいドメイン名のIPアドレスを調べます。
その後、得られたIPアドレスに対してHTTPSなどで通信します。
つまり、Webアクセスの流れを大きく分けると、まずDNSによる名前解決があり、その後に実際のWeb通信が行われます。
DNSプロキシは、この最初の「名前解決」の部分に関わる仕組みです。
DNSプロキシは、端末と外部DNSサーバーの間に入ります。
端末から見ると、DNSプロキシはDNSサーバーのように見えます。
たとえば家庭用ルーターがDNSプロキシとして動作している場合、PCやスマートフォンのDNSサーバーにはルーターのIPアドレスが設定されていることがあります。
この場合、端末はルーターにDNS問い合わせを送ります。
ルーターはその問い合わせを受け取り、必要に応じてプロバイダのDNSサーバーやGoogle Public DNS、Cloudflare DNSなどの上流DNSサーバーへ問い合わせます。
上流DNSサーバーから返ってきた答えを、DNSプロキシが端末へ返します。
DNSプロキシは「プロキシ」という名前が付いていますが、端末から見るとDNSサーバーとして動作します。
そのため、厳密には「DNSプロキシはDNSサーバーではない」とは言い切れません。
むしろ、端末からのDNS問い合わせを受け付けるという意味では、DNSサーバーとして振る舞っています。
ただし、権威DNSサーバーのように特定ドメインの正式なゾーン情報を管理しているわけではないことが多く、主な役割は上流DNSへの転送、キャッシュ、制御、フィルタリングなどです。
この点が、一般的な「DNSサーバー」という言葉と少し混同されやすい部分です。
DNSプロキシのもっとも基本的な役割は、端末から受け取ったDNS問い合わせを別のDNSサーバーへ転送することです。
たとえば、家庭内のPCがWebサイトにアクセスしようとしたとします。
PCはまず家庭用ルーターにDNS問い合わせを送ります。ルーターはその問い合わせを、プロバイダや指定された外部DNSサーバーに転送します。
このように、DNS問い合わせを別のDNSサーバーへ橋渡しする機能は、DNSフォワーダーやDNSリレーと呼ばれることもあります。
実務上は、DNSプロキシ、DNSフォワーダー、DNSリレーという言葉がかなり近い意味で使われることがあります。
DNSプロキシは、DNS問い合わせの結果を一時的に保存することがあります。これをDNSキャッシュと呼びます。
同じネットワーク内の複数の端末が同じドメインにアクセスする場合、毎回外部DNSサーバーへ問い合わせるのは効率的ではありません。
DNSプロキシが過去の問い合わせ結果を覚えていれば、同じ問い合わせに対してすぐに応答できます。
これにより、名前解決が速くなり、外部DNSサーバーへの問い合わせ回数も減ります。
ただし、DNSの情報には有効期限があります。
この有効期限をTTLと呼びます。
DNSプロキシは通常、このTTLに従ってキャッシュを保持します。
TTLが切れた情報は再度問い合わせが必要になります。
DNSプロキシは、特定のドメインへのアクセスを制限する目的でも使われます。
たとえば、マルウェア配布サイト、フィッシングサイト、広告配信ドメイン、トラッキングドメイン、業務上不要なサイトなどをDNS段階でブロックできます。
端末が危険なドメインを問い合わせたとき、DNSプロキシが正しいIPアドレスを返さなければ、その先の通信を成立させにくくできます。
この仕組みは、企業のセキュリティ対策、学校や家庭のペアレンタルコントロール、広告ブロック、DNSセキュリティサービスなどで使われます。
DNSプロキシは、どの端末がどのドメインを問い合わせたかを記録できます。
このログは、セキュリティ調査やネットワーク管理で役立ちます。
たとえば、ある端末が不審なドメインを頻繁に問い合わせている場合、マルウェア感染や不正通信の兆候として確認できます。
企業ネットワークでは、DNSログをもとにインシデント調査を行うことがあります。
どの端末がいつ、どのドメインにアクセスしようとしたかを追跡できるためです。
一方で、DNSログはプライバシーにも関わります。
DNS問い合わせを見ると、ユーザーがどのサービスやサイトにアクセスしようとしたかがある程度わかるため、ログの扱いには注意が必要です。
DNSプロキシは、DNS問い合わせに対して本来とは異なる応答を返すこともあります。
たとえば、危険なドメインに対して無効なIPアドレスを返したり、ブロックページのIPアドレスを返したりすることがあります。
また、社内ネットワークでは、社内専用のドメインを内部サーバーのIPアドレスに向けるために使われることもあります。
外部のDNSサーバーでは解決できない社内システムの名前を、社内のDNSプロキシやDNSサーバーが解決する形です。
このような制御により、利用者は複雑なIPアドレスを覚えなくても、社内ポータルや開発環境へドメイン名でアクセスできます。
DNSフォワーダーとは、DNS問い合わせを別のDNSサーバーへ転送する機能を指すことが多い言葉です。
端末から問い合わせを受け取り、それを上流DNSサーバーへ送るという点では、DNSプロキシと非常に近い役割を持っています。
そのため、実務ではDNSプロキシとDNSフォワーダーがほぼ同じ意味で使われることもあります。
DNSプロキシという言葉は、単なる転送だけでなく、キャッシュ、フィルタリング、ログ取得、応答の書き換え、暗号化DNSへの変換などを含む広い意味で使われることがあります。
つまり、DNSフォワーダーは「転送」に注目した言葉であり、DNSプロキシは「代理処理」や「制御」まで含めて説明されることが多い言葉です。
ただし、この区別は厳密に統一されているわけではありません。
製品やOS、ルーターの管理画面によって、DNS Proxy、DNS Relay、DNS Forwarder、DNS Cache、Local DNS Serverなど、さまざまな名称が使われます。
スタブリゾルバは、PCやスマートフォンなどの端末側にあるDNS問い合わせ機能です。
アプリケーションやブラウザがドメイン名の解決を必要としたとき、端末内のスタブリゾルバがDNS問い合わせを行います。
スタブリゾルバは通常、自分でDNSの階層をたどって答えを探すわけではありません。
設定されたDNSサーバーに問い合わせを送り、その応答を受け取ります。
再帰リゾルバは、クライアントの代わりにDNS階層をたどって答えを探すDNSサーバーです。
たとえば、Google Public DNSやCloudflare DNS、プロバイダのDNSサーバーなどは、再帰リゾルバとして動作します。
再帰リゾルバは、必要に応じてルートDNSサーバー、TLD DNSサーバー、権威DNSサーバーへ問い合わせを行い、最終的な答えを取得します。
DNSプロキシは、スタブリゾルバと再帰リゾルバの間に入ることが多い存在です。
端末からの問い合わせを受け取り、上流の再帰リゾルバへ転送します。
場合によっては、キャッシュから応答したり、特定ドメインの問い合わせを別のDNSサーバーに振り分けたりします。
ただし、実装によってはDNSプロキシ、ローカルリゾルバ、DNSフォワーダー、キャッシュDNSの機能が重なることがあります。
そのため、これらの用語は完全に分離して考えるよりも、「どの機能を持っているか」で理解するほうが実務的です。
権威DNSサーバーは、特定のドメインについて正式なDNS情報を持つサーバーです。
たとえば、自社ドメインのAレコード、CNAMEレコード、MXレコード、TXTレコードなどを管理しているDNSサーバーは、そのドメインに対する権威DNSサーバーです。
権威DNSサーバーは、対象ドメインについて「正式な答え」を返す立場にあります。
DNSプロキシは、多くの場合、特定ドメインの正式なゾーン情報を管理しているわけではありません。
主な役割は、端末からの問い合わせを受け取り、上流のDNSサーバーへ転送することです。
ただし、DNSプロキシがまったく情報を持たないわけではありません。
キャッシュ済みの情報、社内向けの固定レコード、ブロック対象ドメインのルール、ローカル端末名などを持つ場合があります。
そのため、正確には「DNSプロキシは権威DNSサーバーのような正式なゾーン管理を主目的としないが、ローカルな応答情報やキャッシュを持つことはある」と考えるとよいです。
家庭用ルーターは、DNSプロキシとして動作する代表的な例です。
家庭内のPCやスマートフォンには、DHCPによってルーターのIPアドレスがDNSサーバーとして配布されることがあります。
この場合、端末はルーターにDNS問い合わせを送り、ルーターが上流DNSサーバーへ問い合わせます。
ユーザーから見ると特に意識することは少ないですが、家庭内ネットワークでは非常によくある構成です。
企業ネットワークでは、DNSプロキシがセキュリティや管理のために使われます。
たとえば、業務に不要なサイトのブロック、危険ドメインの遮断、社内システムの名前解決、DNSログの収集、部署ごとのDNSポリシー適用などが行われます。
DNSは多くの通信の前段階で発生するため、DNSを制御することでネットワーク全体のセキュリティを強化できます。
VPN環境でも、DNSプロキシやDNS制御は重要です。
企業VPNに接続すると、社内ドメインを解決するために、DNS問い合わせを会社側のDNSサーバーへ送る必要がある場合があります。
また、VPN利用中にDNS問い合わせだけが通常回線側へ流れてしまうと、DNSリークと呼ばれる状態になります。
DNSリークが起きると、通信本体はVPNを通っていても、どのドメインにアクセスしようとしたかが通常回線側のDNSサーバーに見えてしまう可能性があります。
このような問題を防ぐために、VPNクライアントやVPNルーターがDNSの向き先を制御することがあります。
DNSプロキシは、広告ブロックやトラッキング対策にも使われます。
広告配信ドメインやトラッキングドメインへのDNS問い合わせに対して、無効な応答を返したり、名前解決できないようにしたりすることで、広告や計測用通信を抑制します。
この方式はブラウザ拡張とは異なり、ネットワーク全体に適用できることがあります。
家庭内の全端末や社内ネットワーク全体に対して、同じDNSフィルタリングを適用できる点が特徴です。
DNSプロキシは、コンテナ環境やクラウド環境でも使われます。
たとえば、Kubernetesなどの環境では、サービス名を使ってコンテナ同士が通信するためにDNSが重要な役割を持ちます。
内部サービス名を解決したり、特定の名前解決をクラスタ内部で処理したりするために、DNS中継やDNSキャッシュの仕組みが使われます。
クラウド環境でも、内部ドメイン、プライベートDNS、VPC内の名前解決などで、DNSプロキシ的な仕組みが関わることがあります。
DNSプロキシを使うと、ネットワーク内のDNS問い合わせを一元管理しやすくなります。
端末ごとにDNS設定を細かく変更するのではなく、DNSプロキシ側で上流DNSサーバーやフィルタリングルールを管理できます。
特に企業や学校など、多数の端末を管理する環境では大きなメリットがあります。
DNSプロキシは、危険なドメインへのアクセスをDNS段階で止めるために使えます。
マルウェアやフィッシングサイトは、特定のドメイン名を使って通信することがあります。
DNSプロキシでそのドメインへの名前解決をブロックできれば、通信が成立する前に被害を抑えられる可能性があります。
もちろん、DNSフィルタリングだけですべての脅威を防げるわけではありません。
しかし、ネットワーク防御の一部としては有効です。
DNSプロキシがキャッシュを持っている場合、よく使われるドメインの名前解決を速くできます。
特に、複数の端末が同じネットワークを利用している場合、同じドメインへの問い合わせが何度も発生します。
DNSプロキシがその結果を覚えていれば、外部DNSサーバーへ毎回問い合わせる必要がなくなります。
これにより、名前解決の応答時間を短縮できる場合があります。
DNS問い合わせのログは、セキュリティ調査に役立ちます。
たとえば、ある端末が不審なドメインを問い合わせている、短時間に大量のDNS問い合わせを行っている、通常業務では使わない外部サービスへアクセスしようとしている、といった状況を把握できます。
DNSログは、マルウェア感染、情報漏えい、不正アクセス、フィッシング被害の調査で重要な手がかりになることがあります。
DNSプロキシを使うことで、社内専用のドメインや内部サービス名を扱いやすくなります。
外部からは解決できない社内システムの名前を、社内ネットワーク内では正しく解決できるようにする構成です。
これにより、利用者はIPアドレスを直接入力する必要がなくなり、わかりやすい名前で社内システムにアクセスできます。
端末がDNSプロキシだけをDNSサーバーとして使っている場合、そのDNSプロキシに障害が起きると名前解決ができなくなります。
名前解決ができないと、多くのWebサイトやクラウドサービスにアクセスできなくなります。
実際にはIPアドレスで直接通信できる場合もありますが、通常の利用ではドメイン名を使うため、ユーザーからは「インターネットが使えない」と見えることがあります。
そのため、企業ネットワークではDNSプロキシやDNSサーバーを冗長化することが重要です。
DNSプロキシが古いキャッシュを保持していると、ドメインの向き先を変更した後も古いIPアドレスへアクセスしてしまうことがあります。
たとえば、Webサイトのサーバー移転、CDN切り替え、メールサーバー変更などを行った後に、一部の環境だけ古いサーバーを見てしまうケースがあります。
ただし、この原因はDNSプロキシだけとは限りません。
OS、ブラウザ、ルーター、プロバイダDNS、パブリックDNS、CDNなど、さまざまな場所にキャッシュが存在します。
DNS変更後のトラブルでは、どの段階のキャッシュが影響しているかを切り分ける必要があります。
DNSプロキシを運用している側は、DNS問い合わせのログを確認できる場合があります。
DNS問い合わせには、通常、URLのパスやページの中身までは含まれません。
しかし、どのドメインにアクセスしようとしたかはわかります。
たとえば、具体的な記事URLやログイン情報までは見えなくても、どのサービスやサイトを利用しようとしたかは推測できる場合があります。
そのため、DNSログの保存期間、閲覧権限、利用目的などは慎重に管理する必要があります。
DNSプロキシによるフィルタリングは有効ですが、万能ではありません。
たとえば、ユーザーが別のDNSサーバーを直接使ったり、DoHを使ってDNS問い合わせを暗号化したりすると、ネットワーク側のDNSプロキシを回避できる場合があります。
また、IPアドレスへ直接接続する通信や、許可済みドメインを悪用する通信など、DNSフィルタリングだけでは検知しにくいケースもあります。
そのため、DNSプロキシは単独の対策ではなく、ファイアウォール、プロキシ、EDR、メールセキュリティ、Webフィルタリングなどと組み合わせて使うのが一般的です。
DNSプロキシは、ドメイン名をIPアドレスに変換する段階に関わります。
Webサイトへアクセスする前に、「このドメイン名はどのIPアドレスか」を調べる部分を中継・制御します。
そのため、DNSプロキシが扱うのは主にDNS問い合わせです。
HTTPプロキシは、Webアクセスそのものを中継します。
ブラウザからのHTTPやHTTPS通信を受け取り、代わりにWebサーバーへアクセスしたり、アクセス制御や認証、ログ取得、キャッシュなどを行ったりします。
DNSプロキシが「接続先を調べる段階」に関わるのに対し、HTTPプロキシは「実際にWebへアクセスする段階」に関わります。
DNSプロキシもHTTPプロキシも、どちらも中継役です。
しかし、扱う通信が違います。
DNSプロキシはDNS問い合わせを扱い、HTTPプロキシはWeb通信を扱います。
そのため、DNSプロキシだけではHTTPSのページ本文やフォーム入力内容を見ることはできません。
一方で、HTTPプロキシやTLSインスペクションを行う環境では、より詳細なWeb通信の制御が行われる場合があります。
従来型のDNSは、主にUDPまたはTCPの53番ポートを使います。
この方式は一般的に暗号化されていないため、ネットワーク上でDNS問い合わせの内容を観測できる場合があります。
つまり、どのドメインを問い合わせたかが、ネットワーク管理者や通信経路上の機器に見える可能性があります。
DoHはDNS over HTTPS、DoTはDNS over TLSの略です。
どちらもDNS問い合わせを暗号化するための仕組みです。
DoHはHTTPS通信の中でDNS問い合わせを行います。
DoTはTLSで暗号化された専用の通信としてDNS問い合わせを行います。
これにより、従来型DNSよりもDNS問い合わせの盗聴や改ざんを防ぎやすくなります。
DNSプロキシの中には、端末からは通常のDNS問い合わせを受け取り、上流DNSサーバーへはDoHやDoTで問い合わせるものがあります。
この場合、端末側は従来型DNSのままでも、DNSプロキシから先の通信は暗号化されます。
家庭用ルーター、セキュリティ製品、ローカルDNSツールなどで、このような構成が使われることがあります。
DNSプロキシに障害があると、Webサイトが開けなくなることがあります。
この場合、通信回線そのものが切れているのではなく、ドメイン名からIPアドレスを調べる名前解決に失敗している可能性があります。
ブラウザでは、名前解決に失敗したことを示すエラーが表示されることがあります。
一部のサイトだけ開けない場合、DNSプロキシのフィルタリングやキャッシュが影響している可能性があります。
たとえば、特定のドメインがセキュリティポリシーによってブロックされている場合、そのサイトだけアクセスできなくなります。
また、古いDNSキャッシュが残っている場合、新しいサーバーではなく古いサーバーへ接続しようとして失敗することもあります。
社内ネットワークでは開けるのに、社外では開けないサイトやシステムがある場合、社内DNSが関係していることがあります。
社内専用ドメインは、外部のDNSサーバーでは解決できない場合があります。
社内DNSプロキシや社内DNSサーバーが、その名前を内部IPアドレスに解決しているためです。
このような場合、社外からアクセスするにはVPN接続が必要になることがあります。
VPN接続時だけ特定のサイトが開けない、社内システムに接続できない、または通常とは異なるIPに解決される場合、VPNによるDNS設定の変更が影響している可能性があります。
VPN接続時には、DNS問い合わせの送信先が会社側のDNSに切り替わることがあります。
また、特定ドメインだけ社内DNSへ問い合わせるスプリットDNS構成が使われる場合もあります。
DNSトラブルがVPN接続時だけ起きる場合は、VPNのDNS設定、スプリットDNS、DNSリーク対策、ローカルDNSキャッシュなどを確認する必要があります。
Webサイトのサーバー移転、CDN導入、ドメイン設定変更などを行うと、DNS変更の反映タイミングに差が出ることがあります。
これは、DNSプロキシや再帰DNSサーバー、OS、ブラウザなどがDNSキャッシュを持っているためです。
あるユーザーには新しいサイトが見えているのに、別のユーザーには古いサイトが見えているという状況は、DNSキャッシュが原因で起こることがあります。
そのため、Webサイト移転やDNS変更を行う前には、TTLを短めに調整しておくなどの準備が重要です。
広告ブロック系のDNSプロキシやセキュリティDNSを使っている環境では、広告配信ドメインや計測用ドメインが名前解決の段階でブロックされることがあります。
この場合、ブラウザ拡張を使っていなくても、広告タグ、アクセス解析タグ、ヒートマップツール、MAツール、A/Bテストツールなどが正しく動作しないことがあります。
Webマーケティングやサイト改善の現場では、「タグを設置したのに一部環境で計測されない」という問題の背景に、DNSレベルのブロックがある場合もあります。
企業や学校のネットワークでは、DNSプロキシによって特定カテゴリのドメインがブロックされていることがあります。
SNS、動画、広告、トラッキング、ギャンブル、アダルト、マルウェア関連などのカテゴリが制限されるケースがあります。
そのため、自社サイトやランディングページが特定のネットワークだけで開けない場合、サーバー側の問題だけでなく、DNSフィルタリングやWebフィルタリングも疑う必要があります。
WebサイトがCDN、画像配信サービス、タグマネージャー、外部フォーム、チャットツール、決済サービスなどに依存している場合、それらの外部ドメインがDNSフィルタリングの対象になると、ページの一部機能が動かなくなることがあります。
たとえば、ページ本体は表示されるが、画像が出ない、フォームが送信できない、チャットウィジェットが表示されない、広告計測が発火しないといった症状です。
このような場合、問題の原因がWebサーバーではなく、外部ドメインの名前解決やDNSフィルタリングにあることもあります。
DNSプロキシという言葉は、厳密な標準用語というより、実務上の機能名として使われることが多い言葉です。
同じような機能が、別の製品ではDNSフォワーダー、DNSリレー、DNSキャッシュ、ローカルDNS、DNSスタブ、DNSリゾルバなどと呼ばれることがあります。
そのため、名称だけで判断するのではなく、実際に何をしているのかを見ることが重要です。
見るべきポイントは、問い合わせを転送しているのか、キャッシュしているのか、フィルタリングしているのか、ログを取っているのか、応答を書き換えているのか、暗号化DNSに変換しているのか、といった機能面です。
DNSプロキシは、端末から見るとDNSサーバーとして動作します。
ただし、権威DNSサーバーのように正式なゾーン情報を管理しているとは限りません。
この点を理解しておくと、「DNSプロキシとDNSサーバーは何が違うのか」という混乱を避けやすくなります。
正確には、DNSプロキシはDNSサーバーとして問い合わせを受け付けつつ、主な役割として中継、キャッシュ、制御、フィルタリングなどを行う仕組みだと考えるとよいです。
DNSトラブルが起きたときは、DNSプロキシだけを疑うのではなく、名前解決の経路全体を見る必要があります。
端末のDNS設定、OSのDNSキャッシュ、ブラウザのキャッシュ、家庭用ルーター、社内DNS、VPN、プロバイダDNS、パブリックDNS、権威DNS、CDNなど、複数の要素が関係します。
特にDNS変更後の反映遅延や、一部環境だけアクセスできない問題では、どこに古い情報が残っているのかを切り分けることが重要です。
DNSプロキシとは、端末やアプリケーションからのDNS問い合わせを受け取り、上流DNSサーバーへ転送したり、キャッシュから応答したり、フィルタリングやログ取得、応答の書き換えなどを行ったりする仕組みです。
単なる中継役として使われることもありますが、実際にはセキュリティ、管理、パフォーマンス改善、社内システムの名前解決、広告ブロック、VPNのDNS制御など、さまざまな用途で使われます。
重要なのは、DNSプロキシという言葉がやや広い意味を持つことです。
DNSフォワーダー、DNSリレー、キャッシュDNS、ローカルリゾルバなどと機能が重なる場合があり、製品によって呼び方も異なります。
正確に理解するなら、DNSプロキシは「DNS問い合わせを代理で受け取り、転送・キャッシュ・制御を行う仕組み」と考えるのがよいです。
Web運用やマーケティングの現場でも、DNSプロキシは無関係ではありません。
DNS変更の反映差、広告タグや計測タグのブロック、一部ネットワークだけでの表示不具合などに関わることがあります。
そのため、DNSプロキシを理解しておくと、ネットワーク管理だけでなく、Webサイト運用、広告計測、セキュリティ対策、トラブルシューティングにも役立ちます。
以上、DNSプロキシとはなんなのかについてでした。
最後までお読みいただき、ありがとうございました。