[Mister_Snuggles]

The thing that bothers me most about DoH is that it moves the responsibility for name resolution from the operating system to each application. So now you don't have the ability to set up your own DNS server system-wide, you need to do it per-application and per-device. Assuming, of course, that the applications and devices in question allow you to do this and/or respect your choice when you do it.

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?

[jlaporte]

> it moves the responsibility for name resolution from the operating system to each application

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...

[bornfreddy]

Not just that. ISP knows the IP addresses anyway, so they can make an educated guess which domain you are accessing (or use SNI). So why would I want to leak this data to another entity?

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.

[josephcsible]

> Not just that. ISP knows the IP addresses anyway, so they can make an educated guess which domain you are accessing (or use SNI). So why would I want to leak this data to another entity?

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.

[mlhpdx]

Yes, but it won’t be easy. Heavy investment has gone into HTTP and we have great tooling and support for it as a result. That has a lot of benefits and I’m glad for it. But there is a cost.

HTTP is a blunt hammer and computing sometimes needs a scalpel. Lighter, more efficient protocols are important, as QUIC and WireGuard have proven.

[Mister_Snuggles]

To play devil's advocate, shoving everything into HTTP/HTTPS also allowed a ton of innovation.

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.

[anonymousiam]

I have the same gripe about QUIC, but nobody seems to care. QUIC moves part of the network stack into the application layer.

[djha-skin]

It is bad on a server, but good on a mobile device. I hate QUIC too, but I'm Server guy.

[tptacek]

That's a good thing.

[josephcsible]

> 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?

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.

[lokar]

Why can’t you have a forwarding resolver send out queries via http and then use it as the system default?

[Mister_Snuggles]

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.

[PhilipRoman]

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

[meindnoch]

>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 the HTTP part of HTTPS is invisible to middleboxes. They see an opaque TLS stream.

[Mister_Snuggles]

Usually.

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).

[eckelhesten]

That’s incorrect. I use DNSecure (iOS app) to relay all DNS traffic on my iPhone to my DNScrypt-proxy server which I host on the internet (make sure you know what you do before exposing DNS servers on the internet).

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.

[Mister_Snuggles]

How does this prevent a random application from making an HTTPS request to a random hard-coded IP address? Similarly, how does this prevent an application from making an HTTPS request to a generic host (e.g., api.example.com)?

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.

[eckelhesten]

And in case it wasn’t clear. Yes it’s DNS-over-HTTPs and no one except my server and njal.la know about my queries.

[creatonez]

This is not the only way to use DoH. You can setup a system-wide resolver using dnscrypt-proxy.

[gsich]

This is only because applications think they should do that. There is nothing against a DoH client in the OS, I think Windows and MacOS already supports it.

[camhart]

Windows, mac, ios, chrome os all support DOH at the OS level to some degree.

Android supports limited, preset DOH resolvers only.

[marcosdumay]

> But shouldn't we fix the ISPs and middleware instead

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.

[AnthonyMouse]

HTTP3/QUIC is on the path for this because once you have "HTTPS" over UDP, the next thing that happens is you mark all of the actual HTTP bits as optional to implement since the middlebox can't see them and just run a datagram TLS VPN over port 443 to tunnel whatever you want.