On 30/10/2015 5:44 p.m., Eliezer Croitoru wrote: > Hey, > > I was convinced that there was an option to disable the host forgery > test, which will make more sense if you will use bind and will intercept > all DNS traffic into it. There is host_verify_strict to set the checking to set it between super-strict paranoia (on), and allow the one client to be borked but protect others (off, which is the default). There is client_dst_passthru to use the client provided dst-IP as first preferred destination (on), or to do the same server selection as explicit-proxy traffic does regardless of where the client was trying to go (off). * Turning this off can be faster but break sites which make bad assumptions about end-to-end sessions or otherwise depend on IP-based security sessions, so the default is on. * It does not affect the host_verify_strict decision, only applies when the Host header is detected as okay. * It does nothing when a cache_peer is being relayed through as the only upstream option. > > About your idea for an upstream cache. > It's a pretty nice idea, I am pretty sure that the host forgery test can > be disabled in a case you are using an upstream cache_peer. Yes, traffic being received at an explicit-proxy syntax (eg. from an front-end proxy) does not have host verification applied unless you decide to set the super-paranoid mode to on. Host verification is only applied on the proxy doing NAT intercept or TPROXY. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
