No idea how common this is in other countries, but my ISP doesn't sniff or sell my traffic. I've only ever heard about that on HN or Reddit, which are USA-centric. I guess it also happens in other countries, but in the EU such a thing would have to be made known to the user because it processes personal data.
Somehow, adding a Pocket button is bad but sending all visited websites to Cloudflare is good. The top two comments (and many others) on the thread about Pocket can be applied here as well if you just replace the name "Pocket" with "Cloudflare": https://news.ycombinator.com/item?id=9667809
EDIT: so for DoH you would need to speak HTTP but for DNS over TLS you only need to wrap TLS around for example by using stunnel or something.
edit: In response to your edit :)
So is the main objection to this that it breaks traditional layering then? E.g. here's a post in a thread that I found a bit helpful:
(The rest of the thread is interesting as well.)
I guess one downside with DoH is that now there's a larger incentive to break through your https in general?
I think the only benefit of DoH is that is unlikely to be blocked. Otherwise it feels more like a hack and at least i am not concerned about OSI models ;)
Actually, i tried to setup a DNS over TLS server some weeks ago but while it worked like intended i had a hard time to get reasonable response times even after somewhat serious fine tuning for the session setup (i used haproxy at server side). But this was mainly caused by the fact that systemd-resolved established a new connection for each and every request and i did not find a stub resolver that did not either.
> I think the only benefit of DoH is that is unlikely to be blocked. Otherwise it feels more like a hack and at least i am not concerned about OSI models ;)
Thanks for the response, but I'm still a little confused. If you live in the DoH stack you must stay there sure, but the same apparently applies to the DNS over TLS. What to you exactly is hacky about the DoH method if you don't care about the layering violations?
It's not the alternative. With DoH you are sending DNS queries, IP addresses, OS information and possibly even tracking cookies to Cloudflare over an encrypted channel, but Cloudflare still makes plain text queries to authoritative DNS servers from there. While your ISP's network is actually private, sometimes even encrypted, and sending plain text queries over it to its DNS servers is almost the same as having an encrypted channel. On top of that whether you use DoH to Cloudflare or not, your ISP sitll has the ability to spy on what websites you are visiting and in fact is what an ISP typically would use for that purpose anyway, not DNS data.
I think this is an interesting point. Given that quite a few people here on HN have problems with both of these "features", should OpenBSD be disabling them both on their builds?
Cloudflare discloses what data it logs and with whom they share it (APNIC gets properly anonymised data that can only be used for limited purposes iirc).
My ISP has a blanket "we share your data with selected partners as a way to better provide you with our services" (as has all my previous ISPs). When I have time I am hitting them and my bank with GDPR requests.
I can’t understand this move. Firefox should retreat from this default.
And what would be the relationship to DHCP?
EDIT: clearly shouldn't have used unexplained acronyms: DoH = DNS over HTTPS, DoT = DNS over TLS (which typically uses port 853)
DNS over TLS can be easily blocked by blocking port 853. To block DNS over HTTPS you need to block the entire HTTPS traffic.
DOH also doesn't help much with censorship: If you look at traffic patterns, you can detect and block DOH servers pretty easily: look for small queries to a constant endpoint that come just before new connections.
Your explained method is nearly impossible to implement for medium to large scale networks.
Hell, you can go even more trivial with barely any effort: for every new https connection to an unknown server, send a DNS query. If you get a response, block the IP.
HTTP adds nothing but complexity.
But what they should have done (and still could) is to have the server use SNI to determine whether it should speak HTTPS or DoT and then let the clients use DoT by providing the relevant server name.
Think DNS over TLS. Okay. You think $ip:$port is a dns connection. You send query with DoT protocol. You get answers. Bingo! It’s DNS.
If it’s DNS over HTTPS, you can’t tell. What domain(dns.quad9.net or cloudflare-dns.com or dns.google or whatever you can imagine) is it? What endpoint and method(/dns-query?url= or whatever you can imagine) is it? You can’t tell.
HTTP adds complexity. Complexity adds security.
And you still have the traffic patterns that will give you the information with sufficient confidence.
And blocking https packets with mere confidence is impossible.
So, yeah, I can serve up DOH on my own server with a custom endpoint, custom client configuration, and generate cover traffic. But that's not exactly easy. And http doesn't help: I can do that without http, something like https://github.com/yrutschle/sslh, or using SNI (which, as of TLS 1.3, is encrypted).
And merely saying something is impossible doesn't make it so. It doesn't even make it hard.
(I guess DNS over https and DNS over TLS is the same thing.)
> tls-upstream: <yes or no>
> Enabled or disable whether the upstream queries use TLS only for transport.
BTW, you can also use it on Linux.
I've always thought they are the same thing.
However you'd need a pretty complete TLS implementation in the network stack. Which I guess you also need to provide DNS over TLS.
If Google was the one offering DoH, and Otto made this change basically saying, “We don’t want all our traffic going to Google,” I think it would add perspective.
Or do you mean nothing sinister in this OpenBSD move? Well, it is kind of ironic to downgrade Firefox defaults to unencrypted DNS, since the absence of any modern & encrypted DNS on OSes was likely the only reason Mozilla felt the need for the switch in the first place. And this move doesn't seem to address this underlying issue of unsafe defaults caused by OSes like OpenBSD and thus feels a lot like some "no, shut up, everything is fine" reaction to criticism.
Also keep in mind there are different modes DoH in Firefox can operate in.  Ultimately I welcome the feature and hope we see more not-for-profit options as defaults in Firefox.
Related: With Chrome 78, Google is starting to "experiment" with ("an auto-upgrade approach" to) DNS over HTTPS (DoH) , as previously discussed  a few days ago.
There are some very notable differences from Firefox's testing, however (in particular, they will be "keeping the user’s DNS provider unchanged").
Anyone who needs some other configuration, clearly is knowledgeable enough to change the behavior.
You also then end up with each application using its own implementation, but DoH is a complex protocol (DNS+TLS+HTTP), so that's a lot of attack surface. Better to have one high-quality up-to-date implementation in the OS than dozens of applications that each get their own chance to screw it up.
It also breaks all of the usual things that make local DNS work. Your local DHCP server provides your local DNS server which includes entries for the local names with RFC1918 addresses that are only accessible on the local network. Move to DoH via some default external provider and that breaks and requires touching every application on every client to fix it.
This is not true, Firefox will fallback to your OS configured name resolver if it can't find a name. You can also set it to strict mode so it will only use DOH, but this is not the option that Firefox set by default.
It also implies that you're sending all queries for local names to an external provider when that otherwise wouldn't be happening.
I completely understand why they want to support DoH. And then Firefox users with untrustworthy DNS providers would have a solution to it which is no more complicated than a single checkbox to enable it. But what is really being gained over that, which is worth all the trouble of making it the default even for all the people whose existing DNS providers are no less trustworthy than Cloudflare and far less centralized?
Try to explain for a common person what benefits DOH brings to them, or why their DNS provider is unstrustworthy.
> [...] which is worth all the trouble of making it the default even for all the people whose existing DNS providers are no less trustworthy than Cloudflare and far less centralized?
A small number of people will actually have those "trouble" that you speak, and for most of them the case is so specific that they probably are power users that can figure out themselves.
In this particular case it seems relatively easy: have a blacklist of bad ISPs (similar to how we keep track of phishing sites) and enable it by default for those users (they already have lots of remote calls built in, such as http://detectportal.firefox.com/success.txt or the update check, which could easily check to which ISP the request comes from).
In the general case, I guess it would be something to choose on first run, which nobody wants. Perhaps there should be a flag/setting "I do want first-run questions for questionable defaults", so that I don't have to hear through the media which settings I have to change after the next update?
Or you can run your own and do your own recursive lookups.
There have been attempts at solving this through P2P DNS resolution. But, it's just hard to store all those records locally and keep them up-to-date regularly. Perhaps, we could cache and update records for the "popular" domains regularly and reach out to Cloudflare/other DoH or DoTLS providers when the tier 1 lookup fails?