trafficserver-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r785461 - /websites/staging/trafficserver/trunk/content/docs/trunk/admin/configuration-files/files.en.html
Date Tue, 15 Feb 2011 19:38:43 GMT
Author: buildbot
Date: Tue Feb 15 19:38:43 2011
New Revision: 785461

Staging update by buildbot


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
+++ 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>Enables (<code>1</code>) or disables (<code>0</code>) <code>traffic_cop</code>
heartbeat logging.</dd>
+<dd>Avoid DNS lookup for forward transparent requests:</dd>
+<p><code>0</code> Never.<br />
+<code>1</code> Avoid DNS lookup if possible.<br />
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>

View raw message