IEでHTTPプロキシを使用する（または使用しない）場合のDNSルックアップの動作方法

私は最近、クライアントがプロキシサーバーからページを要求したときに何が起こるかに関する議論に参加しました。この一連のイベントについての私の理解が一般的な場合に正しいことを確認したかっただけです。

1. ユーザーリクエストサイト
2. DNS要求は、宛先IPアドレスを解決するために、構成されたDNSサーバーにクライアントによって送信されます（これは、プロキシをバイパスするように構成されたHTTP要求に対応するために最初に行われます）
3. 宛先IPがDNSから受信され、HTTPリクエストが送信される直前に、リクエストは例外リストと照合されます
4. 宛先サーバーが例外リストにない場合、要求はプロキシサーバーに転送されます。
5. 宛先サーバーが例外リストにある場合、要求はクライアントマシンのルーティングテーブルに従って転送されます。

どんなフィードバックでも大歓迎です。

正確ではありません：クライアントの構成方法によって異なります。IEを基本的な例として使用しましょう。

IEを明示的なプロキシで構成する場合：たとえば、他のオプションにチェックマークを付けない場合、プロキシは何かに設定：8080

1. ユーザーが住所を入力します

2. IEは、IEプロキシ例外リスト（つまり、「これらのアドレスのプロキシをバイパスする」）に対して文字列の一致を確認します。

   a。バイパスリストのエントリと一致する場合、クライアントは独自のDNSを使用して名前を解決し、クライアントはポート80（想定）でターゲットIPアドレスに直接接続し、次のような要求を送信します。

   GET /something.htm HTTP/1.1
Host: fulldomainame.example.com

   b。一致するバイパスリストエントリがない場合は、続行します。

3. IEは設定されたプロキシに接続し、次の形式のリクエストを送信します。

   GET http://fulldomainname.example.com/something.htm HTTP/1.1

   ボーナスファクトイド：URLでのFQDNのこの使用は、クライアントが実際のWebサーバーではなくプロキシと通信していると考えることができる1つの方法です

4. プロキシは、独自の DNS を使用してそのホスト名を解決し、ターゲットサイト（上記の手順2のクライアントのように動作する）などに接続します。

WPAD / PACを使用する場合：

自動構成が有効になっているときにISA / TMGが提供するような、Webプロキシ自動検出（WPAD）またはプロキシ自動構成（PACまたはAutoconfig）スクリプトを使用する場合、次の点が異なります。

1. ユーザーが住所を入力します

2. クライアントは、現在のwpad.dat / autoproxy.js / .pacファイルを構成済みの場所からダウンロードします

3. クライアントは、jsファイルで関数「FindProxyForUrl」を探して実行します

4. Autoproxyスクリプトは、ホスト名とURLを処理します。これは機能が制限されたjavascriptファイルですが、まだ多くのことが可能です。

   a。これには名前解決（IsInNet、DnsResolve）が含まれる場合があります

   b。これには、文字列照合（ShExpMatch）が含まれる場合があります

   c。これには、100万個までのカウントが含まれる場合があります（i ++）

   d。これには、管理者が意地悪な場合に、気味の悪い警告ポップアップメッセージが含まれる場合があります

   • （または単に面白い）
   • （（またはデバッグ））

5. FindProxyForURL関数が戻った少なくとも1つの文字列：使用するのが最善のプロキシの順序付きリスト（セミコロン区切り）

   a。いずれかの「DIRECT」クライアントは、名前自体を解決し、上記バイパスケースごとに、直接接続する必要がある場合には、

   b。または「PROXY proxyname：8080」など。この場合、クライアントはそのプロキシのそのポートに接続し、完全なURLをGETするように指示し、プロキシは名前解決を実行します。

   • 例として、スクリプト関数が「PROXY yourProxy：8080; DIRECT」を返し、クライアントにTCPポート8080でyourproxyに接続してこのURLを要求するよう指示し、その接続を確立できない場合は、直接接続してみてください。 注これはそうではないユーザーのための快適なフェイルオーバ経験することが、何も勝るものはありませんので、TCPセッションのセットアップの失敗は、正確に、迅速でないこと。多分。

不具合、微妙さ、原因不明の動作が時折ありますが、ほとんどの場合、物事が奇妙で面白い方法で壊れていない場合、上記は長年にわたってどのように機能するかを見てきました。新しいブラウザは、動作を最適化し、内容を並列化し、常に面白いことを試みているため、特定のブラウザの最新のドキュメントをチェックして詳細を理解してください。

WinSock Proxy / ISA Firewall Client / TMG Client：

（TMG / ISA Serverの）Winsock Proxy Clientに興味があるなら、それは別の話であり、より柔軟性があり、可動部分があります。ここで説明するのは多すぎますが、その仕組みを説明したドキュメントがあります。つまり、Windowsソケットにプラグインし、TCP / UDPベースのトラフィックと名前解決要求の両方をアプリごとおよびユーザーごとにインターセプトできます。非常に強力ですが、現在は非推奨であり、数年後に更新されていません。

クライアントは本当にクリンジーになることができます：

一つの最後の注意：HTTPクライアントが特定のサイト/ URLのプロキシに話をすることを決定した後、プロキシはしないようにそれを伝えるためにのための方法はありません。

「私はそれを提供しないので、代わりに直接それに行く必要があります」ためのHTTPステータスコードまたはヘッダーはありません...

特定のURLがプロキシで提供されるとクライアントが判断すると、proxy-death-gripが実行されます。

これを回避する唯一の方法は、クライアントがPACまたはバイパスリストで接続する直前に選択ロジックを取得することです。

ゾーンとPACファイルに関する最後の注意

IEは、URLにドットが含まれている場合でも、直接接続されているサイトをローカルイントラネットゾーンの一部として扱い（デフォルトでは、ゾーンプロパティで設定可能）、それらのサイトへの統合Windows認証を許可します（つまり、 Kerberosおよび/またはNTLM認証、透過的に）。そのため、ローカルイントラネットゾーンに何かがあるかどうかを制御することで、自動認証の観点から信頼性を定義します。繰り返しますが、少なくともデフォルトでは。

DNSの部分が正しいかどうかはわかりません。有効なDNSサーバーのないマシンが、プロキシを使用してIEでページを正常にフェッチするのを見ました。

私はubuntu 10.04、ワイン、IE 6.0およびsquid 2.7で試します（システムには1つのDNSがあり、イカには他のDNSサーバーがあります）

1. ユーザーがプロキシにリクエストを送信
2. SquidはDNS要求をDNSサーバーに送信します
3. SquidはDNS応答を受信します。nxdomainまたはその他のエラーの場合、エラーページをIEに送信します。名前が解決したら、ページを取得してIEに渡します。

IE 6.0はDNS名を解決しません。

私はそれがそうではないと思います-あなたがIPを入力し、ドメインが例外リストに、またはドメイン、およびIPが例外リストにある場合、それはおそらくプロキシ経由で行くでしょう。

proxy.pac / wpad.datを使用すると、この動作から抜け出すことができます。