> DNS over HTTPS is by itself bad enough, and highly criticized with good reason
The criticisms of DoH seem to be around removing the ability of third parties to snoop on your DNS queries. Am I missing something here?
Like, yes, some of the use cases outlined in the linked wiki article [0] are arguably legitimate (parental controls, cybersecurity identification of C&C nodes), but then we quickly move into murkier territory (ISP blockages due to government mandates).
Preventing MitM attacks is an explicit design goal of DoH, not a side effect.
DoH on-by-default means that I as a sysadmin -- for my family, enterprise, or even just my own computer -- no longer have the ability to easily specify how DNS works for the systems under my control. Maybe I run a PiHole; maybe I run a parental control DNS server; maybe I'm better at privacy protection than Mozilla and Cloudflare are.
Tough luck; now I'm no longer able to configure all my systems to use my DNS server over DHCP. I can't even manually set the global DNS server for one computer any more. Now I have to manually set preferences on every instance of Firefox (at least to verify that DoH is truly off), and every other application that adopts DoH one at a time.
The goal of DoH for preventing snooping by ISPs is fine. It's the implementation with hardwired per-application resolver hosts that's bad.
Edit: There's a way to tell Firefox to disable DoH at the network level [0] but AFAIK this is just a Mozilla thing; it's not an RFC. Will other browsers and apps adopt this mechanism? Who knows?
Tell me where I'm wrong or misunderstanding here: If you consider DNS analogous to HTTP, then DoH is TLS and the DNS provider is the CA (the org you need to trust). Your objection is that you can't modify protocol traffic since there is now an authority out of your control. It seems to me like it increases the security of the user since the network operator can no longer modify the traffic that the user requested.
I get that it makes some use-cases harder, just like HTTPS made some HTTP use-cases harder (like captive portals for wifi login) but in the end it seems like a net benefit for the majority of usecases (I want the same site, securely, no matter the network I'm on), right?
The DNS provider is not analogous to the CA. Remember that the CA only certifies that Cloudflare is in fact the Cloudflare, and not Joe's All-Night CDN and Lotto Ticket Dealer. The CA does not vouch for the ethics of Cloudflare, just like the CA does not vouch for the ethics of Google. So that's point 1.
Point 2 is that if I for some reason don't trust Cloudflare to protect my users' privacy or provide speedy service or hey, maybe I just don't like the fact that they carry traffic from a bunch of seditionists -- whatever -- then I have no easy way to say to Firefox: Don't Use Cloudflare, use my provider who I do trust.
I don't care what sites my users are visiting, so inspecting their DNS traffic is not something I need to do (although perhaps it is for certain enterprises). The central point is that I no longer get to easily choose which DNS provider to trust; Mozilla has made that choice for me. That breaks the internet in a way analogous to the way AMP breaks it, and that's wrong.
I can in fact change that choice but doing so introduces a new protocol and a new set of labor-intensive tasks for the sysadmin that did not exist before, and for every app that adopts the Mozilla model, that labor increases yet more.
It's horrible for environments with split horizon DNS. It presumes that the only network that should exist are home users consuming public Internet cloud services.
For privacy it's a discussion of do I trust my obnoxious non-US ISP or a US based .com with seeing all my browsing habits based on DNS queries. At least I could have legal recourse with my ISP in my own country, and there is slightly better privacy laws.
It was a fine simple solution until DoH. In some internal environments the internal traffic volume can be much higher than the few services that might be publicly exposed.
Sure lots of ways you could do it - get a fat edge firewall to hairpin the traffic + support Internet access but you end up paying a lot more for all the threat licenses on the oversized edge. Could add many more tiers, maybe more translations or overlays... but why bother with a lot more complexity or especially more cost just because someone saw a threat in another country and are trying to solve a problem that does not apply to most.
Further more there can be internal only host names that are now getting probed and exposed externally. Exfiltration to a US company in the name of "security"
Hiding a DNS entry doesn't do anything to hide the machine. How long do you think a newly exposed IP address, without a DNS entry, will last before it is probed?
I just hate that it breaks Split Horizon which is totally legitimate. Leaking local-to-the-LAN queries onto the public internet is also a concern.
IMO the right way to do this is to run your own local DNS recursive resolver, and deploy DNSCurve. This doesn't work for myopic browser vendors though...
I get that breaking split horizon is a real concern, but also I would expect any enterprise deployment using internal DNS resolvers should be able to set up its users' Firefox config to either a) point at an internal DoH server, or b) turn it off?
On one hand, I see the arguments against DoH-by-default -- loss of control, potential for unfixable poor / buggy implementations, requiring trust of third parties... (The trust problem isn't going to be solved any time soon, though.)
It would be nice if implementations just used the discovered DNS server across the board, but DNS servers don't support DoH across the board yet.
On the flip side, I don't see any widespread shifts in this space until a large enough player (in this case, Mozilla) decides to put its thumb on the scale to "encourage" wider adoption. While centralized DoH may be the only game in town today, I would argue that's due to lack of adoption, and I would hope that's not the desired end state.
If you want to prevent MitM attacks, run a local DNS server with DNSSEC. DoH is a trend in the wrong direction. The more IoT garbage begins using DoH, the less control over your privacy you will have. Solutions like pi-hole are rendered useless by DoH.
Since virtually none of the most popular domains are signed, going to the trouble of installing a local DNSSEC server isn't actually going to protect you from anything. Meanwhile: if you're in North America, your ISP is almost certainly collecting and warehousing your DNS queries, and DoH immediately breaks that. Plenty of people use DoH through Pi-holes, for what it's worth.
Not all MitMs inject malicious responses; denial of service is equally problematic. If you can block DNS requests via a pihole, so can your upstream ISP (whether it's because they want to throttle your internet usage, or police it, or whatever else).
And even just a passive observer snooping on your DNS requests can result in an invasion of privacy.
I agree on all counts, but DoH removes control and choices that I want to keep. pi-hole itself supports DoH. It's a good way to protect privacy and keep control.
The criticisms of DoH seem to be around removing the ability of third parties to snoop on your DNS queries. Am I missing something here?
Like, yes, some of the use cases outlined in the linked wiki article [0] are arguably legitimate (parental controls, cybersecurity identification of C&C nodes), but then we quickly move into murkier territory (ISP blockages due to government mandates).
Preventing MitM attacks is an explicit design goal of DoH, not a side effect.
[0] https://en.wikipedia.org/wiki/DNS_over_HTTPS#Criticisms_and_...