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@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users