Browsers only took on DoH implementation directly because they were solving the cold-start problem for a new protocol. Nothing to do with the spec.
There is support for DoH in all major OSs today, but none have made it a simple box to click AFAIK (we could speculate why).
For macOS, iOS, either via Private Relay (paid) or a configuration profile. Premade profiles: * https://github.com/paulmillr/encrypted-dns
For Windows > In the Registry Editor window open: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters > Right-click within the “Parameters” folder and create a new Dword (32-bit) Value. Name this new file “EnableAutoDOH” and set its value to “2.” * https://superuser.com/posts/1764668/revisions
Linux: * https://dev.to/mfat/how-to-enable-system-wide-dns-over-https...
Of course, Cloudflare (if page uses them) and Google (if you are not blocking their remote fonts & js) also already have this information, so there's that.
Because a lot of sites are behind a CDN that makes such guessing infeasible, and can use ECH to block the SNI leak. And since your ISP knows your real identity and other personal info like physical address, it's better privacy-wise for them not to be the ones who know exactly which sites your IP is visiting.
[0] https://developers.cloudflare.com/ssl/edge-certificates/ech/
HTTP is a blunt hammer and computing sometimes needs a scalpel. Lighter, more efficient protocols are important, as QUIC and WireGuard have proven.
Would video streaming sites (Youtube, Vimeo, etc) ever have gotten off the ground if they had to go to IANA to get a port number assigned, then wait for browsers to support the new protocol that runs over the new port, etc? Probably not to be honest. Or maybe browsers would just let JavaScript connect to any port, which would be terrifying from a security standpoint.
I'm firmly convinced that shoving everything into HTTP/HTTPS was a mistake. But I'm also willing to acknowledge that it's probably the least-worst solution to a bunch of problems.
Isn't this just WebRTC?
Also, why does everything have to be done in a browser? We're talking about name resolution. That's supposed to be done by the OS regardless so you don't have a thousand separate configuration options to change if you want to change your DNS server.
I would very much like to see that same freedom to innovate when using other protocols.
Perhaps we shouldn't use computers to run our applications anymore. Everything could run on a gaming console. That would certainly be more efficient for the applications.
It'd be great for the horrible ISPs and middleboxes to change, but that's not realistic, and working around it by wrapping everything in HTTPS is realistic.
The problem is that with DoH the applications themselves have their own resolver built in that doesn't respect the system defaults.
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, 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?
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.
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."
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.
But the HTTP part of HTTPS is invisible to middleboxes. They see an opaque TLS stream.
Some middleboxes inspect the TLS session setup (e.g., SNI sniffing) and in some corporate environments they even decrypt the traffic (this relies on the endpoints having a root certificate installed that allows this functionality, which is something you'd see in a corporate environment).
It’s awesome because I have system wide tracker/adblocking which works whether or not I’m on my LAN and even with Apple Private Relay on.
This is what DoH looks like from outside the application. You can't really tell that it's DoH since it's just an HTTPS connection, which is kind of the whole point of it.
I think that, franky, even without DoH, that ship has sailed. WhatsApp and Telegram (to name a few) is known to embed IP addresses into their applications. It is silly to assume that not standardizing DoH will not result in the same situation, and I imagine there are custom DNS bootstraping happening, for good or evil.
But yes, I believe that if an application try hard enough there are ways to bypass any set of rules you set on a device. Luckily, most applications just use the internal libresolv for any domain resolving needs.
Android supports limited, preset DOH resolvers only.
Well, good luck with that.
I say we formalize an entire internet tunneled over HTTPS and throw some eggs on the face of those people.
Also shoving every protocol under the sun into HTTPS just feels wrong. I get why it's happening (too many middleware boxes and ISPs think internet == web). But shouldn't we fix the ISPs and middleware instead of endlessly working around it?