DNS over HTTPS - Basic Necessity
Why DNS over HTTPS has already become a basic necessity, not just for privacy but for a safer Internet
A little over a month back, I tweeted this thread to address (in my opinion) misleading claims about DNS over HTTPS (DoH for short) in this article, which ideally should’ve been criticism restricted to Mozilla’s choice about the default DoH provider, but instead segued into a criticism of DoH. This article elaborates on the same thread, structured to be an independent read.
Why is DNS still unencrypted?
While traffic on the mainstream Internet has mostly shifted over to HTTPS, a critical component of how Internet works, the DNS has lagged behind significantly in adoption of encryption standards. I attribute this to two reasons:
- Unlike browsers, the DNS doesn't have a direct touch-point with the end users. So while the web browser manufacturers were able to encourage users to shift to HTTPS (various insecure prompts), there's no such direct interaction that happens between the users and the DNS. Which means that there has hardly been any nudge to shift people to more private form of DNS querying.
- DNS settings are opaque to most people, and are received automatically from their ISP. Typically, the settings sent by the ISP, involve DNS servers which are directly controlled by them. The metadata leakage that this leads to, is often a matter of direct or indirect monetization by the ISPs.
When thinking of the above, and for the remaining article, it'd be useful to think of ISPs not just in terms of your traditional at-home ISP, but also the Internet you use at a hotel, your college, a cafe, or at a conference.
Should DNS be encrypted?
This may sound like a ridiculous question in this age, but there are critics who still bring this up as a concern. Arguments vary from ease of law enforcement, to ease of network operations in schools, enterprise environments etc. Both are equally silly arguments in the sense that both try to take a controlling approach to the Internet, which is not just a very dated concept, but actively hurts the very objectives of enforcement.
Take law enforcement for example. If we were to not encrypt DNS, to make the job of LEA easier, remember that the same access is available to (and will eventually be exploited by) vested (foreign & domestic) interests. In fact, in history, there has never been a policy based asymmetric privileged access that actually works effectively in a public network. Such shortsighted approaches are not restricted to LEA alone by the way - well respected companies have been exposed having secret privileged user access ("for maintenance purposes only"). If that outraged us, so should unencrypted DNS.
Any weakening of the public network, is a weakening for everyone - this is a reality that policymakers must take into account. And I'm not even getting into the fact that a large number of DNS abuse & attacks have been linked with state actors, be it for stealing secrets, or enforcement of blocks.
Two competing standards?
Assuming that I've been able put my point across on the need for encrypted DNS, let's talk about the two proposals for the same:
- DNS over TLS (DoT) - uses TLS to encrypt the DNS traffic. Works on a different port (853), making it easy to restrict/block by administrators/ISPs/governments.
- DNS over HTTPS (DoH) - this uses the well-known HTTPS protocol to make DNS queries, and thus is more difficult to identify separately and block.
Some critics of DoH have argued that DoT was already there, so DoH is redundant. But that doesn't represent the truth. And I would like to make two points around it:
- Browser as the OS of the Internet
- Threats from gated mobile app stores
Browser as the OS of the Internet
The OS has been a great invention. It crafted a notion of common abstractions, which greatly accelerated the development of "applications". One could say, it is the accessibility enabled by the abstractions of the OS that truly democratized development of software. Just as the OS enabled the accessibility of software, it can be argued that the browser enabled the accessibility of the web (which is how most of the population uses the Internet). It made for interesting developments. Javascript, the de-facto programming language of the web, became the most popular language of all time. More programmers in the world, now program for the web than for the OS.
In that sense, browser is the new OS - the OS of the web. Which puts browser technologies in a special class. Be it isolates that mirror the "process" & isolation semantics of the OS, or WebAssembly, which is a full fledged virtual machine that can run inside a browser, or the fact that modern audio & video calls happen over WebRTC, browser technologies should be seen not just as an app, but a complete platform with well defined (and open!, more importantly) APIs, where HTTPS is the transport. In that world, DNS over HTTPS makes for a better & safer alternative than DoT - because of having a single underlying transport mechanism. In fact just a cursory read of the DoH RFC makes this quite clear:
The integration with HTTP provides a transport suitable for both existing DNS clients and native web applications seeking access to the DNS.
Threats from gated mobile app stores
It's ironical that the modern smartphone that brought the power of Internet to everyone, has become antithetic to the notion of a free and open Internet. Not only are apps increasingly strongly gated, given that majority of the users are non-technical, but the need for simplicity has also meant that settings that would earlier be overridable in a desktop OS, are now tightly controlled. DNS is one of those casualties. Both iOS and Android now support modification of DNS settings only via a VPN or some such app (when running on mobile data), which (surprise!), are gated by the keepers (Apple and Google).
Browser is the last remaining ungated mechanism in the smartphone era. Increased network controls on the apps that run atop these smartphones is to be expected (likely due to to good security reasons but then, the path to hell is paved with good intentions). All network access, except HTTPS - just because of the historical accident of how Internet evolved. The smartphone app stores cannot prevent access to HTTPS without significant repercussions. That again, is a good reason to have something like a DoH, because without it, DNS resolution gets delegated to the OS, which makes for a stronger centralisation and gatekeeping.
Critics may argue that why should a browser be allowed to have a DNS mechanism separate from the OS. Such critics would do well to look at the history. Between OS vs the browser, it is the browsers that have kept the bar much higher on protecting users. Starting from the invention of SSL, the precursor to TLS, at Netscape, to adoption of Certificate Transparency Logs. It's not like every browser is holier than thou, but browsers have definitely adhered to open protocols far better than the OS vendors.
Moving the control of DNS out of the OS, and into the applications (the browser here), becomes even more important in today's smartphone era. Particularly given the fact that the Android ecosystem is filled with players who have the ability to decide what software goes into the OS image, and have business models around data.
Encrypted DNS isn't the complete answer
This is a surprisingly common argument made against DoH - that just encrypting the first mile doesn't guarantee the privacy of the interaction. Um, ok. DoH never claimed to solve for end to end privacy. Did you stop wearing seatbelts because it doesn't provide protection against all accidents? Obviously not. Each of these tools has their place. The seatbelt needs to be there, the car needs to be built to high safety standards, the roads need to be designed for safety - everything needs to come together! That's just how it is for privacy on the Internet as well. And there's work happening along all those other legs, e.g., the work on encrypted SNI is happening in a separate (as it should be) protocol proposal
Another common concern raised is that your DoH provider may itself be relying on other DNS servers (because of how DNS is federated), and those upstream servers may not be encrypting the DNS queries. Quite right, but those upstream servers don't have your direct IP either (they have your DoH provider's IP), which means that any data that they gather doesn't violate your privacy. Hopefully, over time, the upstream providers start shifting to DoH or DoT as well.
Lastly, there could be other kinds of metadata that still jeopardises privacy, e.g. the IP address that is being used. Critics of DoH have pointed out that repressive regimes can still use this metadata to target people. And again, the point remains the same - privacy is a multi-dimensional problem. We shouldn't impede progress in one just because the others continue to remain unresolved.
It's no surprise that most of these criticisms come from companies that are directly involved in existing business models around DNS.
Adverse implications?
Over time, an ecosystem of additional value added services got created to use the power that comes with such a deep presence of DNS in the network stack. Naturally, as things shift to encrypted DNS, these get naturally impacted as well. Sometimes, critics of DoH call this out as a shortcoming, but these are easily addressable. Here are two that come to mind:
- Parental controls - there's a whole bunch of parental control apps that rely on DNS to work. The way they work is that they maintain an allow list of domains that are permitted to be resolved to respective IPs, while the others aren't - so a wikipedia.org gets resolved, but may be a 4chan.org doesn't. Such services will now need to insert themselves as a DoH provider in a browser for them to work. Given how browser settings are, that should be quite straightforward, so concerns about this seem like making a mountain of a molehill.
- Private domains in Enterprises - companies often have domains that are accessible only inside their own networks, and to enable it, they deploy DNS servers that resolve only inside the network. Deployment of DoH inside browsers means that these DNS servers are never invoked, so internal services won't resolve. This again, is easily addressed, simply by having custom DoH deployments, which as mentioned earlier, is super easy to do. More importantly, concerns about private networks need to be kept secondary to the larger, more public, Internet.
Reality is, every single time there has been a constructive movement in Internet protocols, some incumbents have had to incur changes. Take IPv6 deployments for example. As the Internet grew, we fell short in supply of the roughly 4 billion IP addresses that could be used. Rolling out IPv6 meant that every service provider had to buy new equipment to support the newer protocol - a way costlier an affair than what we're dealing with here.
Genuine concerns & protocol vs policy
None of the above means that there aren't issues, e.g. if Cloudflare is chosen as the default DoH provider on Mozilla's platform, they acquire too much data. Yes, that's a very valid concern. But we should separate the criticism of policy discussions vs protocol discussions. The protocol here is strong and good for the Internet. There would be better ways to deal with policies that lead to centralisation, and enough conversations are already happening around monopolistic behaviours in tech industry, which is great.
Open protocols are good for the Internet. That has been the biggest reason for Internet's success. DoH is an open protocol. Anyone can run a compliant implementation at home (I do). Which means that the protocol doesn't come in the way of competition.
On Internet's resilience to regulation
At a fundamental level, I feel there's a disconnect between what Internet truly is, vs how policymakers often approach it. Internet doesn't work like a regulated state, yet that hasn't prevented policymakers from attempting, say exports of certain encryption algorithms, only to realise how flawed the enforcement is going to be. Likewise, countries have tried restricting key sizes to enable better monitoring, only for those laws to be treated like a joke.
We can debate at length about why Internet doesn't fit well under traditional regulatory tools, and comparisons have been made about Internet's own cyberspace sovereignty as an extension of the Sovereign Individual. Whatever be the reason, what's certain is that we can't & shouldn't try to regulate protocols. Countries that will try to fight this will find that they've wasted time and energy, and actually crippled their progress on the fabric of the future. On the other hand, countries that accept and internalize this will be much better positioned to make economic & social progress on what is bound to be an Internet centric future.