This article is totally wrong. I'm not sure how it got so much traction. Details:
> 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.
> 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.
> 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.
> 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!
> 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.
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.
>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.
I think one way or another you will have to trust some entity with your DNS. Unless you are willing to use tor all the way on OS level. Even running your own recursive DNS resolver will leak your IP to root servers. Put VPN in front of it and know you trust this VPN company (kudos Mullvad).
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.
True, but at the end of the post the author also explicitly rejects the idea of the DoH protocol in general on questionable technical grounds, so clearly their objection isn't just Cloudflare. I think the argument would be a lot clearer if they didn't conflate "using Cloudflare for your DNS" with "using the DoH protocol for DNS" even if they think both of them are bad.
> I think one way or another you will have to trust some entity with your DNS. Unless you are willing to use tor all the way on OS level. Even running your own recursive DNS resolver will leak your IP to root servers
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.
I think, though, for the purposes of this argument you can lump the TLD and root servers together. Lot of people are going to know who you are and what you're looking up if you run your own recursive resolver directly against the root servers
I tried configuring Mullvad DNS on Firefox (last year) with DoH/DoT and it would randomly flake out and not resolve some domains (different ones each time) and the only way to fix it was restarting the browser. Cloudflare at least Just Works (tm)
The Tor daemon exposes DNS resolvers if you enable them in torrc.
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 issue isn't trusting DNS. It's trusting my local network. DNS is unecrypted UDP traffic. There are less than 65,535 ports that my machine can use to originate that request.
The problem with the protocol is poisoning not authority.
its funny you call out Mullvad in this specific case because its the one thing i really dislike about their VPN service. It wont route DNS to the root server, or any designated server really. They redirect DNS queries to their cache indiscriminately. which actually will harm the success of setting up a recursive resolver. I get this is done to prevent leaks, i would just like the option to opt out of it. been customer for many years now though. I use unbound semi recursively resolving using a forwarder with DNS over TLS. So Mullvad is not burdened with what i resolve and the forwarder not with information on who.
Not really. If motivated, building a bespoke DNS for personal (or whatever) use is easy these days. The hard part is the infrastructure to make it reliable and maintainable.
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?
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
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.
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.
> 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.
>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.
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).
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.
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.
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.
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.
DoH does wonders against ISPs which filter DNS traffic (including traffic to third-party DNS servers). This happens more often than many people realize. My ISP blocks traffic to a couple of random websites (perfectly safe and legal) just because their security system doesn't like them, and they can't do anything about that. I only wish for more websites to deploy ECH, because they are using SNI filtering as well.
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.
The disadvantage of those methods is that they require installing custom software, and they don't work on mobile devices unless you put them behind a router with custom firmware. In contrast, DoH works out of the box on most operating systems, and hopefully ECH will work as well.
I guess it depends on the situation then. My ISP doesn't pull such stunts and if they did, I would switch them in a moment. Fortunately others around here don't suck either. Cloudflare (or Google, or whoever) OTOH gets waaaay too much data from everybody. For my taste at least.
I'm glad your ISP doesn't do that, but there are a lot of people not as lucky as you, and we shouldn't deny them all a major increase in privacy just to avoid having you to change one browser setting.
Same goes for if you have an IoT device behind a corporate firewall and you are being forced to use a enterprise DNS server running on some Cisco or Juniper device which doesn't respect TTL's, filters TXT records, etc.
I find it problematic that this article recommends disabling DoH, which leaves users with unencrypted DNS — still centralized (e.g. to Google’s 8.8.8.8 or an ISP) and now vulnerable to man-in-the-middle attacks. Replacing one form of centralization with another while giving up encryption doesn’t improve privacy — it worsens it.
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.
If you're looking to implement encrypted DNS with multiple servers or providers, consider using unbound, which supports TLS resolvers and can operate in recursive mode. Alternatively, you might opt for AdGuard DNSProxy or dnscrypt-proxy, both of which support DNS over HTTPS (DoH), DNS over TLS (DoT), and DNSCrypt. You can run these tools on your local network or computer and configure your resolve.conf to point to them.
DoT is strictly worse than DoH. It doesn't actually fix any of the author's issues with DoH, and it has the gigantic downside that it's trivial for hostile networks to block.
> My ISP is bound by robust privacy, telecommunications interception and other legislation.
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).
The most important part of DoH, etc is that it allows you to make a choice. You can choose a vendor in your country. As a Canadian, I might want to use the service offered by my national TLD operator https://www.cira.ca/en/canadian-shield/configure/firefox/
Many ISPs explicitly sell DNS data, and are also advertising vendors.
In addition, your ISP can also extract whichever metadata it wants from your communications, incl. a very likely perfect guess of the hostnames you visit at which times _even if you don't use DNS at all_, just by looking at IP traffic metadata such as addresses and packet sizes.
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.
No it's not. I'm saying don't let the perfect be the enemy of the good.
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.
In the Politician's Fallacy, the chosen solution doesn't solve the problem. In this example, DoH solves many of the problems, perhaps not optimally, but better than the "do nothing" choice.
I concur and generally advise against using large corporate DNS providers. Instead, consider setting up your own DNS infrastructure, such as your own recursive servers, or opt for a trustworthy DNS provider like Freifunk or CCC, rather than Google, Cloudflare, or Quad9.
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.
I also run my own recursive DNS server on a VPS I rent, but I freely share it with other users of the Internet. This causes my "personal" signal of queries to authoritative servers to effectively disappear, and I also (marginally) benefit from caching effects of other users' lookups.
I haven't taken this step yet, but I have considered it. Could you recommend whether I should share the service on a list such as dnscrypt.info/public-servers?
His proposed alternative, DoT, still has one known peeper, and is easier to block. DoH, OTOH, looks like regular HTTPS traffic and is on port 443.
So the "abuse" of HTTP is not unnecessary, you get something in return.
In some situations, DoT is fine. In others, it won't work, but DoH will.
Even ignoring the question of the technical merits of DoT vs DoH, the way the author transitioned from "Cloudflare bad" to talking about DoT made no sense since DoT as an alternative does not solve the problems raised earlier in the post. Is the author opposed to DoH as a protocol or opposed to sending DNS requests to a company they don't like?
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.
Readit News
> 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.
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.
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!
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.
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.
Deleted Comment
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.
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.
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?
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...
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.
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.
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.
The problem is that with DoH the applications themselves have their own resolver built in that doesn't respect the system defaults.
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).
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.
Android supports limited, preset DOH resolvers only.
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.
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.
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.
> 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.
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).
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 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.
They know your government id when you subscribe to their service.
CloudFlare, otoh, never have your identity. They only have the metadata
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...
CF issues are dealt with “hope to get a post on HN trending”.
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.
We must do something. This is something. Therefore, we must do this.
Deleted Comment
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.
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.