Recently there have been a couple bits of new on the DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) front. Comcast and Mozilla have struck a deal to provide a privacy oriented DoH service for Comcast users in the USA. Apple announced at WWDC 2020 that they are implementing both DoH and DoT on their iOS/iPadOS platforms with iOS/iPadOS 14.
So I feel that it is a good time to talk about the trust models inherent to the DNS query system for residential internet users and where DoH/DoT come in.
DNS queries as we know them
Let’s start with the current models that are the reality for the vast majority of internet users.
DNS query from a device -> Your ISP’s DNS resolvers – In this case, the point of trust for getting valid DNS responses belongs to your ISP entirely.
Another common model if you might not trust your ISP:
DNS query from a device -> Large Public Resolver Service – In this case, we have the large public resolver service to account for, this is usually a provider like Google or Cloudflare. But even if your queries are being handled by someone else, your ISP is still involved in the transport of said queries. If you do not trust your ISP to provide proper DNS service you may also expect them to also run Man in The Middle (MITM) attacks on your DNS queries and potentially intercept them and modify them to their desires.
This would be because in both of the above scenarios the DNS query being sent is not sent in an encrypted transport. That is, it is plain text on the wire and it is trivial to intercept and modify such traffic, especially for the ISP. You can even test this yourself if you care to install a tool like Wireshark and inspect your computer’s traffic for DNS queries; you’ll find it quite informative.
This is where DoT or DoH come in. Both of these protocols encrypt the transport for the DNS query. DNS-over-TLS uses Transport Layer Security (TLS) and DNS-over-HTTPS puts DNS queries inside a HTTPS request which means that a DNS query made using DoH looks like bog standard HTTPS traffic to anything sniffing the wire.
So let’s break down the scenarios again, this time accounting for DoH/DoT.
DoH/DoT query from a device -> Your ISP’s DoT/DoH resolvers. In this case, the point of trust still remains within the ISP and using DoT/DoH doesn’t realistically add any particular benefit if you trust your ISP.
DoH/DoT query from a device -> Large Public DoT/DoH resolver. This is usually a large public resolver like Cloudflare or NextDNS. In this case, if you do not trust your ISP, your DNS queries’ transport is protected from MITM attacks by your ISP.
Let’s talk about that second scenario. In this you have moved your point of trust from your ISP to a third party like Cloudflare. In fact, this is what Mozilla is doing for US Firefox users. So the question in this case is: do you trust Cloudflare more than your ISP? For Americans, the majority opinion appears to be yes. In addition to that Cloudflare is bound by a certain set of privacy oriented policies that theoretically prevent from being malicious with your DNS query data (including selling the data to others).
I say theoretically because I have my doubts on how strongly Mozilla can enforce such a policy on their partners and who has the leverage in such a relationship. In case of the Mozilla-Comcast relationship I have severe doubts about how much follow through we are going to see from Comcast.
Do /I/ trust Cloudflare more than my ISP? Not particularly. Cloudflare is an American corporation and is therefore bound by the vagaries of American law. As a non-American, I don’t think my DNS queries being sent to a American company is good for my privacy regardless if the transport of the query is encrypted or not.
So, to sum up – whoever your DoH/DoT endpoint is, they now have your DNS query which is still valuable to them because they can potentially sell it to other parties for profiling. The certificate authority system is also a point of trust you have to consider and if history has taught us anything the CA system is a shitshow.
The transport encryption that DoH/DoT provides is still useful in the cases of MITM and especially in what I call the “malicious coffee shop wi-fi” situation i.e a local network where you do not know what other devices are there potentially snooping. But remember this: your ISP may not be your friend but that other corporation you gave your DNS queries to isn’t either.