Measuring DNS-over-HTTPS performance around the world

By on 3 Feb 2022

Category: Tech matters

Tags: , , ,


Blog home

It has been a little over three years since DNS-over-HTTPS (DoH) was first introduced, and industry actors have taken numerous steps since then to roll out DoH support to the masses.

Mozilla Firefox already defaults to DoH in Firefox for clients in the United States, Google has announced a gradual rollout of DoH by default in Google Chrome, and Microsoft plans to build DoH into both the Edge browser and Windows operating system itself.

While this ever-growing adoption of DoH has prompted both academia and industry to conduct various measurements regarding the performance of DoH, most of these measurements are insufficient to answer two important questions:

  • How does DoH compare to the default DNS-over-UDP using port 53 (Do53) around the world?
  • Will the transition from Do53 to DoH affect clients in different economies and territories unequally?

Collecting DoH data is a difficult task

To address this gap, we at the University of Illinois conducted a survey using a paid HTTPS proxy service that routes traffic globally via machines located in residential networks.

While this service gave us thousands of clients to proxy our DoH requests through for measurement, the very nature of using a proxy meant the presence of several unwanted variables in our calculations. Importantly, it did not allow us to directly measure the time it took for a machine to resolve a domain using DoH — we could only note down timestamps on our machine, which ran the actual code.

Of note, the domain being resolved was under our control. We also chose a unique subdomain each time to remove the effects of caching altogether.

After careful analysis of the above-mentioned unwanted additions in our measurements, we were successfully able to extract the exact time it takes for a machine to resolve a domain name using DoH and resolve the same domain with a different subdomain using Do53. We decided to use four DoH providers for our experiments: Cloudflare, Google, NextDNS, and Quad9.

What we discovered

Here are a few very interesting things we found:

More PoPs ≠ better performance

We plotted the IP addresses of the DoH providers we received resolution requests from (we call these locations Points of Presence or PoPs). These are the locations we expect data centres or servers of a DoH provider to be present.

After careful analysis of the performance of a DoH provider and the PoPs of the same provider, we concluded that a higher number of PoPs does not necessarily mean better performance. Cloudflare had the best performance with the most PoPs. However, Google, which had significantly fewer PoPs than NextDNS, performed better than NextDNS.

World map showing DNS resolution times and Points of Presence.
Figure 1 — DNS resolution times and PoPs. We show the median (DoH10) resolution time for each economy in our dataset. PoPs we observed for each provider are shown as black stars. The greenest economy (NextDNS-Canada) has a median resolution time of 63ms, while the reddest economies have median resolution times of over 1 second. The same colour scale is consistently used across the four maps. A small number of economies and territories, most notably China, remain grey as we were unable to obtain DoH resolution data across all four public providers for them.

You’re not necessarily talking to your nearest PoP

DoH providers make the location of their PoPs publicly available. In comparing this list of PoPs from the DoH providers and those we actually got a request from, we investigated if a client was indeed talking to a PoP nearest to them. In other words, is there a PoP nearer to the client than the one the client is talking to? If there is, we calculated the potential improvement in the distance.

Even though we acknowledge that physical distance is an imperfect proxy for network distance, we found that 10% of Google clients and 26% of Cloudflare clients can be switched to a PoP that is, at least 1,000 miles closer.

Cumulative Distribution Function graph showing potential improvement in distance to recursive servers for four DNS operators.
Figure 2 — We defined ‘potential improvement’ as the difference between the distance from the client to the DoH PoP it used, and the distance from the client to the closest PoP in our dataset. Although Google has fewer PoPs than other providers, it assigns a higher percentage of clients to the closest PoP, compared to Quad9, which appear to have significant room for improvement.

Internet infrastructure investment is a determining factor when switching from Do53 to DoH

To figure out the factors that determine the performance impact suffered by an economy when switching from Do53 to DoH, we decided to use logistic and linear modelling.

After analysing the models, one thing became overwhelmingly clear: Internet infrastructure investment is one of the most determining factors. Consumers in an economy with a low GDP are twice as likely to experience a slowdown compared to consumers in an economy with a high GDP.

Another surprising thing we observed was that 8.8% of the economies studied see a decrease in latency when shifting to DoH, that is, DoH performs better than Do53 in these economies. This highlights the performance gap between economies.

How can we improve DoH for everyone?

After considering all the data we collected, we believe that users in highly impacted economies should be made aware of the performance degradation that will result after switching to DoH from Do53. Vendors should also think about making DoH ‘opt-in’ for such economies instead of the default.

We also believe that providers should ensure that clients are talking to their nearest PoP since there is still a few percent of clients that can benefit from this switch. Even though providers might not be in direct control of which PoP a client is talking to, due to Anycast and other routing mechanisms, we would still like to bring this to the providers’ attention.

To learn more about our study check out our IMC 2021 paper, Measuring DNS-over-HTTPS performance around the world.

Rishabh Chhabra is a Software Development Engineer at Amazon working in AWS S3. He completed his Master of Science in Computer Science from the University of Illinois at Urbana-Champaign where he worked on this paper.

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.


Leave a Reply

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