On 4/7/20 8:48 PM, zrm wrote:
https://www.trustiosity.com/squid/cache-debug.log.xz
On 4/8/20 10:46, Alex Rousskov wrote:
I found the reason for the difference.
After the destination IP address of your apt requests fails Host header
validation, Squid marks the request as "not cachable":
On 08.04.20 13:01, zrm wrote:
I checked the DNS query apt is making to see why it's different. It's
making a SRV query for _http._tcp.deb.debian.org and then using the IP
address of the name (prod.debian.map.fastly.net) returned in the SRV
query. By contrast, squid does the A record query for deb.debian.org
and gets a CNAME for debian.map.fastly.net. Almost the same, but since
it's a CDN with many IP addresses, enough different that they happen
to not both return the same address and then validation fails.
Meanwhile wget does the same A record query as squid and gets the same
address.
The question then becomes what to do about it. Maybe if squid fails
the validation for the A query, it should try the SRV query and accept
the address as valid if it matches that. Another possibility would be
a config option to have squid completely ignore the address the client
used and always use the address it gets by doing its own DNS query for
the host, in which case the result would be safe to cache.
But these are obviously changes requiring a new version of squid. Is
there any way to make it work without that?
I'd contact debian.org DNS masters. I believe CDN wasn't designedto cause this
kind of issues.
--
Matus UHLAR - fantomas, uhlar@xxxxxxxxxxx ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Despite the cost of living, have you noticed how popular it remains?
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
