[jira] Issue Comment Edited: (TS-492) Allow use of client supplied IP address for origin server.

["Alan M. Carroll (JIRA)" <ji...@apache.org>]

    [ 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