[
https://issues.apache.org/jira/browse/TS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994157#comment-12994157
]
Alan M. Carroll edited comment on TS-492 at 2/13/11 9:51 PM:
-------------------------------------------------------------
Proposed documentation:
proxy.config.http.use_client_target_addr
Default: false.
This option causes Traffic Server to avoid where possible doing DNS lookups in
forward transparent proxy mode. It has no effect if any of the following
conditions are not met:
* Traffic Server is in forward proxy mode.
* Traffic Server is using client side transparency.
* The target URL has not been modified by remapping or a plugin.
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, the 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 maintain internal 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.
was (Author: amc):
Proposed documentation:
proxy.config.http.use_client_target_addr
Default: false.
This option causes Traffic Server to avoid where possible doing DNS lookups in
forward transparent proxy mode. It has no effect if any of the following
conditions are not met:
* Traffic Server is in forward proxy mode.
* Traffic Server is using client side transparency.
* The target URL has not been modified by remapping or a plugin.
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, the 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 maintain internal 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 consider 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.
> Allow use of client supplied IP address for origin server.
> ----------------------------------------------------------
>
> Key: TS-492
> URL: https://issues.apache.org/jira/browse/TS-492
> Project: Traffic Server
> Issue Type: New Feature
> Components: DNS
> Reporter: Alan M. Carroll
> Assignee: Alan M. Carroll
> Priority: Minor
> Fix For: 2.1.6
>
>
> When operating in transparent mode, the IP address of the origin server is
> available from the client socket connection. This enhancement would add a
> switch (default to false) that would use that IP address rather than doing a
> host DB or DNS lookup *if* the URL had not been modified. If the URL is
> modified (remapped) then the lookup would proceed, ignoring this
> configuration flag.
> This not only enhances performance but also is required for certain websites
> that embed the IP address of the origin server in the exchange and use DNS
> switching for performance. In that case ATS can connect to a different origin
> server than the client intended, leading to a protocol failure. One prominent
> example is Microsoft Windows update.
> For now, this switch can be turned on globally and disabled locally by
> creating identity mappings for the exceptions. It may be desirable at some
> point to be able to specifically disable it rather then depend on the
> serendipitous effects of remapping.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
