Hacker News Reader

> If you don't want Cloudflare seeing your DNS requests, then use one of them instead.

Normal people have no idea that this even exists, much less how to do it, so they're still having all their queries routed to Cloudflare by default.

> The only difference between DoT and DoH is that DoT is easier to block and force fallback to totally insecure DNS.

A normal middlebox can't even tell the difference between DoH and DoT because they both just look like TLS. A corporate one that requires you to install certificates on the client so that it can, is just as able to block DoH as DoT.

And fallback isn't required in either case. If some network is blocking encrypted DNS, the client device can be configured to fail rather than use the insecure DNS, at which point the user knows that the network is adversarial and can switch to a VPN or a cellular connection etc.

> A normal middlebox can't even tell the difference between DoH and DoT because they both just look like TLS.

You forgot the "let's intercept in a public place (e.g. public Wi-Fi hotspots)" one where blocking port 853 is super trivial while blocking port 443... is impossible. Sure, Google DNS will be blocked easily but there a lot of DoH providers!

There is no law against running DoT over port 443.

At that point you might as well use DoH. But you're also reasoning axiomatically about something we have a lot of documentary evidence for: the DNS operator community (or a big chunk of it) favors DoT and opposes DoH because they want to make it easier to block encrypted DNS; they frame this in terms of "control over their own networks".

> At that point you might as well use DoH.

What benefit is the additional complexity and overhead of HTTP buying you there?

> the DNS operator community (or a big chunk of it) favors DoT and opposes DoH because they want to make it easier to block encrypted DNS; they frame this in terms of "control over their own networks".

This is one of the main issues here: When then DNS operator is you, i.e. your local network at home or your corporate network within your own company, you should be able to control DNS on your own network, which you can't if a bunch of adversarial devices are bypassing your DNS servers.

When the DNS operator is your ISP, letting them block encrypted DNS is bad.

So what we need is some way to distinguish between these situations so that the local network administrator's preferences are heeded but Comcast can go pound sand. But browsers are too late in the stack for that because they have no way to tell if the system DNS server is the one the user wants or the one they got by default from their ISP and never knew to change.

I don't think we need any way to distinguish these situations any more than we needed to preserve the non-ephemeral key exchanges in the jump from TLS 1.2 to TLS 1.3, which were opposed for the same reason. You can control which computers you allow on your network, and allow only computers which give you endpoint monitoring. The 2025 TCP/IP protocol stack should not be going out of its way to give network operators more visibility into what applications are doing.

> You can control which computers you allow on your network, and allow only computers which give you endpoint monitoring.

This would be a great argument if it was actually feasible, but then you have Chromecasts hard-coding Google's DoH servers to prevent ad blocking etc., and devices doing automatic firmware updates to change things like that after you've already bought them.

Pass the law that says the customer has to be given root and the ability to install custom firmware on any device they buy before saying that is reasonable.

You're not going to get either of those things. The market has converged on DoH and applications will continue to run it, and you're not going to get a law giving you root on all the devices that go on your network. If you're concerned about Chromecast's DNS, don't hook up a Chromecast. I don't, and I'm doing fine.

Saying "the market" when you're mainly just talking about Firefox and Chrome implies that it couldn't be changed just by convincing a small set of specific people.

And we'll yet see about that law. Right to repair is pretty popular.

Good luck. It doesn't bear in any way on DoH, though.

There are only like 3 major ones. You can block those IPs too.

There's a ton of minor ones, it's easy to spin up your own, and the hope is that eventually, with ECH, it won't be possible to block them without blocking basically the entire Internet like North Korea does.

By the time you're spinning up your own there isn't any issue. The controversy is that they're switching everyone to Cloudflare by default.

What do you propose they do instead? They obviously can't trust the network-provided one, since the whole point is that that one is often malicious.

Malicious DNS in terms of returning bad results is generally irrelevant because if you can't trust the network then returning the wrong IP address and routing the right IP address to the wrong server are the same. Also, you're using HTTPS/TLS/SSH/etc. on the actual connection anyway, right?

So the point of this is to prevent Comcast from seeing your DNS queries. And then it works fine to trust the network to say "no, really, use this one and not the default DoH one" as long as that setting is one that Comcast would get in trouble for misusing. Notice that they don't return bad results for use-application-dns.net as it is.

> Normal people have no idea that this even exists, much less how to do it, so they're still having all their queries routed to Cloudflare by default.

This goes the other way too. Normal people don't know about DNS at all, and without DoH, are leaking all of their DNS queries to their ISP without knowing.

> A normal middlebox can't even tell the difference between DoH and DoT because they both just look like TLS.

DoT uses port 853, which can just be blocked wholesale. It's not feasible to do the same for DoH since it uses port 443.

> And fallback isn't required in either case. If some network is blocking encrypted DNS, the client device can be configured to fail rather than use the insecure DNS, at which point the user knows that the network is adversarial and can switch to a VPN or a cellular connection etc.

It can be, but it's not the default on any mainstream system. Normal people won't change defaults, and they deserve privacy too.

> This goes the other way too. Normal people don't know about DNS at all, and without DoH, are leaking all of their DNS queries to their ISP without knowing.

But is this actually any better than leaking them to Cloudflare? There is at least the possibility that the ISP isn't logging them and that they only run a DNS server because their customers expect one.

It's hard to imagine any reason for Cloudflare to do it other than because they want to analyze DNS traffic, and then it's in a much more centralized location than to be distributed across every network and ISP.

> DoT uses port 853, which can just be blocked wholesale. It's not feasible to do the same for DoH since it uses port 443.

So run DoT over port 443. The benefit of DoT is removing the implementation complexity of a pointless HTTP stack.

> Normal people won't change defaults, and they deserve privacy too.

So change the system defaults to use DoT. That might even get you port 853 open, because breaking the defaults in popular devices would get the network admins off their butts to notice that a new protocol exists.

> But is this actually any better than leaking them to Cloudflare? There is at least the possibility that the ISP isn't logging them and that they only run a DNS server because their customers expect one.

> It's hard to imagine any reason for Cloudflare to do it other than because they want to analyze DNS traffic, and then it's in a much more centralized location than to be distributed across every network and ISP.

Your ISP knows your real-world identity, whereas Cloudflare just knows your IP address. And I trust most ISPs, e.g., Comcast, less than I trust Cloudflare.

> So run DoT over port 443. The benefit of DoT is removing the implementation complexity of a pointless HTTP stack.

That would be perfectly fine and address all of these problems, but it isn't how things work today, and unless/until it does happen, I think DoH is way, way better than DoT over port 853.

> So change the system defaults to use DoT. That might even get you port 853 open, because breaking the defaults in popular devices would get the network admins off their butts to notice that a new protocol exists.

That'd only be true if the system defaults prevented fallback to insecure DNS, and so far, the few systems that support any form of secure DNS all will automatically do insecure fallback.

> Your ISP knows your real-world identity, whereas Cloudflare just knows your IP address.

Your ISP also just knows your IP address. They may have some information linking that IP address to a person, but so does Cloudflare, which does a MITM on half the internet and thereby knows not just your identity but the things inside the TLS connections you make.

> That'd only be true if the system defaults prevented fallback to insecure DNS, and so far, the few systems that support any form of secure DNS all will automatically do insecure fallback.

So change the system defaults instead of having the browsers disrespect the system settings that may well have been purposely set by the user.

> Your ISP also just knows your IP address. They may have some information linking that IP address to a person, but so does Cloudflare, which does a MITM on half the internet and thereby knows not just your identity but the things inside the TLS connections you make.

But then Cloudflare has your info even without DoH, so in that case, it's strictly more private to use DoH.

> So change the system defaults instead of having the browsers disrespect the system settings that may well have been purposely set by the user.

Just like you said about running DoT over port 443: this is a totally reasonable thing that would solve the problem, but it isn't how things work today, and unless/until it does happen, I think browsers defaulting to using secure settings when the system settings are insecure is the better option. (Especially since users who purposely don't want DoH can just manually configure their browser too in that case.)

> But then Cloudflare has your info even without DoH, so in that case, it's strictly more private to use DoH.

They have your info when the site you're accessing uses Cloudflare, which means they know more than enough to identify you.

Now you're telling them when you access a site that doesn't use Cloudflare.

> Just like you said about running DoT over port 443: this is a totally reasonable thing that would solve the problem, but it isn't how things work today, and unless/until it does happen, I think browsers defaulting to using secure settings when the system settings are insecure is the better option.

How do you get them to stop doing it once a better solution exists?

> Especially since users who purposely don't want DoH can just manually configure their browser too in that case.

This is the problem with doing it this way. Suppose I don't want DoH in my house, how do I get rid of it? Configure six different browsers on each of the dozens of devices in my family and hope I didn't miss any?

It needs something in the nature of "change this DHCP option on your internet gateway" is the issue, but that thing needs to be a universal standard that everything respects.

> They have your info when the site you're accessing uses Cloudflare, which means they know more than enough to identify you.

> Now you're telling them when you access a site that doesn't use Cloudflare.

But if Cloudflare already has that info from half the Internet, then the loss of privacy from that is outweighed by the gain of privacy from hiding it from your ISP.

> How do you get them to stop doing it once a better solution exists?

Once Windows, macOS, iOS, and Android all default to secure DNS with no automatic fallback, I expect browser vendors will be perfectly happy to change it.

> This is the problem with doing it this way. Suppose I don't want DoH in my house, how do I get rid of it? Configure six different browsers on each of the dozens of devices in my family and hope I didn't miss any?

The phrase "devices in my family" sounds a lot like "other people's devices", so wanting that seems uncomfortably close to what the malicious network operators want.

> It needs something in the nature of "change this DHCP option on your internet gateway" is the issue, but that thing needs to be a universal standard that everything respects.

That's specifically what there needs to not be, because if such a setting existed, malicious networks would all just use it.

> But if Cloudflare already has that info from half the Internet, then the loss of privacy from that is outweighed by the gain of privacy from hiding it from your ISP.

Except that your ISP gets it anyway via SNI and seeing which IP addresses you connect to.

> Once Windows, macOS, iOS, and Android all default to secure DNS with no automatic fallback, I expect browser vendors will be perfectly happy to change it.

Then why is Chromecast hard-coded to use Google's DNS with no option to even manually change it?

> The phrase "devices in my family" sounds a lot like "other people's devices", so wanting that seems uncomfortably close to what the malicious network operators want.

The "devices in my family" want the same DNS server because they want to be blocking ads and malware. The issue is there are then rather a large number of them and requiring them each to be configured individually with many opportunities for omissions becomes a security vulnerability, since omissions allow the malware through.

You also need this if you want devices to resolve local names.

> That's specifically what there needs to not be, because if such a setting existed, malicious networks would all just use it.

The browsers already have this:

https://support.mozilla.org/en-US/kb/canary-domain-use-appli...

The problem is it's not a standard so then not everything respects it or does it the same way, and devices not implementing it out of malice (e.g. to purposely avoid ad blocking) get to pretend they're not doing anything untoward.

> Except that your ISP gets it anyway via SNI and seeing which IP addresses you connect to.

Hence my point about CDNs and ECH upthread.

> Then why is Chromecast hard-coded to use Google's DNS with no option to even manually change it?

I lump Chromecast into the "IoT" category, not the "browsers" category. Google could spy on you even with no DNS access at all if it wanted to.

> The "devices in my family" want the same DNS server because they want to be blocking ads and malware. The issue is there are then rather a large number of them and requiring them each to be configured individually with many opportunities for omissions becomes a security vulnerability, since omissions allow the malware through.

If you're concerned about that, don't you realistically need something like uBlock Origin on each endpoint anyway, since so many sites serve their (malware-laden) ads from their own domains these days, specifically because of things like the Pi-Hole?

> You also need this if you want devices to resolve local names.

There would be nothing wrong with a fallback just for TLDs like ".local" and ".internal" that will never exist for real on the Internet. The critical "no fallback" point is just for potentially-real TLDs when the DoH server isn't reachable.

> The browsers already have this:

> https://support.mozilla.org/en-US/kb/canary-domain-use-appli...

> The problem is it's not a standard so then not everything respects it or does it the same way, and devices not implementing it out of malice (e.g. to purposely avoid ad blocking) get to pretend they're not doing anything untoward.

That setting is bad and needs to go away. It completely defeats the purpose of DoH.

> Hence my point about CDNs and ECH upthread.

ECH isn't widely used and the IP address still reveals a ton of information regardless.

> I lump Chromecast into the "IoT" category, not the "browsers" category. Google could spy on you even with no DNS access at all if it wanted to.

In that case it's more about ad blocking than spying.

> If you're concerned about that, don't you realistically need something like uBlock Origin on each endpoint anyway, since so many sites serve their (malware-laden) ads from their own domains these days, specifically because of things like the Pi-Hole?

Most sites don't have the technical capacity to do that and you still get to block all of the others. Also, a lot of the malware comes from scummy ad networks that innocent sites used out of ignorance, and then blocking the ad network blocks the malware which that site isn't purposely trying to foist on you.

> There would be nothing wrong with a fallback just for TLDs like ".local" and ".internal" that will never exist for real on the Internet. The critical "no fallback" point is just for potentially-real TLDs when the DoH server isn't reachable.

You can get a TLS certificate for any real name, including dynamic DNS names on some providers, even if those names are only used locally, using ACME DNS01. You can't get a TLS certificate for .local or .internal names. But you may not want to put local names in the global DNS, or they may not resolve to the same IP address everywhere, e.g. you need some server to resolve to the public IP from the internet but the local IP on the LAN.

> That setting is bad and needs to go away. It completely defeats the purpose of DoH.

It doesn't, because Mozilla owns that domain and ISPs refusing to resolve it would get in trouble in most countries, so they don't, and then people using the default ISP DNS still get DoH instead.

You can manually configure your browser to always use DoH regardless of that entry, which is what people on actually malicious networks do. Its purpose is to make it so the default can be changed without touching every single application on every single endpoint device.

> It's hard to imagine any reason for Cloudflare to do it other than because they want to analyze DNS traffic, and then it's in a much more centralized location than to be distributed across every network and ISP.

Isn't bot/DDoS protection a very obvious reason for Cloudfare to do it?

Any normal user agent will make a DNS request shortly before requesting a page from that domain. A normal user agent will also request the page from the IP returned by the DNS server.

Attempting to connect to a server IP hosted by Cloudfare from a client IP that has not recently received that server IP in a DNS response seems like an obvious signal for their bot/DDoS mitigation system.

> Any normal user agent will make a DNS request shortly before requesting a page from that domain. A normal user agent will also request the page from the IP returned by the DNS server.

How does that tell them anything when there are many legitimate client devices using someone else's DNS servers?

Are there really public DoT servers that listen on port 443? Do you have an example? I would be interested.

Anybody can get a VPS and install a DNS server on it using any port they want. You can also turn a VPS into a VPN or use any number of existing VPN providers that allow VPN connections on port 443.

If public DoT servers listening on port 443 do not exist, I find the argument about the fact that blocking 853 is very easy a very valid one then.

Only a very small minority will be able to run their own DNS server I assume.

With or without DoH you ISP knows all hosts you connect to anyway, for HTTP and similar including hostname. ECH could have been an improvement but does not get much traction.

ECH is getting deployed, and we shouldn't make it forever useless just because it's not widely deployed already.

> Normal people have no idea that this even exists, much less how to do it, so they're still having all their queries routed to Cloudflare by default.

This is a complaint about Firefox's implementation, not DoH in general. Chrome will use DoH with your system dns provider, if it supports it.

I'm torn on whether using cloudflare by default was a good choice. On the one hand, having all requests going to a single provider and trusting that provider not to log anything is a potential privacy problem. And it can cause problems for people who use private DNS resolvers. On the other hand, even if you don't completely trust cloudflare, it is probably more private than a lot of people's default DNS providers that come from ISPs that are known to spy on customers either for profit or at the request of a government.

The article is not wrong, it's exactly what they're doing, but so does Google with their 8.8.8.8 servers, and you thought Google was doing it out of the goodness of their hearts (after they removed the do not be evil clause).

At least Cloudflare offers their 1.1.1.2 and 1.1.1.3 resolvers with built-in content filtering or full adult content filtering as as unfiltered 1.1.1.1, which is better than others. Normally folks pay Cisco OpenDNS or other enterprise-y products for this, and I applaud them doing it in general, for free. I'd set my mother to use it if something I had to do still. Cloudflare is probably one of the less-evil companies today, and is a good engineering company if you follow their blogs.

Apple is actually worse in that they forced an entire DNS AND Web Proxy solution to get ALL traffic every apple users do in the name of "privacy", but in the end it's really more for their marketing and analytics they can sell at will. Funny Google tried to offer a VPN service and everyone shunned it, but Apple people just drank the kool-aid as something nice Apple did just because they're a lovely company like that.

As the security guy that runs enterprise firewalls, I tend to block the Apple's VPN/proxy stuff as proxy-avoidance by default, which creates a ton of noise in terms of denied apple proxy and doh drops, but it keeps them using my internal dns and internet that I can see when l-users happen to get themselves infected and start exfiltrating data to China. Otherwise with Apple's VPN/Proxy privacy bs, I have no ability to see or stop it, and neither do their users. Thanks for the fish Apple.

I just assume all VPN companies do this now as their real revenue stream.

I also happen to do work for Firefox's primary advertising partner, and I can tell you it brings me no comfort as a Firefox user myself.

"But slowly people started to realize what the collaboration between Mozilla and Cloudflare really means: Cloudflare gets all your DNS queries."

This is not wrong. This is correct. The article speaks correctly here.

The comment you're replying to used that quote to frame their argument that there are plenty of providers besides Cloudflare. Nobody is disputing that if you set your provider to Cloudflare your queries go to Cloudflare. This is not a reasonable rebuttal.

In 2018 how many other choices were there actually?

This article says "Last update: 2018-10-26". https://github.com/curl/curl/wiki/DNS-over-HTTPS/9e5a5acf799... shows the list as of then, which had 12 choices.

If you use Cloudflare as your provider, then yes. But the article incorrectly asserts that DoH requires you to use Cloudflare as your provider.

>The only difference between DoT and DoH is that DoT is easier to block and force fallback to totally insecure DNS. There's no reason to ever use DoT if you can use DoH. (And I don't get why the author likes it better: whoever runs the DoT server gets the exact same data that they'd get with a DoH server instead.)

Don't use shitty networks then. This is not an issue for all residential (and mobile) connections. Only corporate and other shtity configured networks are affected by this.

> Don't use shitty networks then. This is not an issue for all residential (and mobile) connections. Only corporate and other shtity configured networks are affected by this.

There are some residential and mobile connections that this is an issue for. And it's not always an option to use a network that doesn't try to do this.

Maybe 0.01%. Anyway, it's not an argument against it.