On 10/5/22 07:48, Ralf Hildebrandt wrote:
Using squid-6.0.0-20220905-r9358e99f9: ====================================== On sunday, one of our DNS server froze and was not answering any queries. Shit happens, that's why we have another DNS server. Our Squid config says: dns_nameservers 141.42.5.157 141.42.5.156 So, 141.42.5.157 was not answering any queries, and 141.42.5.156 took over. But... monitoring reported dns_query_time rose to about 8000ms, meaning all http requests took ages, since (I guess) the first dns server was queried, and (after 8s?) the second server was used. But according to the docs, "dns_timeout" defaults to 30s.
Disclaimer: My response below is based on quick code analysis without any tests. It ignores many complications, including two DNS query types for each name (A and AAAA) and chasing dns_defnames after NXDOMAIN.
Squid dns_timeout does not control when Squid sends a query to the second DNS nameserver. It controls when Squid completely gives up on trying to resolve a name. Such resolution failures often lead to transaction forwarding errors.
The time[out] gap between two repeated DNS queries within one resolution attempt is controlled by dns_retransmit_interval (including its exponential back-off algorithm). See below for more details.
Is there any way of making squid mark the first server as "dead" (for e.g. 5 minutes) and use the next server instead?
Not yet AFAICT: Today, Squid starts with the first nameserver and uses the second nameserver only when the first query fails (including dns_retransmit_interval timeouts). If there is enough time (see dns_timeout) and there are only two DNS nameservers configured, then Squid will use the first nameserver again (for the same resolution attempt) if the second query/nameserver fails, and so on (i.e. a round robin scan across all configured nameservers that always starts with the first nameserver).
Thus, if I am reading the code correctly, an unresponsive first nameserver will cripple your Squid even if the second nameserver is perfectly healthy :-(.
HTH, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
