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

Reply via email to