Why not use DNS over HTTPS (DoH)?
bsdhowto.ch
bsdhowto.ch
> But slowly people started to realize what the collaboration between Mozilla and Cloudflare really means: Cloudflare gets all your DNS queries.
There are a lot of DoH providers other than Cloudflare. https://github.com/curl/curl/wiki/DNS-over-HTTPS lists several. If you don't want Cloudflare seeing your DNS requests, then use one of them instead. (And even for users who do just stick with the default, I think it's better privacy-wise for Cloudflare to see that data than for the average American ISP to.)
> Yes, there is. It is called DNS over TLS and is specified as a proposed standard in RFC 7858. This provides transport encryption to DNS without abusing HTTP as transport protocol.
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.)
> No, it is not. Abusing HTTP as a transport protocol for DNS data adds a unneeded complexity to the protocol. You must add a HTTP module to all DNS servers or interact with a separated HTTP server on the same system in order to support DoH. That is a lot of code which can contain a lot of bugs and security flaws. Complexity is the enemy of security.
The extra complexity of HTTP is massively outweighed by the significant reduction in fallbacks to insecure DNS.
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.
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!
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.
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.
And we'll yet see about that law. Right to repair is pretty popular.
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.
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.
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.
> 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 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.
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.)
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.
> 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.
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.
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.
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.
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.
How does that tell them anything when there are many legitimate client devices using someone else's DNS servers?
Only a very small minority will be able to run their own DNS server I assume.
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.
This is not wrong. This is correct. The article speaks correctly here.
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.
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.
And abusing https is for a good reasons. Blocking ports 53 and 853 is easy and many ISPs will do that.
The author also make it feel like the only option is to use cloudflare DoH on Firefox while that's the first option, there is also nextdns and custom field. There are many providers I would trust more like quad9 and Mullvad DoH.
I think the reasons why not to use DoH is the same for why not using public dns from providers you don't trust anyway.
Most of the people are happily using 8.8.8.8 and handing all their dns information to the biggest advertisement company in the world. Or wosre, using their ISP provided DNS.
In fairness, the date on the post is 2018 - when Firefox first launched this, Cloudflare was the only option
With modern recursive DNS, you don't leak much to the root servers, just the tld you're trying to resolve. And you can axfr the root zone and then the root servers only know you're a resolver. The TLD servers know a lot, by necessity, though.
If you include the TLD as part of "Lot of people are going to know who you are and what you're looking up", ignoring any mitigating effect of Query Name Minimisation, the number of people is identical to any other setup.
For ISP resolver it will be the ISP and the owner of the domain name through web logs.
For public DNS resolver it will be the public resolver and owner of the domain through web logs.
for personal recursive resolver, it will be the TLD and the owner of the domain name through dns and web logs. The TLD job in this case is to give you the authoritative name servers of the domain name that the owner of the domain has.
With Query Name Minimisation, the TLD only get the domain name without any subdomains. They can't see the distinction between a user reading hacker news, or a user going to the main page of ycombinator to read about YC invests.
You'd of course be trusting Tor nodes for your DNS at that point, as I believe the network pulls records from exit nodes' resolvers, but you sidestep the quandary of deciding who you trust to directly make requests to.
You can also have multiple resolvers in the same daemon that use their own circuits, reducing the chances of receiving forged DNS records from potentially malicious exit nodes.
Similarly, DoH and DoT work over Tor.
You don't have to use it at a system level, just point your DNS clients at the daemon.
The problem with the protocol is poisoning not authority.
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?
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.
I would very much like to see that same freedom to innovate when using other protocols.
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.
The problem is that with DoH the applications themselves have their own resolver built in that doesn't respect the system defaults.
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.
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?
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
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.
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.
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.
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.
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.
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
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).
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/
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.
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.
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.
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.
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.
Android supports limited, preset DOH resolvers only.
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.
https://groups.csail.mit.edu/ana/Publications/PubPDFs/Archit...
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...
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).
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.
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...
I think the network as a chokepoint will slowly go away due to improvements in cryptography, and we'll need the endpoint to do all the inspection and enforcement.
That's exactly what I want, because any solution other than that one would allow network operators to snoop on other people's endpoints.
If your OS doesn't trust a MitM box, it yells.
DoH is simply HTTPS traffic as far as a firewall is concerned so how are you going to block or decrypt it?
If you take it a step further and you are running a DoH server on the same place where the API endpoints (REST, gRPC or whatever) for your IoT device are running no one is going to see the anything but HTTPS traffic
This is surprisingly easy to beat using very funny methods, like splitting the request in the middle of SNI, or sending a request with a low TTL to an unblocked website first which gets dropped then repeating it to the correct SNI.
There are more methods all of which I find very funny for some reason. You can use GoodbyeDPI on Windows and zapret on Linux.
Instead of sending all my DNS traffic to sketchy multinational corporation A, we'll send all my traffic to sketchy multinational corporation B?
Doesn't seem like much of an increase in privacy to me.
I'm now with a different ISP, and anyway have PiHole handling DNS queries on most devices in our house. It forwards DNS requests to dnscrypt-proxy running on the same Pi, which uses Quad9 over DoH.
If the goal is to reduce centralization, a better approach would be to use encrypted DNS (DoH or DoT) with resolver rotation or randomization. That way, users retain privacy from local networks and ISPs without concentrating all DNS traffic in a single provider’s hands.
You’ll only be vulnerable to a MitM attack if your system’s resolver is insecure and also vulnerable to a MitM attack.
(I have weirdly strong and specific ideas about DNS security.)
> Cloudflare gets all your DNS queries.
That's true, but Cloudflare is more trustworthy than my ISP, and probably most people's ISPs.
> Complexity is the enemy of security.
That's true, but that's no reason to go from an imperfect solution to a nonsolution.
> there is DNS over TLS
That doesn't solve most of the issues that the author brought up.
> How does a modern company in the IT business earn money? By selling data.
Maybe I'm naive, but I thought they made money by using all the data they collect for better threat prevention, and from their paid services.
Based on what?
The bar is real low, mostly for the fact that ISPs are mandated by law in most if not all countries to track traffic flowing through their pipes.
Cloudflare provides relatively better privacy guarantees for the public DNS resolvers it runs: https://developers.cloudflare.com/1.1.1.1/privacy/cloudflare...
If you live in a rural area where people are co-operative, there might be a community owned fibre operator plus Opeanreach, otherwise just Openreach.
If you live somewhere very silly, like up a mountain or on your own island, your only practical option will be paying Openreach to do the work.
Edited to add, Notably: Only Openreach is usable by an arbitrary service provider. So if you want to pick your service provider separately, the actual last mile delivery will always be Openreach. And if they're small it won't just be last mile, Openreach also sell backhaul to get your data from some distant city to the place where the ISP's hardware is, you're buying only the, like, actual service. Which is important - mine means no censorship, excellent live support and competent people running everything, but the copper under the ground is not something they're responsible for (though they are better than most at kicking Openreach when it needs kicking)
In the UK there are even aggregators like Fibre Café [1] that makes it easier for ISP's to connect through multiple networks.
You're next argument might be "but how do you know the server is really using ODNS?" You don't. If your security threat profile doesn't allow for this, whatever you're doing shouldn't be using a public internet network anyway.
CF issues are dealt with “hope to get a post on HN trending”.
Cloudflare, on the other hand is based in a foreign jurisdiction that offers none of these protections.
It really depends on which jurisdiction are you in, unfortunately. US ISPs are selling everything they can hover (including DNS information) to advertisers, and it is impossible to switch to another one unless you're lucky (because the monopoly is essentially maintained).
Given that they are funded and run by the same forces american parastical capitalism provides I would trust them as much as I'd trust google or alphabet.
I'll continue to route my DNS to quad-nine over mullvad over my specifically chosen ISP, and everything on my network does that as I can easily intercept and redirect udp/53.
The weak point are treacherous devices which use DoH which is a constant fight to block.
Why would cloudflare, built from the same corporate background, be any more trustworthy?
Some may also consider reverse proxying/caching to be providing transit service, but I'm not sure if the majority of people would agree on that.
So you already have to trust your ISP anyway -- but there was no need to trust Cloudflare *. DoH to Cloudflare is almost certainly a net loss in privacy compared to using your ISP's DNS over clear text.
* Right until they became hosters of half of the WWW. So Cloudflare can pretty much also guess your activity even if you don't do DNS with them anyway.
Even if you use a VPN?
Big CDNs and ECH make that impossible.
If I check up right now, form the top 10 links in HN right now, it is trivial to distinguish the top-level domain from just the IPv4 or IPv6 address. Heck, even _for this website itself_ the current IPv4 reverse DNS points to ycombinator.com. I don't even need to go into packet size heuristics, or the myriad of ad networks, etc.
Sure there are some instances where you will share the IP of the CDN. This has been seen recently e.g. in the recent article of the "LaLiga" blocks in Spain. But bigger sites cannot afford for this to happen, and even smaller sites tend to have at least one paid IP address for mail (reputation is a bitch, and Cloudflare doesn't have any).
Two of the top 10 links in HN right now (https://news.ycombinator.com/item?id=44215603 and https://news.ycombinator.com/item?id=44212446) are to different subdomains of github.io that resolve to the exact same IP addresses, so reverse DNS doesn't tell you which one is being visited.
And you can't even tell the TLD, because the TLD is "io", but the reverse lookup on the IPs will give you a TLD ending in "com".
> Heck, even _for this website itself_ the current IPv4 reverse DNS points to ycombinator.com.
That's because HN isn't behind the kind of CDN I'm talking about. But a lot are. Is your argument "since your ISP can see some of the sites you're going to, we should remove all protections and let them see all sites you're going to?"
"io" and "com" are top-level domains, and in the example I gave, you can't even distinguish between them.
104.21.3.245
104.21.68.247
104.21.80.31
104.21.95.131
104.21.112.1
104.26.4.133
104.21.3.245 -- trebaol.com
104.21.80.31 -- diwank.space
104.26.4.133 -- daringfireball.net
104.21.112.1 -- simonwillison.net , taras.glek.net
In the meanwhile, from the current top #30 articles on HN (also via copilot script, but I removed non-cloudflare IPs):
ycombinator.com -- no CDN
letsbend.de -- no CDN
grepular.com -- no CDN
xania.org -- cloudfront
github.io -- no common CDN
owlposting.com -- AWS, but IPv4 remained static
netfort.gr.jp -- no CDN
simonwillison.net -- cloudflare, 104.21.112.1 fixed
folklore.org -- azure, 13.107.246.1-255 range
danq.me -- no CDN
nature.com -- fastly, IPv4 remained static
daringfireball.net -- cloudflare, 104.26.4.133
ssp.sh -- no CDN
trebaol.com -- cloudflare, 104.21.3.245
glek.net -- cloudflare, 104.21.112.1
gov.uk -- AWS, but IPV4 remained static
phys.org -- no CDN
diwank.space -- cloudflare, 104.21.80.31
free.fr -- no CDN (my French ISP, btw)
ericgardner.info -- AWS, but IPv4 remained static
ghuntley.com -- fastly, IPv4 remained static
paavo.com -- no CDN
railway.com -- cloudflare, 104.18.24.53
alloc.dev -- cloudflare , 188.114.96.2
- IPv6
- Its Geo region will actually match yours
- Routing tables
- The patience to also include resources fetched from these pages in the analysis (i.e. page X always gets its JS from Y domain which results in a constant Z KB transfer).
- The rest of your browsing activity
- The rest of everyone's browsing activity including most popular _current_ hosts for each hostname.
Do you still claim that it is "impossible" to track your activity because of CDNs? I still bet you your ISP can do it with _100%_ accuracy.
They're never going to be "1 IP ECH" . That would be the end of the Internet as we know it.
If it ever happens that the majority of the WWW is 1 CDN, we have a bigger privacy problem than DNS. Much bigger.
Many ISPs explicitly sell DNS data, and are also advertising vendors.
Cloudflare, on the other hand, doesn’t share or sell data and retains minimal data: https://developers.cloudflare.com/1.1.1.1/privacy/public-dns...
So does UDP based DNS, and TLS based DNS. It’s all the same in that regard.
Do ISPs do deep packet inspection to get lookup data? Maybe, but it increases the cost of doing so and makes the business aspect of it less viable. Perhaps a minor win.
With cleartext DNS, your queries may never reach your chosen server. Plenty of ISPs are configured to just answer any DNS query, regardless of its destination. Using a nonstandard port might help, but you’d be much better off deploying one of the DoH / DoT / DoQ / etc secure protocols.
They know your government id when you subscribe to their service.
CloudFlare, otoh, never have your identity. They only have the metadata
This is textbook politician's fallacy. Yes, it may be preferable to continue with a "non-solution" if the solution proposed is stupid enough.
DoH does solve a problem for many people. Many large ISPs will sell your DNS requests, use them for targeted advertising, tamper with responses for various reasons, etc., and so DoH is an improvement over the status quo--not for everyone, but for many users, and I'd guess most users.
You're right, DoH might not be worth adopting if it were "stupid enough", but... it's not stupid enough.
If you combine this with ECH and a good blocker, no they do not. That's exactly why Spain is blocking around 60% of the internet during football games now; the ISPs cannot tell which websites and subscribers are pirating football streams.
[citation needed for the 60% figure]
Precisely due to these blocks is why I know that Cloudflare is NOT 60% of the WWW, not yet at least. Certainly, if Cloudflare was serving 60% of the Internet, I would consider switching my DNS to them. But that would be a privacy nightmare for another day (replacing federated ISPs with a single big centralized one? great idea /s). It is not yet the case as of today.
In fact, as of today, and even if you have a "good blocker", I, a total noob, have a high chance of reliably identifying which HN news item from the top #30 you clicked from just the addresses: https://news.ycombinator.com/item?id=44219061 . Imagine what the non-noobs at your ISP could do.
We must do something. This is something. Therefore, we must do this.
The advantages of self-hosting recursive servers include complete configurability, absence of censorship, tracking, and rate limits. However, like any self-hosting solution, it requires an investment of time and money. It's also important to note that DNS lacks an authentication layer, so for access restrictions, it should be placed within a private network or VPN.
The issue of pre-configured DNS over HTTPS (DoH) in many browsers and mobile devices can be addressed through firewall rules on your router.
For creating your own DNS infrastructure, I recommend dnsdist if you have ample time, though bind and unbound are also viable options.
For the past three years, I have been running dnsdist with recursive servers on two ARM VPS instances, costing around 14 EUR per month. This setup provides me with DNS over TLS (DoT), DoH, and other features. I use them with unbound (TLS) or dnsproxy and dnscrypt-proxy across routers, servers, and other machines. For mobile devices, I utilize DoH directly.
Previously, I used bind in recursive mode without any encryption beyond SSH tunneling or VPN.
Alternatively, I can recommend ffmuc as a DNS provider.
[0]: https://en.wikipedia.org/wiki/DNS_spoofing#Cache_poisoning_a...
You can't run a public service without reflecting something, but you can endeavour to make the reflection ratio small.
A in production config looks like: https://github.com/freifunkMUC/ffmuc-salt-public/blob/main/d...
In some situations, DoT is fine. In others, it won't work, but DoH will.
If we're getting into the technical part of the discussion though, I personally don't think DoH or DoT are great protocols for DNS. Security is fine, but it's a lot of overhead for relatively small requests where latency matters. I wish DNScrypt had gained more traction as an encrypted protocol designed specifically for DNS.
Why mentioning DNS-over-TLS if you are against DNS-over-HTTPS? They have all the same "downside".
What's wrong with one less peeper (your ISP)? You _have_ to use a DNS server unless you use something fancy like dnsmasq to round-robin between multiple DNS servers (but your ISP can still see everything)
Besides, you can run your own DoH server with ease, you don't have to use Cloudflare's.
DoT is the friend of all self-hosters. Self-hosters need to control their own DNS if they want to use SSL within their LANs, within their self-hosted VPNs, and within their own self-hosted VPN subnets especially (I use Wireguard subnets a lot). Secure DNS with TLS, sure, but this control-ability, at the port level (853), is what a self-hoster needs to keep their life sane.
I'm currently using pi-hole configured to use DoT through Cloudflare.
Some of the websites just don't open without DoH.
Agree with the general claim that anything "S" could be a power grab by a single peeper. Google pushing HTTPS in Chrome comes to mind.
https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-oha...
That's genuinely awful advice.
Besides the fact that there are other DNS providers that can do DNS over HTTPS, disabling it just makes things worse. - you still fire all of your DNS requests to a single host (whether that's cloudflare or any other) - you also do it in clear text
>DoH is not about protecting your DNS queries from peepers. That is a big lie. It is about making sure only one peeper can see all of your queries.
How is this a lie? It does protect your queries from MitM. I doubt anyone ever said anything about protecting from everyone - either you keep a synced copy of the entire DNS database (or its part) locally, or send your query to someone else's computer. How else do you expect it to work?
>Refuse to use it today
"Refuse"? Why???
>Is there an alternative way? Yes, there is. It is called DNS over TLS
How does this eliminate the single peeper? You're still sending your query to someone else's computer. DoT encrypts, so it must be a good thing, right?
Run hyperlocal root, run your own dns.
His "don't move off 22 for ssh" is also just opinion. He argues "you will be found" but misses the experience of those of us running on shifted ssh is continuously validated by the visibly lower level of probes we see. He offers no mathematical analysis of how quickly a port knock sequence will be uncovered, and again dismisses it as infeasible and useless.
I've got nothing against strongly held opinions and these are his. But, form your own opinions too.
I sometimes think of putting my private servers on completely random IP addresses drawn from /64 IPv6 ranges. It should be near-impossible to find those by address scanning, unless I'm overlooking something dumb. Am I? It wouldn't surprise me.
For example suppose you put my-private-server.vanity-domain.example in DNS with an AAAA pointing to your private server - "passive DNS" service means big DNS providers will sell the answers they saw when anybody (say, yourself, on somebody else's computer) asks AAAA? my-private-server.vanity-domain.example. They don't reveal who asked, so this isn't personal information, but they do reveal what the question was and its answer.
A long time ago we used this to build target portfolios, if we're going to sell your company our product X, this is way we can see that you already have products A, B and C, but not D, E or F so we look a bit smarter coming into the sale.
Come to think of it, I could have a private DNS too. I haven't bothered with that.
In terms of privacy, they still preserve it (according to GDPR principles).
Worse than that, that post misunderstands it's own statement:
"Sure, you will see fewer attacks than before, but most of the attackers are no longer just stupid bots"
That's a *good* thing, because the move has reduced the signal to noise ratio. By getting rid of most of the crufty noise of the internet, you now know that anything hitting your logs now is more likely to be an actual threat than the poorly automated dictionary attack bots.
Moving SSH to a different port doesn't make the system much more secure (and definitely shouldn't be the only thing you do), but it does generally enable you to be more responsive.
Is there an alternative way?
Yes, there is. It is called DNS over TLS and is specified as a proposed standard in RFC 7858. This provides transport encryption to DNS without abusing HTTP as transport protocol.
because then we could use DoH for hiding our DNS requests..
DoH requests go to /dns-query so you only need that path to proxy onto your DoH handler.
Some DoH clients will also allow you to specify a custom path, so you can also obfuscate the path by configuring client and server to use /foobar instead.
But, re-using an existing site does come at the cost of generating a bunch of extra log noise (fine if it's just you, not so fine if it isn't). If you don't have some kind of auth in place, you might also find that you suddenly come under a lot of load (when I ran a public DoH service, I eventually started getting a lot of traffic from users in an authoritarian country)
For a mobile device, where ads are much more penetrating, I discovered the fantastic android option of "Private DNS". It forces ALL traffic through it. I inserted a free ad blocking DNS server which works though DoH (thank you controld) and all companies are ditched. On the desktop ublock guards the browser. Better a company to know some sites I visit than dozens to penetrate my digital life.
At the end of the day, if your problem is you don't trust the DNS provider to also be snooping, no flavor of encrypted DNS will solve it. Whoever lands the DNS query will be able to snoop whether it's TLS or DoH
Due to recent browser problems I was giving Brave a shot. It's an interesting browser, but it has DoH enabled in a way that seemingly cannot be entirely disabled. It can be frustrating to not be able to interact with a lot of services because the browser is disregarding my local policy on my system.
Plus, the last comment on that thread says that "It works fine in incognito or a fresh profile". I suspect that some kind of caching is at play here.
Also, does anyone know what's the safest option? And how to configure it for all our home devices?
It can send DNS in all devices encrypted to a public or private DNS server. It can force this by overriding client configuration if desired.
Article is a bunch of strong opinion with nothing to back them.
Why discredit the whole post by adding an irrelevant tl;dr?
But that part is wrong too. The HTTP part has a very important reason to be there: because if it weren't, middleboxes would block the traffic.
I hope they're forced to divest from Android and Chrome. It's absolute anti-consumer garbage.
DNSCurve exists and was a far better solution, but that in turn... you know cut into ISP spying as well.
Exactly. Which is why I point my Pi-Hole at my own recursive resolver.
Can my ISP see those queries? Sure. Are they using transparent proxies to redirect my queries to their resolvers? No.
Is my ISP cataloguing all my recursive resolutions? Maybe. But probably not. Theoretically, they could, but mirroring all the traffic to storage for tens of millions of customers seems exorbitant, unnecessary and wasteful.
More likely, I'd expect that at some point (likely the router interface at my local head-end), they use Netflow[0] and/or something similar, to characterize the IP-based traffic being transmitted through it. The collected data wouldn't contain the DNS queries themselves, so my ISP would need to rely on just the Netflow data.
And while it is possible for ISPs to correlate DNS queries to Netflow streams[1][2], using a recursive resolver rather than their resolver makes it more cumbersome for them (or Cloudflare, or Google, etc.) to do so.
Regardless, I'd much prefer that my recursive resolver use encrypted communications, not so much between it and the root servers, but between it and authoritative servers. The former would be nice, but depending on the encryption overhead (TLS or even just TCP connections to the root servers would require significant extra resources), likely impractical.
>DNSCurve exists and was a far better solution
Is there any recent activity WRT that protocol? I found some stuff from at least a decade ago.
The IETF's DNS Private Exchange[3] (dpriv) working group has a few interesting things, but it sure would be nice to have the DNS equivalent of smtp's 'starttls'[5] feature, perhaps ala RFC9539[4]?
Perhaps one day there will be mainstream support for that.
What I do works for my use case, but likely isn't workable for many (most?) other folks.
[0] https://en.wikipedia.org/wiki/NetFlow
[1] https://arxiv.org/pdf/2211.05682
[2] https://github.com/maganiss/FlowDNS
[3] https://datatracker.ietf.org/wg/dprive/documents/
I think the ideal solution would be if the root servers adopted encryption of some sort. But I can see why they're somewhat reluctant to do that, especially with relatively heavy protocols (compared to DNS) like DoH or DoT.
Edit: With the existence of QNAME minimization, I guess I should say that the requests to the root servers or authoritative DNS servers are unencrypted. This does at least spread out the risk a little, since other than your ISP there's probably some variation in who is actually between you and the various servers you're making requests to.
>Is there an alternative way?
What about just using different provider that you trust?
What if I trust Cloudflare more than I do trust my ISP?
DoH using HTTPS for example is a reasonable choice; it blends the DNS traffic in with HTTPS traffic, not requiring network operators to open a new port and, in fact, making it harder for network operators to stop you from being able to use it. If you are not on a hostile network then there's not much of a practical advantage of picking DoH or DoT, but the reasoning for why DoH made this choice is not unreasonable. And HTTP may be more complicated than DNS, but neither of them are really close to the complexity of TLS, and any OS is going to need at least one good implementation of both if it plans on existing on the Internet, so I'm really not sure why this seems like a good place to draw the line.
Secondly, okay sure, don't trust Cloudflare... But, on the other hand, why is it better to send your DNS requests unencrypted? i.e. why would you disable DoH entirely? One party peeping is still less than an arbitrarily large number? In practice there is an extremely good chance that even if Cloudflare acted in a maximally malicious manner, having them as your DNS provider is the least scary implication. They already have untold amounts of information about you from the fact that they're a middle man terminating TLS for a lot of the websites you visit. And while it would be nice to have private DNS that is hardened against Cloudflare or the U.S. government spying on you, this is kind of at odds with having DNS be low latency, accurate and reliable.
I think a lot of actual dislike of DoH comes from people who believe that network operators should be the ultimate controllers of their domain, but in the future we actually got most people don't even control the WiFi in their home to any meaningful extent. As much as it's hard to trust Google or Cloudflare, since you know they have bad incentives to circumnavigate the will of the user and network operators, they are in the unfortunate situation of "having a good point" with regards to DoH. I ultimately never liked Firefox's decision to roll out DoH by just automatically sending DNS requests to Cloudflare using a trust-me-bro promise; oddly enough, Chrome did a more reasonable approach, trying to use whatever your configured DNS server is, but automatically upgrading it to DoH if it was a resolver that had a known DoH endpoint.
Granted, I believe Google Chromecast devices also will attempt to use DoH to get around a Pi Hole, so obviously I'm not trying to give any undue credit here. You still can't really trust Google or Cloudflare on the whole. But, being wrong about some things doesn't mean you're also wrong about other things, and the points made in favor of DoH still do stand, especially when it is configured explicitly by the end user. (P.S.: and it's silly to really dwell on this point too much anyways. If you had a truly malicious party, they could simply not use any kind of DNS to resolve names at all, in an effort to make their traffic harder to block. Using DoH is still less obscure.)
The bottom line is though, it's not clear if you can really trust your own ISP anymore than Cloudflare, especially depending on where you live. Ultimately, it's not hard to see why Firefox made this choice.
If it's privacy, why offer DNS-over-TLS as an alternative? It has exactly the same privacy properties.
If it's security, then tl/dr and first section makes no sense.
There could be other "peepers", known or unknown, between the DoH provider and each authoritative nameserver.
Generally, with no exceptions that I am aware of, the DNS traffic between (a) the third party DNS provider/open resolver/shared cache/DoH provider, and (b) each authoritative nameserver is unencrypted.
"It is called DNS over TLS and is specified as a proposed standard in RFC 7858. This provides transport encryption to DNS without abusing HTTP as transport protocol."
Same problem as with DoH. Generally, the DNS traffic between (a) the third party DNS provider/open resolver/shared cache/DoT provider, and (b) each authoritative nameserver is unencrypted.
"The DNS needs security features that prevent the peepers from reading your DNS traffic. I'm all in for it. But DoH is NOT the answer to this."
The only working DNS encryption solution I am aware of is DNSCurve, making it is easy for authoritative nameservers to encrypt their responses.
I use DNSCurve via CurveDNS at home on the local network. Originally I was just testing it to see if and how it would break. That was over over 15 years ago. It is still working.
I have seen HN commenters with high karma try to discredit DNSCurve. Not because it doesn't work, but because it is not popular. There are few DNSCurve-protected authoritative nameservers on the internet. Meanwhile the most popular encryption that is used for HTTPS, including DoH, is from the same author as DNSCurve. Pay no mind.
As a proof of concept, I have thought about starting a DNS registry that requires registrants to offer DNSCurve-encrypted responses from their authoritative nameservers.
DoH has commercial motives. It is based on (yet) another weird Silicon Valley definition of "privacy". Nevertheless, I have managed to find good uses for it. For example, it allows for bulk DNS retrieval via HTTP/1.1 pipelining. It can also be useful when hotel-provided internet service is intercepting DNS. IMHO, DoH is an option that is useful to have. This is not to say I would rely on it.
Perhaps I'm generally OK with DoH because I do not use remote DNS. I stopped letting applications use remote DNS before DoH was introduced. I now use a forward proxy with all name-to-IP mappings stored in memory. DNS queries only travel over the loopback to own authoritative servers and generally all RRs point to the loopback address of the proxy. DoH is useful as a source of DNS data retrieved in bulk from various providers. It is not the only source I use.
Arguably the debate over DNS encryption is moot because domainnames appear in plaintext on the wire anyway, via the TLS "Server Name Indication" (SNI) extension.^1 TLS has become extremely popular. The extension mainly serves the needs of CDNs. The proposed Band-Aid for the harmful effects of SNI, put forth by the CDNs (i.e., the source of the problem), is known as "ECH". It is not popular.
ECH coverage is narrow. One might be able to use ECH with a specific browser and version and a Cloudflare website.^2 For the rest of the myriad software that use TLS, and the rest of the www not accessible via Cloudflare's CDN, including other major CDNs and millions of websites not hosted on major CDNs, all bets are off. The famous "example.com" certainly supports TLS. It does not support ECH. Neither does news.ycombinator.com
1. Test: https://github.com/kontaxis/snidump
2. Test: https://test.defo.ie
maybe there is something to be said about the complexity but they left that to the last paragraph
[0] like https://www.quad9.net