It’s not only about encrypted DNS. More important goal of this ticket is to provide DNSSEC (authenticated DNS). Many ISP provided DNS servers nowadays still do not offer DNSSEC. With an DNS-enhancement opt-in package users could get an option to easily enable system wide DNSSEC. DNS being encrypted on top of that since for example by using DNSCrypt is only a bonus on top.
- SNI: true but that may in the future no longer be the case thanks to ESNI (encrypted SNI)? Reference:
- IP: When behind cloudflare (or similar) that might be no longer applicable too? Would be ironic. Shared hosting might then be a privacy advantage.
Indeed.
Depends. On first visit of the website could be victim to sslstrip.
- sslstrip can be prevented if the website signed up to be added to the HSTS preload list.
- Btw also
DNS Certification Authority Authorization (CAA) Policycan help.
(related: DNS Certification Authority Authorization (CAA) Policy / DNSSEC for whonix.org / ssllabs.com test results / OCSP ERROR: Exception: connect timed out [http://r3.o.lencr.org] / Must-Staple)
Even if using HTTPS and encrypted DNS there could still be MITM attempts. In absence of 1) (HSTS preload) and 2) (CAA policy) there are still risks.
Right. My biggest worry is DoH centralizes DNS traffic at a few DoH resolvers. Increases centralization. If Firefox/Chrome enable that by default, and then DoH resolvers start with censorship, effectively fewer users can get access to information. Yes, there would be options to circumvent this and some would succeed but the net effect is that fewer people will have access. Censorship doesn’t become totally useless just because it’s not 100% efficient.
However, DNS-over-HTTPS isn’t what was previously implemented in this ticket which was was DNSCrypt instead.
If DNS-over-HTTPS in Firefox/Chrome gets enabled by default then whatever this opt-in package would do would be much less effective. It would then be for system traffic except from usual major sources of traffic, the browsers.