On 2026-01-16 00:49, Amos Jeffries wrote:
On 16/01/2026 05:28, Alex Rousskov wrote:
On 2026-01-15 02:14, archer wrote:
# {cache_peer ... no_netdb_exchange } already set earlier
netdb_filename none
pinger_enable off
Icp_port0 #seems to be default value
And this issue persists. It seems that NO squid.conf could help with
the DNS leak issue.
Yes, your statement matches what I have stated in my previous
response: AFAICT, there is no squid.conf option that would disable
those DNS lookups in Squids built with `--enable-icmp` (which is also
the default).
Q1: So, does Squid netdb work on the IP level?
Squid NetDB feature has several parts/algorithms/statistics that use
various protocols. In this particular case, Squid prepares to "ping"
(via ICMP) the site targeted by the CONNECT request. Since ICMP needs
an IP address, Squid performs a DNS lookup first.
Since NetDB is a database indexed by CIDR, Squid needs to know the IP of
the origin server in order to lookup the details, even when going
through a peer.
The buggy code path in question does not really "lookup the details". It
does not need them. Instead, when successful, the lookup
populates/updates those details for _future_ use.
AFAICT, this particular DNS lookup is a Squid bug: Squid should not
perform that lookup when "pinger_enable" is "off" because the result
of that lookup cannot be used for its intended purpose -- pining the
corresponding origin server.
I have not investigated whether Squid should ping origin servers when
going through a cache_peer. If Squid should not, then there is a
second bug here.
The ping should not happen when "pinger_enabled off", but the
"closest/fastest" selection algorithm(s) still needs IP address to
lookup the available NetDB information.
The second suspected bug happens _after_ "selection algorithm(s)" have
completed their work. Look for netdbPingSite() callers. In this specific
case, the caller is TunnelStateData::connectDone() which is
post-peer-selection and even post-peer-connection-establishment code.
The algorithm could be a bit smarter in noticing when all possible
destinations (eg prohibited DIRECT and single peer) have already been
selected and skipping useless attempts to find more alternatives. But
that is not necessarily a bug per-se.
For the specific case in question, those algorithms may already be smart
enough to avoid those unwanted DNS lookups: The first logged unwanted
lookup happens _after_ those algorithms are applied.
Alex.
_______________________________________________
squid-users mailing list
[email protected]
https://lists.squid-cache.org/listinfo/squid-users
