Bug#993272: allow using multiple SRV records to load balance mirrors without CDNs
2021, ഓഗസ്റ്റ് 30 1:22:57 PM IST, Julian Andres Klode <jak@debian.org>ൽ എഴുതി
>On Mon, Aug 30, 2021 at 02:16:08AM +0530, Pirate Praveen wrote:
>> Package: apt
>> version: 2.3.8
>> severity: wishlist
>>
>> If I understand correctly, the current SRV record implementation is
>> targetting CDNs so all servers will be responsind to the same hostname and
>> will have certificates matching the main hostname.
>>
>> I'm exploring the possibility of using SRV records to transparently load
>> balance between multiple mirrors. This works well for http but will fail for
>> https.
>>
>> Current DNS setting is,
>>
>> $ dig +noall +answer -t SRV _https._tcp.fasttrack-mirror.fsci.in
>> _https._tcp.fasttrack-mirror.fsci.in. 60 IN SRV 10 1 443
>> fasttrack.debian.net.
>> _https._tcp.fasttrack-mirror.fsci.in. 60 IN SRV 10 1 443 mirror.linux.pizza.
>>
>> and the error
>> Err:3 https://fasttrack-mirror.fsci.in/debian-fasttrack bullseye-fasttrack
>> InRelease
>> Certificate verification failed: The certificate is NOT trusted. The name
>> in the certificate does not match the expected. Could not handshake: Error
>> in the certificate verification. [IP: 185.181.160.236 443]
>>
>> This is expected because neither fasttrack.debian.net nor mirror.linux.pizza
>> has tls certificates for fasttrack-mirror.fsci.in
>>
>> Would it be possible to use the hostnames mentioned in SRV records for
>> retrieving the data instead of the main hostname? Is there any security
>> concerns for doing that?
>
>Can't use the target hostnames, as the SRV record, like all DNS, is not
>trusted. You'll have to redirect at an http(s) level if you want this,
>or issue certificates for the hostname to all SRV endpoints.
Thanks for the suggestions. Just curious if the threat of a malicious SRV record is worse than serving plain http repository ?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Reply to: