[squid-dev] Removing DNS lookups in intercept mode by using client dest IP address
John Dunne
imirish at alldunne.com
Fri May 22 09:28:29 UTC 2015
Hi, thanks indeed for your response.
> On 21 May 2015, at 14:35, Amos Jeffries <squid3 at treenet.co.nz> wrote:
>
> On 22/05/2015 12:00 a.m., johndunne wrote:
>> Hi,
>>
>> I'm running squid 3.5.4 on a network which caches http and https traffic via
>> a tproxy redirect on a linux box. The setup runs perfectly, except that a
>> slight lag is introduced owing to the squid service making DNS lookups for
>> many of the requests it receives via http and https.
>>
>> Now, I'm considering patching squid such that it auto adds the destination
>> IP address of the client connection to its own dns cache, for the hostname
>> that appears in the http header of that connection. I think this is safe
>> since the connection is redirected via tproxy i.e. I know that the client
>> machine got that IP address for the hostname in the HTTP/HTTPS request.
>
> No, no you dont. On the contrary we do know from testing the
> host_verify_strict feature that many, many clients lie.
>
> The amount of traffic where URL and Host header contained entirely
> different domain names (or even ports) was quite a surprise.
Wow, that's interesting! So it’s a very bad idea for me to have made that assumption. Thank goodness for smarter people!
>
>>
>> Assuming my logic here isn't flawed, does anyone know if this is sensible
>> and if any such work has already been done?
>>
>
> No, the DNS lookup being done is to protect against CVE-2009-0801.
>
> That CVE is about a client browser running a malicious script provided
> by a web server somewhere, which makes HTTP requests but lies when
> sending the Host: header. This is trivial for an attacker to do and if
> trusted would result in cache corruption affecting all clients on the
> network.
>
> Essentially if the Host header value does not match the URL or resolve
> to the IP being contacted then it can't be trusted for use as a cache
> key that other clients might fetch.
>
> You could get around the DNS lookup if you really have to by patching
> Squid to always mark the hostVerify as done with a failed result. But
> none of the traffic would then be able to cache, so its not a very
> useful thing to do.
>
>
> You can probably better reduce latency by ensuring that the clients and
> Squid are using the same DNS resolvers. And that they those resolvers
> respond fast. That will allow Squid to verify success more often than
> not and caching will raise the HIT ratio on intercepted traffic.
>
Good tips. I’ll focus on improving cache performance via DNS caching.
> Amos
>
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
More information about the squid-dev
mailing list