Bug#1109583: please use SRV records to follow instead of using them as overwrites

On 7/20/25 22:22, Julian Andres Klode wrote:
>> no, as I've written it could mimic the same behaviour as 301 in HTTP(S) which obviously doesn't interfer with encryption at all.
> 
> The key difference is that this is signed and encrypted by the end point you wanted to talk to.

I'm afraid I don't understand.

To overwrite _https._tcp.deb.debian.org locally is the prerogative of 
the admin of the local DNS resolver and users have to trust them 
(otherwise they use their own resolver). DNSSEC doesn't help in that 
case, as it's not visible to the client using the resolver with the 
override.

> To use the SRV target as the hostname, the DNS record would need to be accordingly signed with DNSSEC and that verified such that the authenticity of the SRV can be tied back to the domain owner.

If the resolver the user trust in is returning a technically valid DNS 
answer to the client (e.g. mirror.example.org instead of fastly), the 
client cannot know it's semantically legit or not (see above).

Hence, the client (= apt) who is afaik not verifing DNS indepently of 
what is configured in /etc/resolv.conf, could then just take that record 
and connect to the 'new' hostname (mirror.example.org), verify its 
certificate etc.

If I understood your argument correctly, it would imply that apt should 
refuse to work in all situations where there's no local DNSSEC 
validation as it cannot trust the resolver or the intermediate network 
at all - so it would need to do all its DNS queries and DNSSEC 
verification on its own.

There is nothing to be prevented on that OSI layer here - as said 
before, local network adminstrators can always place a transparent proxy 
in between and filter traffic at their will. There is conceptually no 
defence in apt itself appropriate for that. What prevents abuse here is 
the signatures, hashes and expiration of what's inside the archive, not DNS.

oiow:

   * due to the public nature of a debian mirror, it's the content and
     it's up2date-ness that needs to be protected, not the mirror it
     comes from.

   * disallowing using SRV records to shape traffic is not increasing
     security or preventing anything, it's making legitimate network
     optimization for users benefit needlessly difficult/inconvenient.

Regards,
Daniel