On 25/10/2013 2:44 a.m., Plamen wrote:
Amos Jeffries-2 wrote
On 24/10/2013 6:44 a.m., Plamen wrote:
Yes,
this is one of the problems I'm also experiencing,
the customer is using different DNS than the Squid, and he complains
because
he says - without your SQUID I can open xxxx web page, but with your
SQUID
it's not opening.
Ah. So the real problem is "Why is it not opening for Squid?"
The current releases of Squid *do* use the client provided destination
IP. The DNS resolution is only to determine whether the response is
cacheable and if alternative IPs may be tried as backup _if_ the client
given one is unable to connect by Squid.
Hi Amos,
thanks for the valuable feedback.
Do I need to do something specific to get this behavior of Squid where it
uses the dst provided IP, like some directive in config has to be enabled or
it is default behavior?
This is default behaviour for squid-3.2 and later.
In this scenario, what happens if the DNS servers configured in SQUID stop
responding for some reason for some period of time (or they become
unreachable), will the traffic continue to pass normally or the users will
start getting errors and they will not be able to browse anymore?
Traffic will pass to the client dst IP. There may be some small lag on
the first request after DNS went out while Squid waits for the DNS
response. But some delays are only to be expected when things on the
network break.
I will give you real life example that I'm trying to resolve.
The ISP is having 2 Upstream providers.
The SQUID is running in TPROXY mode, and the squidbox has an IP address from
Upstream 1 and respectively uses this IP to contact DNS servers.
When both upstream providers are working - everything is smooth in terms of
HTTP traffic.
When Upstream 1 goes down for some reason, for a period of time, the
customers which are provisioned with IPs belonging to UPSTREAM 2 also get
affected because the SQUID cannot do DNS lookups anymore.
I'm trying to resolve this kind of issues.
This kind of issue is best fixed via other means.
For example; I use IPv6 private allocation fc00::/16 IP addressing for
all my network internal traffic including the links between Squid and
its DNS server. No matter which upstream is active (even with none)
these connections and lookups will continue working so long as my own
network remains stable.
Another way is to configure an explicit address in udp_outgoing_address
for Squid to use as its src IP on UDP packets (and thus DNS packets).
This does the same thing for Squid->DNS traffic, but does not protect
other internal-only traffic so I dont favour it as much as the IPv6 method.
Amos
