I don’t have a strong opinion on everything. However, in the case of DoH-vs-DoT-vs-DNS, I have a very strong opinion.
And it’s that DoH is harmful and unnecessary. In this post, I’ll explain why.
DoH (DNS-over-HTTPS) is spreading everywhere. DoT (DNS-over-TLS) is somehow behind. If you don’t know what they are, you better learn them before they bite you.
DNS is mainly a UDP-based protocol. It uses TCP when replies are too big for a UDP datagram (think DNSSEC). Also, it’s a non-encrypted non-authenticated protocol by default: everyone “in the middle” of your connection can spoof and possibly modify a DNS query/response. ISPs used this technique in the past (and today!) to collect user browsing history, block access to websites, and nasty stuff like reply with an advertising page to all missing A records. The effect of the last one is that if you type a wrong URL, you’re redirected to a page with a search engine (by the ISP itself, usually) and some ads. It also breaks a lot of stuff that relies on DNS records (for example, mail delivery).
So, how do you protect yourself / your company from this? DNSSEC is a thing; however, it does not protect from all kinds of attacks – two examples: it does not cover data from spoofing (DNSSEC authenticates responses, does not encrypt them), and does not protect from a MITM that strips the DNSSEC signature.
DNS-over-TLS (DoT) is part of the solution. It encapsulates DNS over a TLS connection, providing confidentiality (via encryption) and authenticity (via certificate verification). It doesn’t protect from the DNS server itself (just like TLS/HTTPS) – in other words, it doesn’t provide “trust”.
DNS-over-HTTPS (DoH) is an alternative to DoT. It defines a new DNS protocol over HTTP over TLS connection, providing confidentiality (via encryption) and authenticity (via certificate verification). It doesn’t protect from the DoH server itself. In other words, it doesn’t provide “trust”. Also, the last time I checked was not supporting everything that DNS supports (while this may be changed in the latest revisions).
Well, I can count four significant issues. Let me roll out them for you.
DoH is DNS implemented over HTTP in a TLS connection. For those who don’t know what HTTP is for, it’s the acronym for HyperText Transfer Protocol.
DNS is not hyper-text. Usually, it is plain text or integers. There is no hyperlink, no other content, nothing like that. So why do we need to wrap it in a protocol that was meant to serve other things?
HTTP is a text-based protocol. While the latest versions are now switching to a “mixed binary-text” form, it’s a fundamentally different protocol than DNS. For example, HTTP has headers, like
Accept-Language. These are entirely no-sense in DNS world. Reimplementing DNS over HTTP is a waste of resources.
This is not an issue of DoH per-se; it’s a problem with implementations and the way it’s deployed.
DoH is usually deployed with baked default servers from giant companies like Cloudflare. People don’t understand that; they don’t know that. So they’re switching from the local DNS server (which might be the provider DNS) to a DNS server which a company manages in (possibly) a foreign State.
This is a big switch in “trust”. I think it’s terrible because no one (e.g., non-IT people) is aware of this switch. No one should play with other’s people “trust”.
This might also raise the latency of DNS queries or pose some risk.
Also, I don’t think that big companies like Cloudflare, Google (or others) are more “trustable” than my ISP. YMMV
A lot of implementations come with “canaries” – i.e., a way to disable DoH remotely. Mozilla uses a canary domain, for example. This mechanism was meant to disable DoH in companies where the network admin wants PCs to use local DNS servers (think about Active Directory / Kerberos deployments).
Let’s use the Mozilla one as an example: when the browser wants to use DoH (at least for automatic deployments), it issues a plain old DNS query for the canary domain
use-application-dns.net. If the response is empty, or
NXDOMAIN, or some other errors, then DoH is disabled.
The problem is that DoH was sponsored with the following claims:
- ISPs are bad actors – they will track your activity
- ISPs will modify your request, pointing to search pages with a lot of ads
- ISPs servers are slow
If ISPs are bad actors, they can modify the canary DNS request to disable DoH.
Here comes the interesting part, at least for me.
In Italy (but I think the same applies in some other countries as well), ISPs must block some web content. Mostly, they block illegal websites (drug sales, etc.). They act at DNS level, as blocking IPv4 has a nefast impact (think about CDNs and Clouds), and blocking HTTP is a no-go as most of the traffic is encrypted today.
This is a weak protection – it takes literally zero time to override ISP DNS settings. However, it works for nearly any non-IT citizen, which is the majority.
Also, ISPs might intercept (plain-old) DNS queries to other servers and block them as well. Not very pleasant, but it can.
With DoH deployed this way, all those who don’t customize their DNS settings will automatically use a DNS server that might be (and currently is) not compliant with Italian laws without knowing it. I’m not a lawyer, but I strongly think that this is illegal.
DoH servers of Cloudflare, Quad9, and others should implement GeoIP and block all contents that local DNS is blocking. GeoIP is hard, error-prone. And these companies are outside Italy (most of the time, outside the EU), so it will be difficult to enforce anything.
First, DoT is not intended to be deployed as DoH is. DoT was planned to replace the DNS protocol without altering the DNS structure. ISPs should implement DoT and have their customers use them.
Also, DoT is plain old DNS with a TLS wrapper. It means that adapting software is lightweight and fast. No need for an HTTP parser, no need for completely different protocol implementation.
I don’t know. Maybe someone has invested a lot of money building a business and tooling around HTTP to maximize profits. Or perhaps they don’t know anything about other protocols. I really don’t know.