Hacker News Reader

Comment by Mister_Snuggles | Hacker News Reader

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?

View on HN

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

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.

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

TIL about ECH [0], thank you!

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

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.

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.

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.

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

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

That's a good thing.

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?

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

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.

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

It's "better" for the application, but not necessarily better for the whole system, or the users. I'm sure it makes perfect sense from the (selfish) application developer point of view, but it goes against the philosophy that defines the roles of the OS vs. the applications.

That's not engineering, that's just religion.

https://groups.csail.mit.edu/ana/Publications/PubPDFs/Archit...

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

I don't believe it's my responsibility to cover these basic concepts here, but the role of the OS is to abstract the hardware from the applications.

All browsers are applications, regardless of what Microsoft argued in their 1998 anti-trust suit defense.

The OS knows how to talk to your networking hardware, and it provides services for the applications to do so, and even implements some standard protocols so the applications don't need to do that.

This is all very basic stuff, but I've been out of school for many decades, so maybe they don't teach it anymore.

https://www.theringer.com/2018/05/18/tech/microsoft-antitrus...

What? Don't worry, I understand "the basic concepts". It's just that you yourself said that it was about a philosophy so it's weird to claim that disagreeing with said philosophy is just ignorance.

Also, I'm not sure you understand what quic is then? The kernel still handles most of the hardware abstraction, and in most cases still interacts exclusively with the hardware at the driver level (except for very high performance networking).

Yes, it can also help with protocols, but even going by your own definition ("but the role of the OS is to abstract the hardware from the applications"), protocols don't have to be at the kernel level.

You missed my original point, providing a browser was obviously an exaggerated example of doing more than just abstracting and handling the hardware. Which is also what implementing protocols at the kernel level is. The kernel still handles QUIC's UDP layer (and thus the hardware).

It's not even true that kernels universally handle hardware abstraction! Their argument is an overgeneralization of what Linux and WinNT happen to do.

Yes exactly, I completely agree! I was about to say that, but even with that rather restrictive definition it still doesn't make sense to want things like QUIC anywhere else but in userland.

But whenever I hear about "philosophy" in a discussion about kernels, I just default to assuming that they mean "whatever Linux does is the right way™".

But hey, I should've just skipped my kernel courses since they didn't teach me a lot about "kernel philosophy" lol.

Could you maybe explain it to David D. Clark too? He appears not to have learned it at school either.

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

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

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

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.

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

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

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.

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

Sure. My point is that blocking DoH wouldn't stop that though.

> Maybe I'm old-school, but I like to have some control over what's going in and out of my network.

What if you were a public Wi-Fi operator? You definitely shouldn't have control or insight into the traffic to and from other people's computers and phones.

> DoH seems to exist mainly to circumvent that control.

No, DoH is purely a good thing, since the evil use cases like above can happen even without it.

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.

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

> 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

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

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

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

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

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.

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.

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.

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.

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.

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.

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

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

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.

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

Android supports limited, preset DOH resolvers only.

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

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.

Reply on news.ycombinator.com