@@ -2363,3 +2363,85 @@ Cheers
23632363Amos
23642364
23652365
2366+ From rousskov at measurement-factory.com Fri Jan 16 13:56:04 2026
2367+ From: rousskov at measurement-factory.com (Alex Rousskov)
2368+ Date: Fri, 16 Jan 2026 08:56:04 -0500
2369+ Subject: [squid-users] peer-select.cc, cache_peer and dns queries
2370+ In-Reply-To: <3efcc634-0849-49a5-9532-92f28c60aec9@treenet.co.nz>
2371+ References: <C6552CCA-44F1-4FBE-B4AE-2CB20C955301@139.com>
2372+ <ec0ae64f-350c-4661-b27f-821436f66036@measurement-factory.com>
2373+ <2b4169659e66d98-00001.Richmail.00020836837433808968@139.com>
2374+ <6e1f74f3-ca70-4cd5-8b12-40f5ab1c9cac@measurement-factory.com>
2375+ <7663FB89-0DEA-4AAA-A720-222C4D19ABF4@139.com>
2376+ <bec610c5-9f44-4547-a99b-dfbc38294699@measurement-factory.com>
2377+ <CDD3EB38-B329-423E-B9C3-BAB8479A38D1@139.com>
2378+ <a41eff83-2afe-463c-835c-c1052d1746ed@measurement-factory.com>
2379+ <3efcc634-0849-49a5-9532-92f28c60aec9@treenet.co.nz>
2380+ Message-ID: <4b4940ab-e796-40fe-ab46-0121b3c4b049@measurement-factory.com>
2381+
2382+ On 2026-01-16 00:49, Amos Jeffries wrote:
2383+ > On 16/01/2026 05:28, Alex Rousskov wrote:
2384+ >> On 2026-01-15 02:14, archer wrote:
2385+ >>
2386+ >>> # {cache_peer ... ?no_netdb_exchange } already set earlier
2387+ >>> netdb_filename none
2388+ >>> pinger_enable off
2389+ >>> Icp_port0 #seems to be default value
2390+ >>
2391+ >>> And this issue persists. It seems that NO squid.conf could help with
2392+ >>> the DNS leak issue.
2393+ >>
2394+ >> Yes, your statement matches what I have stated in my previous
2395+ >> response: AFAICT, there is no squid.conf option that would disable
2396+ >> those DNS lookups in Squids built with `--enable-icmp` (which is also
2397+ >> the default).
2398+ >>
2399+ >>
2400+ >>> Q1: So, does Squid netdb work on the IP level?
2401+ >>
2402+ >> Squid NetDB feature has several parts/algorithms/statistics that use
2403+ >> various protocols. In this particular case, Squid prepares to "ping"
2404+ >> (via ICMP) the site targeted by the CONNECT request. Since ICMP needs
2405+ >> an IP address, Squid performs a DNS lookup first.
2406+
2407+ > Since NetDB is a database indexed by CIDR, Squid needs to know the IP of
2408+ > the origin server in order to lookup the details, even when going
2409+ > through a peer.
2410+
2411+ The buggy code path in question does not really "lookup the details". It
2412+ does not need them. Instead, when successful, the lookup
2413+ populates/updates those details for _future_ use.
2414+
2415+
2416+ >> AFAICT, this particular DNS lookup is a Squid bug: Squid should not
2417+ >> perform that lookup when "pinger_enable" is "off" because the result
2418+ >> of that lookup cannot be used for its intended purpose -- pining the
2419+ >> corresponding origin server.
2420+ >>
2421+ >> I have not investigated whether Squid should ping origin servers when
2422+ >> going through a cache_peer. If Squid should not, then there is a
2423+ >> second bug here.
2424+ >
2425+ >
2426+ > The ping should not happen when "pinger_enabled off", but the
2427+ > "closest/fastest" selection algorithm(s) still needs IP address to
2428+ > lookup the available NetDB information.
2429+
2430+ The second suspected bug happens _after_ "selection algorithm(s)" have
2431+ completed their work. Look for netdbPingSite() callers. In this specific
2432+ case, the caller is TunnelStateData::connectDone() which is
2433+ post-peer-selection and even post-peer-connection-establishment code.
2434+
2435+
2436+ > The algorithm could be a bit smarter in noticing when all possible
2437+ > destinations (eg prohibited DIRECT and single peer) have already been
2438+ > selected and skipping useless attempts to find more alternatives. But
2439+ > that is not necessarily a bug per-se.
2440+
2441+ For the specific case in question, those algorithms may already be smart
2442+ enough to avoid those unwanted DNS lookups: The first logged unwanted
2443+ lookup happens _after_ those algorithms are applied.
2444+
2445+ Alex.
2446+
2447+
0 commit comments