DNS over HTTPS ("DoH" from here on) is a protocol for performing Domain Name System resolution over secure HTTP. In theory, this is a good thing: in practise, it's a problematic solution born out of the failure of several other more sensible ideas that proceeded it. But don't take my word for it: I'm not a DNS expert, and no more an "Internet expert" than many thousands of other people: I'll include a Bibliography, and you should read up on the subject and make up your own mind. What's below is my understanding of the situation, and my opinions.
DNS originated (around 1985) - as so much of the internet did - as a totally unencrypted, unsecured way of converting a name, such as 'gilesorr.com,' into an IP address. As I write, that conversion yields '184.108.40.206' ... but the point(s) of domain name resolution are that A) you can remember the name and magically find the number, and B) the number can change and it doesn't matter so long as it's in the DNS system. The point is, it's human-friendly: we like and remember names far more easily than numbers. And this process is done over UDP rather than TCP: UDP is stateless and faster than TCP because of that statelessness.
As you might expect, a totally unsecured system like this has its issues in 2020. Man-in-the-Middle (MITM) attacks against DNS (which would allow intercepting DNS queries and redirecting people to your preferred website) are surprisingly easy - although I think if they were common, we'd be hearing more about them. Because of this, several improvements have been proposed: the ones that I think are most important when thinking about DoH are DNSSEC and DNS-over-TLS. DNSSEC was proposed 15 years ago: the idea was to sign DNS transactions so that they couldn't be spoofed. This would essentially eliminate the possibility of MITM attacks. Notice though that this proposal doesn't include encryption, only signing - so your query could still be seen by others in transit. While pretty much everyone thinks it's a good idea, after 15 years hardly anyone has bothered to implement it because it's harder than regular DNS and no one cares.
Another more recently proposed solution is DNS-over-TLS. TLS is "Transport Layer Security," which is the standard encryption used for the web. This blocks MITM attacks as well as encrypting your query in flight. This is a recent development (about two years? Wikipedia isn't very clear on the subject) and while it's available from some DNS providers, it's opt-in at the client end and very few people are opting in.
DNS over HTTPS
I'm not clear on who first proposed DoH, but Firefox does seem to be the first browser to implement it - presumably out of frustration with the failure (or perhaps "glacial pace of adoption") of the previously mentioned standards. They argue that it protects your privacy.
There are some good things about DoH, but I think they're far outweighed by the problems it causes and problems it raises.
- DoH queries look like any other encrypted request for a website, making the queries nearly invisible
- but ... right after your browser make the query, the browser immediately requests data from the website you just looked up: so a snooper can still see what websites you're going to (this is a simplification, but it applies in most circumstances)
- if you want to stop people watching where you're going, use a VPN or Tor
- my reading suggests that in practical terms, the switch from unencrypted UDP to encrypted TCP sounds slower but isn't in practise
- DoH is implemented in your browser: all (or nearly all) previous implementations of DNS have been implemented as a service at the OS level. Moving it to your browser is massively problematic:
- DNS queries that aren't in your browser (
wget, many other command line utilities ... and even other browsers that don't implement DoH) don't use the same system, so results may not match
- DoH bypasses network block lists because the queries don't follow the usual DNS request path, going through the browser to browser-specific DNS servers
- DNS queries that aren't in your browser (
- on the plus side, a friend commented "I'm personally all for making surveillance capitalism incrementally more costly to the data brokers and ad networks out there." DoH will do that: it makes snooping more costly, but by no means impossible.
- ZDNet wrote an article (see the Bibliography) that was extremely anti-DoH, almost entirely based on the fact that DoH bypasses enterprise security (and it definitely will - see "bypasses block lists" above). I get where they're coming from, but for some people that's a plus. And besides, it shouldn't be their only measuring stick.
- ask yourself: who pays for the DNS servers behind DoH? Firefox is a fairly reliable organization (now), but they now run their own DNS network, and by using DoH you rely entirely on their DNS. What are their biases?
- and Paul Vixie says (I'm paraphrasing): "Use DoT, never DoH." His view appears to be partly about enterprise architecture (see ZDNet), but also structural (which is where I really agree with him): he thinks this is the wrong place to implement DNS.
In the end, I'm looking at getting DoT working on my computer. Because Paul Vixie, but also because I was coming to the same conclusion he came to before I read what he said. And because of "bypasses network block lists:" I've implemented a lot of domain blocks (Facebook, advertising sites, some other stuff) right at my router. DoH ignores that completely.
Ever heard the expression "if you've got a hammer, everything looks like a nail?" Firefox has a web browser, so everything is an encrypted web query. A browser isn't the only tool, and it's not the best one to use in this case.
- https://blog.apnic.net/2019/11/04/dns-wars/ , particularly section "Episode 5 – Today’s DoH/DoT wars"
- https://www.addictivetips.com/ubuntu-linux-tips/get-dns-privacy-protection-on-linux-dns-over-tls/ (how to implement DoT on Fedora/Ubuntu - I haven't tried it yet, that's the next project)
- https://openwrt.org/docs/guide-user/services/dns/dot_dnsmasq_stubby (how to implement DoT on OpenWrt ... another possible next step)