Author: buildbot
Date: Tue Feb 15 19:38:43 2011
New Revision: 785461
Log:
Staging update by buildbot
Modified:
websites/staging/trafficserver/trunk/content/docs/trunk/admin/configuration-files/files.en.html
Modified:
websites/staging/trafficserver/trunk/content/docs/trunk/admin/configuration-files/files.en.html
==============================================================================
---
websites/staging/trafficserver/trunk/content/docs/trunk/admin/configuration-files/files.en.html
(original)
+++
websites/staging/trafficserver/trunk/content/docs/trunk/admin/configuration-files/files.en.html
Tue Feb 15 19:38:43 2011
@@ -1656,7 +1656,33 @@ T=SERVER_PORT_BLIND_TUNNEL</p>
<dd><code>INT</code></dd>
<dd><code>0</code></dd>
<dd>Enables (<code>1</code>) or disables (<code>0</code>)
<code>traffic_cop</code> heartbeat logging.</dd>
+<dt><em><code>proxy.config.http.use_client_target_addr</code></em></dt>
+<dd><code>INT</code></dd>
+<dd><code>0</code></dd>
+<dd>Avoid DNS lookup for forward transparent requests:</dd>
</dl>
+<p><code>0</code> Never.<br />
+<code>1</code> Avoid DNS lookup if possible.<br />
+</p>
+<p>This option causes Traffic Server to avoid where possible doing DNS lookups
in forward transparent proxy mode. The option is only effective if the
following three conditions are true -</p>
+<ul>
+<li>Traffic Server is in forward proxy mode.</li>
+<li>Traffic Server is using client side transparency.</li>
+<li>The target URL has not been modified by either remapping or a plugin.</li>
+</ul>
+<p>If any of these conditions are not true, then normal DNS processing is done
for the connection.</p>
+<p>If all of these conditions are met, then the origin server IP address is
retrieved from the original client connection, rather than through HostDB or
DNS lookup. In effect, client DNS resolution is used instead of Traffic Server
DNS.</p>
+<p>This can be used to be a little more efficient (looking up the target once
by the client rather than by both the client and Traffic Server) but the
primary use is when client DNS resolution can differ from that of Traffic
Server. Two known uses cases are:</p>
+<ol>
+<li>
+<p>Embedded IP addresses in a protocol with DNS load sharing. In this case,
even though Traffic Server and the client both make the same request to the
same DNS resolver chain, they may get different origin server addresses. If the
address is embedded in the protocol then the overall exchange will fail. One
current example is Microsoft Windows update, which presumably embeds the
address as a security measure.</p>
+</li>
+<li>
+<p>The client has access to local DNS zone information which is not available
to Traffic Server. There are corporate nets with local DNS information for
internal servers which, by design, is not propagated outside the core corporate
network. Depending a network topology it can be the case that Traffic Server
can access the servers by IP address but cannot resolve such addresses by name.
In such as case the client supplied target address must be used.</p>
+</li>
+</ol>
+<p>Additional Notes:</p>
+<p>This solution must be considered interim. In the longer term, it should be
possible to arrange for much finer grained control of DNS lookup so that
wildcard domain can be set to use Traffic Server or client resolution. In both
known use cases, marking specific domains as client determined (rather than a
single global switch) would suffice. It is possible to do this crudely with
this flag by enabling it and then use identity URL mappings to re-disable it
for specific domains.</p>
<p><strong>Parent Proxy Configuration</strong></p>
<dl>
<dt><em><code>proxy.config.http.parent_proxy_routing_enable</code></em></dt>
