Re: [squid-users] Unneeded DNS lookups for cache_peer selection

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 30 Jan 2014 09:51:45 +1300

On 2014-01-30 03:48, Amon Ott wrote:
> Hello everyone!
>
> We have a setup with a single parent proxy that shall be used for all
> requests. "never_direct allow all" ensures that the parent is not to be
> bypassed. Still, every request leads to an extra unnecessary (and
> failing) DNS lookup. We enjoyed several complaints because of unwanted
> DNS traffic inside a firewalled area. As all results are negative, even
> the DNS caching does not really help.
>
> I have traced the problem into peerSelectDnsPaths() in
> src/peer_select.cc. It seems that despite the clear fact that only one
> cache_peer can ever be selected (and has to be selected), the code
> still
> makes a DNS request for the hostname in the requested URL to find the
> best proxy. It would be greatly appreciated if we could suppress these
> lookups without loosing DNS access for parent proxy lookup by DNS name.
> The lookup does not make any sense to me even with multiple parents, if
> the parent selection is never based on the request target host.
>
> The only workaround we have found so far is to specify the parent proxy
> by IP address and tell Squid with "dns_nameservers localhost" to use a
> not existing DNS server. However, this way we loose the DNS based load
> balancing at the parent proxy, which we cannot influence ourselves.
>
> This looks like a similar problem to the one discussed in
> http://www.squid-cache.org/mail-archive/squid-users/201309/0364.html

It does indeed sound like a similar problem. The issue is likely the
same, "bad" configuration requiring DNS lookups to happen.
There are two solutions indicated in my response to that referenced
post:
  1) fixing the ACL tests and config options requiring DNS
  2) using /etc/hosts (or a localhost DNS resolver)

If you are willing to post your config file (without any # comment
lines) I am happy to check it like I did that earlier one.

Amos
Received on Wed Jan 29 2014 - 20:51:54 MST

This archive was generated by hypermail 2.2.0 : Thu Jan 30 2014 - 12:00:07 MST