What’s Next in Making Encrypted DNS-over-HTTPS the Default

It's nice that Firefox (currently) still offers options to turn off DoH and to keep using local domains. (although the way DoH and HTTPS-everywhere are structured show that non-internet sites don't seem to have much of a place in the web of the future)

However, now that we have public DoH endpoints available for everyone to query, what will keep non-browser apps and devices from using DoH without any way to opt-out?

Currently, tracking DNS requests seems to be a common way for security and privacy researchers to get some basic information what an app or device is doing on the internet. If DoH is widely deployed, all you'll probably be seeing is encrypted connections to IPs of shared hosters.

This seems like a perfect opportunity for apps and devices to cloak data tracking and other illegitimate requests.

Why do you think that is? I understand that their solution is not perfect (nothing ever starts out that way), but the amount of aggression in your comment suggests that something deeper is going on. Do you feel threatened?

I suspect it's fear of change. As people realize that plain-text DNS is a gaping security hole, they are going to start demanding encryption. This means you, the administrator, will have to learn more skills and do more work to keep things running. Things like `.local:` printers may break, and you may have to upgrade your internal DNS servers to RFC8484 so you can keep your split-horizon stuff working. Security is never free.

Or not. None of this is mandatory, and you can just switch it off (and Mozilla will automatically switch it off if they detect an environment like yours, as it says in TFA). The threat isn't Mozilla "deciding policy" for you (they aren't), the threat is that they are calling the industry out for running old & vulnerable DNS standards, and we all know deep inside that they are right.

I know perfectly well who operates my DNS server: My ISP. If they are doing shady stuff, I can sue them, raise awareness or switch providers.

I can't do the same with hardwired DoH endpoints.

Until recently, the general understanding was that each network operator was responsible for the clients inside their network - and therefore also had the ability to set the network's configuration.

In 99.99% of the cases, this included access to nonlocal sites on other, public network's, aka "the web", but this was nowhere technically required. Browsers and other DNS-consuming apps were perfectly capable of working within other networks. What a DNS name resolved to was technically a property of the network.

By now, this model is shifted towards the Web as a platform with browsers and DNS as clear parts of it - a platform that is incidentally pay-to-play and centrally controlled by the US because at the very least you need recurring payments for your domain and you need to give companies and institutions located in the US control over your machine.

This shift has been going on for a long time, but I believe HTTPS-everywhere and DoH have served to make this unignorably obvious because those bring the concept of the web platform into the technology stack itself.

To make the tired old car analogy again: In the vast majority of cases, you will drive your car on the public road network and nowhere else. However your car is technically capable of driving off-road or performing highly questionable maneuvers in your backyard because the car itself doesn't have any concept of "public roads", "private roads" or "non-roads". DoH would be adding a device that turns off the engine as soon as you're not on a public road. What exactly constitutes as a "public road" is determined by the car manufacturer.

I do agree that in the long run it might be better for ensuring that "the web" is the same no matter from where you visit, but I think it's definitely more than a simple technical change.

I also think all the heuristics, opt-outs and special rules for corporate network's don't cut it, because they relegate the current default case to an uncommon special case - and developers have a habit of ignoring uncommon special cases. I wouldn't be surprised if we see a lot of non-browser apps and devices in the future that use DoH by default and that an administrator would have to reconfigure by hand for each single installation - or that are simply hardwired to some set of DoH servers without any way to configure them at all.

The benefit they do provide is authentication (ensure that google.com is really google.com) and protection against man-in-middle.

And those are great benefits!!

But it doesn't help anyone to misstate and/oversell the benefits of a new service/protocol.