Opinion: Centralized DoH is bad for privacy, in 2019 and beyond

By on 3 Oct 2019

Category: Tech matters

Tags: , , , ,

1 Comment

Blog home

Recently, Mozilla announced it would be moving Firefox DNS lookups to Cloudflare by default, for its American audience. There will be a notification about this for existing users, at which point they could choose to go back to their provider DNS. But crucially, there will be no opt-in: it is Cloudflare by default, using a technology called DNS over HTTPS (DOH).

This reignited some controversy, mostly in Europe, where meetings and panels in AmsterdamThe HagueParis and Belfast went over the pros and cons of this move, because it might well come to Europe as well.

During these discussions, I noticed that we haven’t been very analytical about what moving and encrypting DNS does for privacy. Many people appear to conflate the concepts of privacy and encryption, which are in fact very different things.

In this post, I argue that in September 2019, centralized DoH ‘by default’ is a net-negative for everyone’s privacy, and that even in later years it will not improve privacy outside of the most privacy hostile environments — where no one should rely on partial measures like DoH to stay secure.

Recapping what DoH does

DNS is currently typically provided by the operator of a network, which could be your Internet Service Provider, your phone company, your employer or your proverbially evil coffeeshop Wi-Fi.

The DNS provided this way is never encrypted. Anyone observing your network traffic can see which DNS lookups are made. A more capable person could also inject fake answers, potentially rerouting your traffic.

DoH, meanwhile, encrypts DNS queries going over the network, which means that no one between you and the DoH server can see your DNS queries or modify the DNS responses.

Crucially, in both plain DNS and DoH, the operator of the DNS server can see, sell, block and modify your DNS data. It is only the people in between that get locked out.

DNS and metadata privacy

DNS privacy matters. Moreover, in general, knowing what sites you visit matters — your traffic metadata. A complete listing of sites (and servers) contacted will reveal where you work, live, study, what your hobbies are, what equipment/devices you own, what sports teams you follow, which health care providers you frequent, what brand of car you (want to) own and, likely, your sexual preferences.

Many governments will also be very interested in who communicates with political parties or organizations they don’t like.

Restricting and choosing who can see the metadata of what sites you visit is, therefore, very worthwhile.

Metadata leaks

DNS is one of four ways in which such metadata gets transmitted in plaintext. For starters, browsers do not exclusively perform HTTPS requests. Many visits still start with a plaintext HTTP request that then redirects to HTTPS.

Secondly, TLS (which underlies HTTPS) very often has to transmit, in plaintext, the name of the site (or server) the user intends to connect to. This is true even in TLS 1.3. There is an IETF draft standard for encrypting this plaintext Server Name Indication (SNI), but it is not widely adopted and needs serious work before it can be standardized.

It is frequently and mistakenly thought that TLS 1.3 has plugged this leak, it hasn’t. To verify, try: sudo tshark -i eth0 -T fields -e ssl.handshake.extensions_server_name -Y ssl.handshake.extensions_server_name -n


Thirdly, to ensure that the certificate used for a TLS connection is valid, many browsers and TLS stacks will perform an OCSP lookup to the Certificate Authority provider. This lookup itself is also plaintext. Note that with some care, OCSP lookups can be prevented.

Finally, research has uncovered that over 95% of websites can uniquely be identified purely by the set of IP addresses they are hosted on, and these IP addresses also can’t be encrypted.

I should also note that unless special measures are taken, a whole horde of dedicated web tracking companies (like Facebook and Google) will record and monetize most of your moves online anyhow, no matter how well encrypted your connection.

Privacy before and after DoH

From the above, we see that DoH plugs only one of four (or five) avenues leaking sites visited.

But if we sum it up, pre-DoH, the following parties have access to the names of most of the sites you visit:

  1. Your own network provider.
  2. Your own government, police, intelligence services (through court orders).
  3. Anyone capable of snooping your local network.
  4. Certificate Authority providers (through OCSP).
  5. Large-scale tracking and advertising companies (Google, Facebook).

DoH in browsers is currently exclusively offered by/through American companies. So after switching to DoH, we have to add the following to our list:

  1. Cloudflare / your DoH provider.
  2. The US government, NSA, FBI, and so forth.

Because DoH does not encrypt anything that is not also present in plain text, there is nothing to remove from the list.

Based on this, it can be concluded that as it stands, using DoH to a browser-provisioned cloud provider effectively worsens your privacy position.

Note: DoH is the protocol, and it could be used to enhance privacy. Using DoH to move DNS to the cloud is a specific way of using DoH that is damaging to privacy in 2019.

DoH offers additional tracking capabilities

DoH opens up DNS to all the tracking possibilities present in HTTPS and TLS. As it stands, DNS over UDP almost always gets some free privacy by mixing all devices on a network together — an outside snooper sees a stream of queries coming from a household, a coffee shop or even an entire office building, with no way to tie a query to any specific device or user. Such mixing of queries provides an imperfect but useful modicum of privacy.

DoH, however, neatly separates each device (and even each individual application on that device) to a separate query stream. This alone is worrying, as we now have individual users’ queries, but the TLS that underlies HTTPS also typically uses TLS Resumption, which offers even further tracking capabilities.

In short, setting up an encrypted connection eats up precious CPU cycles both on the client and server. It is, therefore, possible to reuse a previously established encrypted state for subsequent connections, which saves a lot of time and processor energy.

It does, however, make it possible to track an application from IP address to IP address because this TLS Resumption session ID is effectively a cookie that uniquely tracks users across network and IP address changes.

But what about the privacy agreement?

DoH providers typically publish privacy policies in which they pledge to provide you excellent DNS service without them benefitting in any way from your data, except possibly through very abstract research, or nebulous performance benefits that might attract customers for other products.

History has shown that the overwhelming majority of providers of free services that carry interesting user data have eventually failed at keeping this promise — either by being compromised or by accidentally using the data anyhow. Apologies ensue, but trust never returns.

In addition to this hypothetical future misbehaviour, no privacy agreement stands up to a court order to hand over data in bulk. It so happens that the US legal and intelligence climate frequently does, in fact, use subpoenas and national security letters to hoover up user data. It should also be noted that specifically, US law affords far less privacy protection to ‘non-US persons’ than the already meagre protection provided to American citizens.

Also, US law extends to all servers and services operated by US companies, so ‘hosting data in Switzerland’ does not provide protection if the operator is American.

So, relying on a privacy agreement as some kind of unquestionable guarantee of privacy is not grounded in history nor in legal fact.

DNS for security

DNS itself is, oddly enough, not much of a security function in a browser. We derive secrecy and integrity from TLS, which in itself does not care about DNS. As an extreme example, a DNS provider could simply hand out as an answer to any browser query, receive TLS connections on that address and connect to the right server from there based on the SNI, and things would just work.

This would not allow any snooping (because TLS is end-to-end, and will check the certificate provided by the server hosting that name), but it does show that DNS integrity is irrelevant for browser security, as long as TLS is used faithfully (and we have no alternative to it anyhow).

DNS for adblocking, censorship, and CDN distribution

Although DNS cannot change TLS-protected data, it can surely prevent access to such data. Economies frequently use DNS as a censorship choke point because it is easy and cheap. Russia, Turkey and Indonesia use DNS extensively to block access to sites their governments do not like.

Phones and increasingly browsers do not make it easy to block advertisements. One simple way of doing so anyhow is through DNS. Sabotaging the lookups for popular ad servers is a very effective way of blocking advertising content.

Similarly, using lists of known malware associated domain names, it is very possible to cheaply block devices from accessing botnet infrastructure.

Finally, DNS can be used to optimize connectivity to streaming video caches, based on the IP address of the client computer. Several very large-scale CDNs and service providers rely on this technique to route users to the right server.

One significant change with DoH is that the choice of what to censor (or block) moves from the network operator to the browser vendor (who picks the DoH provider). If you are a privacy activist this is great, as long as you trust your browser vendor (and its government) more than your own economy.

If you want to block ads, malware, or if you need to route users to the best server, this will only be possible if the selected DoH vendor provides this service. This may not always be the case, especially if your browser or DoH vendor is also in the advertising business, or in fact, competes with other CDNs.

Service provider originated DoH

I (and many others) argue that encrypted DNS is good and that we should be doing more of it. This often gets rejected out of hand because there is no encrypted way to provision a nameserver.

When we connect to a network, in almost all cases, our devices get configured automatically with the right network settings and nameservers to use. Crucially, this autoconfiguration (be it DHCP or PPP) is not itself super-encrypted. So, although our Wi-Fi or 4G may be encrypted, the nameserver address is provided in plaintext over that connection.

This would allow a clever attacker to provision a snooping DoH server, defeating the point of DoH.

Because of this reason, browser vendors argue that they must ignore this autoconfiguration and hardcode a DoH server to use, over at a vendor they have selected on behalf of the user.

However, we should realize that the worst thing a network provider can do is inject a nameserver to learn what they could already learn from three other ways in which a browser leaks what it connects to!

DoH for oppressive regimes

It is frequently brought up that DoH is not built for privileged westerners living in economies with (perhaps deteriorating) rule of law. DoH is instead offered as a way for people living in oppressive regimes to evade censorship and scrutiny, which surely is a laudable goal.

It is often said that a little knowledge is a dangerous thing. I have no experience as a political freedom fighter, but I do have family members who have had to flee their profoundly undemocratic nation because they are members of the persecuted minority.

Some years ago I contacted them because a flaw had been found in TLS encryption that might be dangerous for them, and to my surprise, no one there cared. They had been assuming their Internet traffic was being spied upon anyhow, and it turns out, they were right.

Later they told me ‘we all use VPNs’ and I was impressed how privacy-conscious they were. ‘But no’, they told me, ‘everyone does that, because without a VPN the Internet here is too slow’; they suspected the spying machinery was generally overloaded. The VPN was for speed. It was not assumed to deliver privacy, on which point they were also proven right (most VPN providers are pretty shady).

I mention these two stories to show that our assumptions on oppressive regimes may be wildly off, and not represent the reality on the ground in China, Russia, Iran, Indonesia and Turkey. It is a lot of fun being an armchair imaginary political activist, but things are remarkably different if you actually live there.

Source: <a href="https://xkcd.com/538" target="_blank">xkcd</a>

Of course, more encryption is good if it makes the life of oppressive regimes harder. It is definitely a case of ‘we must do something, and this is something’. It is slightly (but only slightly) harder to extract the TLS SNI than it is to parse plain DNS.

But the dynamics of what will happen when people in those economies start relying on DoH for their safety are very hard to fathom. We hear that some governments have already moved beyond DNS-based blocking, something we also saw in Russia during ‘the Telegram wars’.

In this context, it is instrumental to see DoH as a ‘very partial VPN’ that only encrypts DNS packets, but leaves all other packets unmodified. And in fact, the various DoH apps for phones are implemented as VPN providers. If judged as a VPN, it does look like a terrible one full of weaknesses.

Given this, recommending DoH because it will help dissidents in dangerous economies may be a very ‘techbro’ thing to do — assuming your invention must be helpful without fully understanding the situation. Because for all we know the false sense of security is actually more harmful.

We may wonder why proponents aren’t instead recommending a full VPN as a solution instead of pushing an incomplete solution. Perhaps the creep factor of routing all your traffic through a cloud provider is too much?

DoH as an incremental step

DoH proponents often agree that DoH itself does not fix all metadata privacy leaks, but insist it is a good step. The stated goal is to be able to eventually use any network, no matter how untrusted, and browse the web in complete privacy.

Oddly enough, DoH proponents say it is fine to move everyone’s DNS to a central place in another economy, even though it currently does not provide any benefit, except sending your DNS to an additional party under control of a foreign snooping happy government.

To achieve the goal of perfect privacy on untrusted networks (without running a VPN) will require us to:

  1. Completely shut down plaintext HTTP.
  2. Use encrypted DNS.
  3. Deploy functional and downgrade-proof encrypted SNI.
  4. Disable OCSP/make OCSP stapling mandatory, or replace it with an alternative mechanism.
  5. Host everything (every last widget) on large content distribution networks that can provide generic IP addresses, which have no discoverable link to the sites they are hosting.

If and only if all these steps are completed, shutting down entire Internet industries in step 5, does DoH stand a chance to deliver actual privacy benefits.


Centralized DoH is currently a privacy net negative since anyone that could see your metadata can still see your metadata when DNS is moved to a third party. Additionally, that third party then gets a complete log per device of all DNS queries, in a way that can even be tracked across IP addresses.

Even if further privacy leaks are plugged, DoH to a third party remains, at best, a partial solution, one that should not be relied upon as a serious security layer, since it will be hard to plug everything, especially if non-CDN content providers survive.

Encrypting DNS is good, but if this could be done without involving additional parties, that would be better.

And for actual privacy on untrusted networks, nothing beats a VPN, except possibly not using hostile networks.

Adapted from orignal post which appeared on PowerDNS Technical Blog.

Bert Hubert is a software developer and founder of PowerDNS.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *