[squid-users] Squid transparent not caching apt requests from deb.debian.org

[zrm]

On 4/8/20 13:13, Matus UHLAR - fantomas wrote:
> 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.
> 

It seems to be like this on purpose:

https://deb.debian.org/

I'm not sure there is actually anything wrong with their DNS 
configuration, it's not required for the SRV record to point to the same 
name/address as the A record (which would in fact defeat the point of 
the SRV record).

It *might* be a bug in apt, since if the SRV record says to use 
prod.debian.map.fastly.net then maybe it ought to be using that as 
"Host: " in the HTTP headers, but I'm not sure about that. If it's 
supposed to use the original domain in the HTTP headers when using a SRV 
record then this could still be a failing of squid for not checking and 
considering valid the address from the HTTP SRV record.

I'll send them an email and see what they have to say about it.