There's no reason you couldn't, and this would actually be fine in my view.

The problem is that with DoH the applications themselves have their own resolver built in that doesn't respect the system defaults.

Today, it's a good thing that applications don't respect the system defaults, since on basically every OS, the system defaults are either "totally insecure DNS all the time", or "auto fallback to insecure DNS". I'd only want programs to start respecting the system defaults if that ever changes.

You can change the system defaults on sane OS.

Thats like saying every application should come up with its own bespoke encryption framework because the OS doesn’t utilize full disk encryption by default. The solution is not to implement encryption in all your programs, the solution is to configure full disk encryption in the OS.

> You can change the system defaults on sane OS.

You can, but most people won't.

> Thats like saying every application should come up with its own bespoke encryption framework because the OS doesn’t utilize full disk encryption by default. The solution is not to implement encryption in all your programs, the solution is to configure full disk encryption in the OS.

Should password managers just store all of your passwords in cleartext instead of encrypting them, since you should be using FDE?

> Should password managers just store all of your passwords in cleartext instead of encrypting them, since you should be using FDE?

Better analogy, should every random app bundle own custom crypto and encrypt all files and ask user for password just in case some user does not set login password?

An app should do what it does, if secure storage is not its task then it probably should leave it to the os and if it's not DNS resolving then it shouldn't DNS resolve. Is very annoying

> You can, but most people won't.

Who is to say that insecure defaults is less good for most people? The reason why things like FDE and other enhanced security mechanisms aren’t enabled by default is because it increases the risk of things breaking for non tech savvy people. I have had to recover installs from peoples hard drives where the messed things up and if they used FDE they would have been screwed. The reality is that it is much more likely grandma forgets her password over somebody stealing her desktop and scraping her data. It would be nice for OS vendors to create profiles for OS installs, and then people who know what they are doing can opt for the “secure” profile, but I don’t think FDE can ever be the default on mass consumer devices.

> Should password managers just store all of your passwords in cleartext instead of encrypting them, since you should be using FDE?

Those are different threat vectors. FDE stops intruders from accessing your system when it is locked/off. Password manager encryption is to prevent rogue processes on an UNLOCKED system. The system can solve the second problem either by having a more granular permissions system (like iOS) so that process A cannot read data of process B, or the OS can have a secure enclave which can store your secrets behind biometrics.

Notably, both of these solutions are implemented in Apple world and I would argue that applications should consider using those system mechanisms instead of rolling their own encryption.

If you are actually serious about security you aren’t using passwords, you are using webauthn and u2f where possible.

When applications don't respect system defaults, they are by definition "going rogue."

I run Pi-hole because I like having some control over the IoT garbage on my (separate IoT) home subnet. Much of the IoT garbage already pins their DNS server, which limits my control, or makes control more difficult to achieve.

If you're worried about IoT garbage spying on you, blocking DoH wouldn't even help. Presumably, there's something important on the Internet that they need to access (since otherwise you'd just air gap them outright), so they could exfiltrate your data through the same connection that they're using for their legitimate purpose.

But that's the game that most IoT stuff plays. They offer some utility that makes them worthwhile, but they exfiltrate your data to marketeers and even government entities (such as Ring's partnership with law enforcement).

Maybe I'm old-school, but I like to have some control over what's going in and out of my network. DoH seems to exist mainly to circumvent that control.

> DoH seems to exist mainly to circumvent that control.

Hate to break it to you, but if I control the client, then I'm not in any way obligated to use DNS or any other IETF-endorsed protocol to turn names into numbers when I'm running on your network.

The idea of "controlling what's going in and out of the network" died in the 90s.

Sure, it's a "good thing" for the IoT garbage and the information hoarders, but it's not a "good thing" from my perspective, or from the perspective of corporate IT security.

Without DoH, only the evil IoT garbage with things like hardcoded IPs have "privacy". DoH gives privacy to legitimate users of regular browsers.

So it's good for the use case where the user does not control the subnet they're using, but not anywhere else.

> they could exfiltrate your data through the same connection that they're using for their legitimate purpose.

their traffic can be monitored. They can secretly exfiltrate if they hide it, use pin certs or use some custom encryption. This should be a red flag

Firefox at least allows to set your own DoH resolver if you want

I can see a future where Chrome will use the system resolver for everything except Google's advertising domains, and those name resolutions will be impossible to block because they're going to a Google IP that may also serve services you want. Maybe Chrome would get called out for this change and they'd back it off.

But I doubt that a smart TV that does this would get called out, and even if they were the response would likely be "Oh, that model is three months old and we don't do firmware updates, sorry."

That's already been the case for years, and is why DoH was invented in the first place.

Chromecasts hardcode DNS to 8.8.8.8, so people would redirect that traffic to their PiHole for adblocking.

To "fix" that, Google introduced DoH, which is why adblocking on chromecasts is significantly harder nowadays.

Google already makes blocking individual services nearly impossible. Want to give kids access to Google Classroom? Auth is done through google.com so now search is unblocked. What about Google Docs? You’ve just opened all of YouTube as well.

Just had a nice reminder that all of YouTube is accessible from Google Classroom as well.

That's not a good argument to block DoH, since once apps or devices would start doing that, they could just as easily start hardcoding the IPs instead.

You can, in fact that's how Arch wiki suggests doing it: https://wiki.archlinux.org/title/DNS-over-HTTPS