[squid-users] dns failover failing with 3.4.7

[Amos Jeffries]

On 31/07/2015 3:48 a.m., Mike wrote:
> On 7/27/2015 17:25 PM, Amos Jeffries wrote:
>> On 28/07/2015 8:38 a.m., Mike wrote:
>>> Running into an issue, using the squid.conf entry
>>> dns_nameservers 72.x.x.x 72.x.y.y
>>>
>>> These are different servers (under our control) for the purpose of
>>> filtering than listed in resolv.conf (which are out of our control, used
>>> for server IP routing by upstream host).
>>>
>>> The problem we found like this weekend is if the primary listed dns
>>> server is unavailable, squid fails to use the secondary listed server.
>>> Instead it displays the "unable to connect" type messages with all
>>> websites.
>> Details please. How do you know the secondary is not even being tried?
>>
>> What is Squid getting back from the primary when its "down" ?
>>   or just dns_timeout being hit?
>>
>> Add this to squid.conf to get a cache.log trace of the DNS activity:
>>    debug_options 78,6
>>
> Amos,
> 
> If it was using the secondary server listed, connections to almost all
> websites would not be failing to load if primary was down. For the test
> we temporarily took the primary DNS server offline (per the example
> above 72.x.x.x), and no websites would load unless it was in the squid
> cache, but any elements that required additional data failed to load
> causing formatting issues with the displayed website. If we swap the
> setting to the "secondary" with the first IP (per the example above) as
> dns_nameservers 72.x.y.y 72.x.x.x
> and it works the same way, take the ".y.y" down and it refuses to use
> the secondary listed IP ".x.x" for DNS, instead displays the website
> could not be displayed error in the browsers. We even tried another test
> (per the example above) dns_nameservers 72.x.x.x 8.8.8.8 then let it run
> for an hour or so. Then we took down the primary which means it should
> use the secondary google IP of 8.8.8.8, but it doesn't, goes right back
> to the "website could not be displayed" error in the browsers.
> I was wonder if this might be a bug. This is happening on multiple
> servers, one has squid 3.4.7, another has 3.4.6 and problem occurs on both.
> 

Thank you exactly the kind of answer I was looking for question #1.
(Evidence that the problem is what you think it is before digging for a
cause).

Kind of answers Q2 a "nothing", implying that Q3 is "yes" dns_timeout is
happening.


 Is your dns_timeout (default 30 sec *total* DNS lookup timeout) larger
than your dns_retransmit_interval (default 5 sec per-query timeout) setting?


Amos