Sigh. This is aggressively breaking normal DNS behavior (and will be an absurd hassle for a very large number of organizations, but in terms of extremely normal split-horizon and orgs with regulatory obligations to catch HTTPS traffic).
Applications should not contain their own encapsulated resolvers, let alone resolvers that default to sending all of my DNS traffic to for-profit companies that have previously experienced massive data leaks (and fun CF fact, they invited the then-CTO of Cambridge Analytica to talk at their Internet Summit event in SF last year).
I agree they shouldn't take away the "god-mode" /etc/hosts, which is only ever populated very intentionally by sysadmins and power users. If anything, that should be a flag just like the various modes of using TRR.
And finally - it's an open protocol in development, and anyone can set it up who wants to. If you don't want to use Google or Cloudflare, you don't have to. And FWIW millions of people are already using 8.8.8.8 and 1.1.1.1 and Cisco's OpenDNS as their primary resolver. That GOOG and CF are at the forefront of another increment of Internet standards should not be surprising.
Moreover, whatever promises CloudFlare and others make, they're still centralization points and therefore ripe targets for infiltration and exfiltration.
The moment browsers actually solve the privacy problem will be the moment 9/10ths of the internet goes poof and disappears along with their monetization strategies. As long as Google is viable then these are just tricks arguably doing more harm (increasing reliance on centralized vendors, increasing complexity of the software stack) than good.
they can disable it, any organization that modify /etc/hosts can also change Firefox's preferences file
In general it's not acceptable to break functionality and then demand people invent workarounds. But it's insane to demand that every organization in the world write new portable system integration software that has to take into account 100 varying things just to disable something nobody has asked for. And it's even more insane when the software in question is the underpinning of all internet access that has existed in the same form for 40 years.
And I trust Cloudflare, and more specifically Mozilla legal's ability to negotiate with Cloudflare, more than I trust approximately any ISP.
The willingness of people to put all their stock in a corporation with a promise of benign benevolence boggles my mind. I'm not particularly cynical, but I recoil at the notion that you'll now need an entire HTTP+TLS stack just to do DNS "properly", and that 99% of people will be using a single DNS provider.
EDIT: It's not even benign benevolence. I see that DOH includes server push. So now it's obvious how CloudFlare will monetize this--they're positioned to be able to push DNS updates directly to clients, reducing latencies when domain names change, particularly automated DNS topologies for load balancing, failover, etc. Reducing latencies, that is, if you're a paid CloudFlare customer.
You don't have to trust anyone, you can run a recursive resolver too. Even some home routers do that already.
Not everyone wants the thing I want. But that's different from nobody wanting it.
(However, a system-wide DNS resolver using DNS-over-HTTPS is definitely a thing I want! I've been considering writing an NSS module in Rust for it, as a way to play with writing a loadable module with tokio, to see if that even works.)
Chrome in particular has a DLL blacklist that seems to work very well in practice: in theory, a DLL blacklist can't possibly work, but in practice, DLLs don't try hard enough to hide their existence from the blacklisting code. https://www.chromium.org/Home/third-party-developers#TOC-Goo...
Two, running a proxy to move all my browsing elsewhere seems like the hack. Changing the internet's norms so normal DNS is HTTPS-based, and everything just works everywhere for everyone, seems like a stable long-term solution.
So I had a DNS server that used UDP. Now I need a DNS server and an HTTPS server that uses TCP. Now I'm encapsulating DNS in HTTPS. So now the packets are bigger and there's extra latency, increasing traffic and slowing things down. (These kind of "fixes" must be common, because I seem to notice how technology is constantly getting slower and crappier rather than the opposite)
Then there's security concerns, because you're running twice the software with greater complexity, yet it's subject to the same attack methods as everything else, meaning one exploit could impact DNS just as much as every other HTTPS service. Among these are attacks on the PKI system, which is fragile to say the least - an expired or revoked cert kills your DNS, and any CA can generate a cert (which apparently isn't hard to do using a BGP exploit) which can be used to circumvent the encryption. Since you need DNS to do anything on the net, it will be trivial to simply kill all DNS-over-HTTPS queries going over a network and force people to use a downgraded, insecure version of DNS. And you've got to handle encryption in a way that is normally for streams rather than datagrams - unnecessary for data which only really needs authenticity and integrity assurances (which is, again, already provided by DNSSEC)
Then there's reliability. You're tunneling DNS over a connection to one server. We already know this is slower, and we already know DNS is one of the factors that slows down page connections. So you had better hope that the one HTTPS endpoint you have a persistent pipelined connection to doesn't go down, or wait and wait for what you hope is an independent 3rd party's service that is also in your list of DNS-over-HTTPS resolvers to pick up the slack.
As a DNS admin, I had software that communicated with DNS servers. But now I have to rewrite everything to use DNS-over-HTTPS, because if a query fails in DNS-over-HTTPS, you have to troubleshoot the actual connection and not what you think is in DNS, or what you think DNS should be sending back to the client. So now I have to reinvent every DNS tool. And of course, for the enterprise DNS solutions that can't just magically sprout a new protocol extension, I'll need some sort of middleware software to map the DNS-over-HTTPS queries to the real DNS server.
All of this because someone wanted "privacy" of their DNS queries, and was too lazy to allow UDP packets greater than 512 bytes over their network.
DoH provides confidentiality and query integrity now, without requiring a boil-the-ocean step where every DNS administrator on the Internet signs their records.
Solving this is known as "the robustness principle," aka "internet engineering." Expecting every device in between every two points on the internet to a) work reliably and b) not make questionable decisions about packets that it can parse has never worked. Successful internet protocols, e.g. TCP and HTTPS, are those which put the least reliance on the network to behave reasonably. Unsuccessful ones, e.g. IPv6, are the ones that put the most reliance on the network to behave reasonably.
It's true that the successful ones are nowhere as pretty as the unsuccessful ones. But for most people, success is more important.
[1] https://github.com/st3fan/tinydoh [2] https://github.com/m13253/dns-over-https
To put this another way: it's a significant benefit for my random non-techie friends to be able to use this new feature plus HTTPSEverywhere. And even as a techie, I don't use a hosts file to block anything. So I'm not bothered by how Firefox chose to implement this, like most people.
That kind of thinking, really irks me.
It does bother me when Firefox introduces a feature which covers up a huge hole in TLS, and they get a large number of complaints on HN.
Mainstream users do not need most software ever made.
"0 - Off (default). use standard native resolving"
...
"5 - Explicitly off. Also off, but selected off by choice and not default."
It seems that the plan for the "0 - default" is to switch the users to other modes without the user knowing it, and to keep the behavior off the user must specifically change the option to "5."
or...
It could be prepared for when the user gets asked what they want and then Firefox can remember an explicit "no" as compared to not selection ever made.
/ Daniel (author of the blog post)
Daniel’s own decisions aren’t in question here. If he works for Mozilla he is not more powerful than the whole company.
Having “off” and “off when selected by user” but not other variants still points to the intention of the default state not remaining off. Which is not problematic. Problematic is however naming the state that will obviously be changed “off.”
That's arguably rude, but then your follow-up is exactly the type of conspiratorial bullshit he's implicitly accusing you of, so it was just foresight after all I guess.
TRR doesn't read or care about /etc/hosts
There's no way to exclude or white list specific domains"
For me, the primary advantage of HOSTS/DNS is the ability to control answers to application queries for addresses and block ads.
This seems to remove all control a user might have through controlling such lookups. Yikes.
I think DOH is useful but in a different way. For example, it is useful for retrieving bulk DNS data using RFC 2616 pipelining, alleviating dependence on piecemeal DNS lookups, thus increasing speed and privacy. Data can be stored locally and refreshed periodically, if necessary (I have been doing this witout problems for 15 years). It's also useful for retrieving data from a variety of caches, allowing answers to be compared.