[squid-users] Squid not failing over to secondary DNS host

[Amos Jeffries]

On 12/10/17 18:44, Geoffrey wrote:
> Thanks for your reply Amos.
> 
> I just realised I left out some info in the original email that was
> pertinent. :)
> 
> 
>> How are you determining that exactly?
>> squid logs? DNS logs? firewall counters? packet traces?
> 
> Quite simply by trial and error and monitoring the results of taking
> the 2 DNS/DCs offline/online, and using the cachemgr report.
> 
> EG. here is the report after I loaded one page and then took the
> primary DNS offline, then continued to browse to two more pages. The
> latter two pages did not load and the cachemgr report seems to verify
> that squid is not using the secondary dns server at all (primary dns
> server having 27 queries to 9 replies and the secondary getting none).
> 
> 
> root at websafetyv51:~# squidclient mgr:idns
> Date: Thu, 12 Oct 2017 05:30:12 GMT
 > Via: 1.1 websafetyv51.localdom.local (squid/3.5.23)
...
> 
> Internal DNS Statistics:
> 
> The Queue:
>                         DELAY SINCE
>    ID   SIZE SENDS FIRST SEND LAST SEND M FQDN
> ------ ---- ----- ---------- --------- - ----
> 
> DNS jumbo-grams: not working
> 
> Nameservers:
> IP ADDRESS                                     # QUERIES # REPLIES Type
> ---------------------------------------------- --------- --------- --------
> 192.168.100.249                                      27         9 recurse
> 192.168.100.248                                       0         0 recurse
> 
> Rcode Matrix:
> RCODE ATTEMPT1 ATTEMPT2 ATTEMPT3 PROBLEM
>      0     1550        0        0 : Success
...

That is a bit odd. Also the fact that ~1550 queries are not showing up 
in the nameserver counters.

Do you have ICMP and ICMPv6 working in your network? If not that is 
probably part of the issue.

Are you using DROP rules or policies in your firewalls? that can also 
lead to missing packets like this.

Are you able to perform some more careful tests?
  * restart Squid with both resolvers active and take snapshots of that 
report periodically across the test. It will need sufficient time after 
shutting down the first resolver for any packet or query TTLs to expire.


If you could also check whether either resolver is responding using 
alternative IP addresses it would help clarify what is going on.


Amos