svn commit: r1071026 - /trafficserver/site/branches/ats-cms/content/docs/trunk/admin/configuration-files/files.en.mdtext

[am...@apache.org]

Author: amc
Date: Tue Feb 15 19:38:37 2011
New Revision: 1071026

URL: http://svn.apache.org/viewvc?rev=1071026&view=rev
Log:
TS-492 documentation

Modified:
    trafficserver/site/branches/ats-cms/content/docs/trunk/admin/configuration-files/files.en.mdtext

Modified: trafficserver/site/branches/ats-cms/content/docs/trunk/admin/configuration-files/files.en.mdtext
URL: http://svn.apache.org/viewvc/trafficserver/site/branches/ats-cms/content/docs/trunk/admin/configuration-files/files.en.mdtext?rev=1071026&r1=1071025&r2=1071026&view=diff
==============================================================================
--- trafficserver/site/branches/ats-cms/content/docs/trunk/admin/configuration-files/files.en.mdtext (original)
+++ trafficserver/site/branches/ats-cms/content/docs/trunk/admin/configuration-files/files.en.mdtext Tue Feb 15 19:38:37 2011
@@ -1600,6 +1600,33 @@ the `records.config` file.
 :  `0`
 :  Enables (`1`) or disables (`0`) `traffic_cop` heartbeat logging.
 
+*`proxy.config.http.use_client_target_addr `*
+: `INT`
+: `0`
+: Avoid DNS lookup for forward transparent requests:
+
+   `0` Never.  
+   `1` Avoid DNS lookup if possible.  
+
+   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 -
+
+   * Traffic Server is in forward proxy mode.
+   * Traffic Server is using client side transparency.
+   * The target URL has not been modified by either remapping or a plugin.
+
+   If any of these conditions are not true, then normal DNS processing is done for the connection.
+
+   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.
+
+   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:
+
+   1. 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.
+
+   2. 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.
+
+   Additional Notes:
+
+   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.
 
 **Parent Proxy Configuration**