Beyond DNS over HTTPS: Trustless DNS Privacy

It seems that DNS security and privacy discourse is upon us once again.

The story so far

The DNS protocol allows computers to send UDP messages to servers, called nameservers, to ask for the IP addresses associated with domain names. Which DNS servers computers make these requests to is traditionally decided based upon recommendation from the local network. When you connect to a network, your computer will in most cases use the DNS the network administrator wants you to use.

DNS is extremely old, and provides no protections against DNS lookups being man-in-the-middled, tracked, altered, etc. In modern times, we recognize that this is a problem, and a couple of proposals have emerged to address it.

DNS over TLS

The obvious solution to DNS queries being unencrypted is to just encrypt them. DNS requests could be sent over TLS instead of UDP, and everything could otherwise carry on as usual. You would use the nameservers recommended by the network, but talk to them over TLS if possible, falling back to plain old DNS otherwise.

This provides some security and privacy improvements. Computers between your computer and the DNS server can’t intercept and record or modify your DNS traffic.

DNS over HTTPS

DNS over HTTPS is a protocol that attempts to solve the same security and privacy problems as DNS over TLS, and then some. Instead of wrapping DNS queries in raw TLS, it wraps them in HTTPS, which is itself a protocol operating over TLS.

The rationale for this is that users don’t just need protection from unspecified men in the middle, they need protection from hostile network administrators. By allowing network administrators to choose what DNS servers computers on their network talk to, users can unknowingly be routed to malicious servers. There is no reason to trust the infosec cliche coffee shop Wi-Fi to have well-behaved DNS servers. Encryption doesn’t get you much if the server you’re encrypting to doesn’t behave in your interests.

Network operators can force DNS requests to always be made using their choice of servers by either MitMing requests to other servers and responding to them themselves, or by just blocking traffic on the DNS port to other servers. DNS over TLS removes the ability to do the former, but because DNS over TLS has its own port, it’s still possible to identify and block DNS over TLS traffic. DNS over HTTPS deliberately makes this impossible by mixing DNS traffic in with all other HTTPS traffic. It’s not generally feasible to block all HTTPS traffic to unknown servers.

The conflict between DNS over TLS and DNS over HTTPS comes down to some people thinking that they have the right to enforce restrictions on the people they provide a utility service to, and other people who tell them righteously to fuck off. As an anarchist, opposed to all forms of hierarchy and authority, whose life’s work is focused on defending the autonomy of technology’s end users, you can guess which side I’m on.

Mozilla and Cloudflare muddy the waters

The part of Mozilla that still cares about doing the right thing by their users rightfully took the side of DNS over HTTPS, and decided to make Firefox make DNS requests over HTTPS by default, to a trusted party, rather than depending on arbitrary networks to be trustworthy. Mozilla decided to partner with Cloudflare for this.

The problems with universally using Cloudflare-provided DNS over HTTPS are pretty stark. Mozilla’s plans would have DNS queries from all over the world, which are currently spread out through lots of independent DNS servers, all routed to a single provider based in a country with notoriously weak privacy laws and a notoriously intrusive system of mass surveillance. Cloudflare can assure us all they want that they don’t log the source IP address and requested domain name of every DNS query they process, but it is ultimately impossible to prove such a thing, because they’re still receiving the information.

People on the other end of the spectrum from the anti-privacy network administrators are understandably alarmed by this plan, and the perception of Cloudflare as the only serious DNS over HTTPS server makes these people sceptical of the whole DNS over HTTPS effort. These concerns can then be easily co-opted by the DNS over TLS crowd, despite their concerns being in complete opposition to each other.

It’s important to note here that there’s no fundamental reason there can’t be other public DNS over HTTPS servers. Indeed, one of the benefits of DNS over HTTPS is that, due to HTTPS’s underlying TLS, the need to defend against being abused to carry out amplification attacks, often cited as a reason to avoid running a public DNS server, doesn’t apply. Running a DNS over HTTPS server is in fact extremely easy. I’ve been running one myself for over a year. You can internally run a standard DNS server software, and then just run a simple program that translates public DNS over HTTPS requests into internal DNS requests to that server. I am not aware of any reason for there not being more public DNS over HTTPS servers other than nobody being interested in running them. I don’t know why Riseup, Disroot, weho.st, and other similar autonomous hosting providers don’t run them, but I suspect the muddiness the debate is at at this point puts people off DNS over HTTPS entirely. Perhaps, by clearly setting out the issues at play in this article, I can contribute something to resolving that.

Applications vs the operating system

Another concern about Firefox’s implementation of DNS over HTTPS is that it has traditionally been the job of the operating system to facilitate DNS resolution. The Firefox developers presumably feel they have no choice, because widespread availability of DNS over HTTPS at an operating system level will not happen in the near future. There’s no reason an operating system could not easily provide DNS over HTTPS, though. For the past year I’ve been using DNS over HTTPS as my system DNS resolver just fine. It’s also important to realise that if you’re unwilling in the general case to have your DNS queries sent to arbitrary servers based on the preferences of the network administrator, your web browser will have to be able to handle its own DNS in some cases anyway, to allow you to navigate captive portals, which don’t always work with custom DNS.

People concerned about application-level DNS will also make the point that you have to trust every application not to use malicious DNS servers, but I think this is missing the point. If you don’t trust an application to do this, there’s no reason for you to trust it to do anything else either, so why you’re running such software in a context where it’s critical for it to do just DNS correctly is beyond me.

Overall, I don’t think it’s important where DNS resolution happens. It would be nice for operating systems to handle DNS to reduce duplication of effort between applications, but we’re at this point because operating systems have failed to take steps to keep their users safe. And, assuming we’re talking about free software, which, especially when you’re worried about security and privacy, is the only software worth talking about, a software distribution that trusts its operating system-level DNS can modify the applications they distribute to make them use it.

A new proposal

While reducing centralization can protect against privacy concerns by creating choice in who to trust with IP address and requested domain name pairs, a better solution would be to not have to trust anybody in the first place. There is a widely used solution for being able to interacting with servers without making such interactions traceable back to you — Tor. It even has the additional benefit of hiding what servers you are connecting to from a potentially malicious network, and is extremely hard to block. A Tor connection to a DNS server would allow us to make DNS requests without worry about being identified. As a bonus, if we use Tor hidden services instead of connecting back to the clearnet through an exit node, connections are end-to-end encrypted, so there’s no need for an extra layer of TLS. Because Tor only works for TCP, not UDP, though, we do need to wrap DNS in TCP before sending it to Tor. So, I am therefore proposing DNS over TCP over Tor.

This does create a dependency on a local Tor daemon, but I think it would be reasonable in the two contexts that are the main focus of DNS security — operating systems and browsers. Both of these are large enough systems that adding a Tor daemon wouldn’t be a significant level of bloat, and it could have other benefits and make it easier to use Tor for other purposes. Indeed, Mozilla have already floated the idea of integrating Tor into Firefox. DNS traffic is low enough bandwidth that the Tor network should be able to handle a large roll-out of DNS over TCP over Tor, and Cloudflare have already shown¹ that it is possible to have reasonable performance despite the overhead of Tor, especially when the IP of the DNS server itself doesn’t need to be kept secret. Operating system and browser vendors integrating Tor in this way would also have huge benefits to the Tor community, because the presence of a running Tor daemon would no longer in itself be inherently suspicious.

With privacy concerns abated, there’s a lot less to worry about even if DNS does end up becoming centralized. Such a centralized service would provide very little advantage to the people running it, and it would be easily replaceable should it ever go away. And if people want to run other instances, large or small, that would be just as easy to do. Software vendors could choose different defaults, or randomly choose from a list, but even if they didn’t do this and all standardized on a single provider, the consequences would be minimal.

The only Tor hidden service serving DNS over TCP that I know of, is, ironically, operated by Cloudflare. But, as I’ve explained, this doesn’t really matter. So, I am considering the possibility that Spectrum, the security-focused operating system I am creating, might default to using Cloudflare DNS over TCP over Tor. If this ends up happening, I would of course be willing to also default to other reliable public DTT servers, but I would also feel no qualms about solely using Cloudflare in this way.

It’s important, of course, to remember that this is not a be-all-and-end-all solution to DNS security and privacy. Most notably, there’s no guarantee that the responses from the DNS server are legitimate. This should be addressed with DNSSEC and TLS.

Nonetheless, if other software was to adopt a similar method of resolving DNS queries, I think the internet would be much safer, and, as additional benefit, Tor would be much stronger.