[squid-users] peer-select.cc, cache_peer and dns queries

[Alex Rousskov]

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.