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

[bornfreddy]

TIL about ECH [0], thank you!

[0] https://developers.cloudflare.com/ssl/edge-certificates/ech/

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

[AnthonyMouse]

> Or maybe browsers would just let JavaScript connect to any port, which would be terrifying from a security standpoint.

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.

[mlhpdx]

Absolutely. The investment in HTTP means I can setup a website or API in a few clicks and pay nothing (or nearly so) for it. That has made it possible for me to try many, many things over the years. It’s fabulous.

I would very much like to see that same freedom to innovate when using other protocols.

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

[anonymousiam]

Please elaborate. Why is it "good" to have a separate network stack element in each application, and what does this mean for legacy applications that will never support QUIC?

[tptacek]

Because different applications have different needs and there is nothing intrinsically safer or better about having the stack be kernel-resident and, in fact, a lot to recommend moving things out of the kernel and into userland, which has a better application cotenancy model (full cr3 context switches between different users).

[anonymousiam]

Circumventing the role of the operating system in the name of improved efficiency and duplicating a once-centralized function in (some) applications doesn't seem like a well thought out course of action. Why have an operating system at all? Why not just boot your computer to each application you want to run, as was done on the early PCs of the 1980's?

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.

[tptacek]

"The role of the operating system" is whatever we decide it is. The operating system exists to serve applications, not the other way around. This isn't an aesthetic thing; it's an engineering choice. Moving parts (or all) of the networking stack into userland is often better engineering, for the reasons I just supplied, any of which I'm happy to go further into.

[mardifoufs]

Considering that a lot of people use their OS just to navigate the web, you could use the logic you are applying here to argue that the browser should be an OS provided component. Plus, networking is one of the easiest things to move to userland. An OS is still extremely useful for everything else, so I'm not sure I see your point

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

[josephcsible]

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.

[__turbobrew__]

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.

[josephcsible]

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

[throwaway290]

> 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

[__turbobrew__]

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

[anonymousiam]

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.

[josephcsible]

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.

[anonymousiam]

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.

[throwaway290]

> 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

[VWWHFSfQ]

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

[Mister_Snuggles]

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

[kuschku]

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.

[jonhohle]

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.

[jonhohle]

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

[josephcsible]

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.

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

[meindnoch]

Ok, but at that point there's zero benefit to DoH anyway.

[jen20]

There might be: even if my employer can decrypt traffic, there's no reason for either of my scumbag internet service providers to be able to.

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

[nerdsniper]

Yep with applications hardcoding addresses and utilizing certificate pinning, there's nothing the device owner/homeowner/network admin/system admin can do to inspect or modify DNS over HTTPS traffic, other than uninstall the application or block the connection entirely. Increasingly, blocking connections breaks the app so you almost might as well just uninstall the app or block it from being installed on managed endpoints.

[zinekeller]

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

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.

[eckelhesten]

Theoretically you could domainblock known DoH servers that certain applications would use.

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.

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