The Domain Name System (DNS) is a vital component of every networked application. Standardized in the 1980s, when many of today’s security concepts and protocols had not been developed yet, it was designed as an unencrypted and unauthenticated protocol, and as such, has since fallen behind modern expectations of protocol security.
Over the years different solutions to increase DNS security have been proposed, with DNS-over-HTTPS (DoH, RFC 8484) being the most recent and controversial. DoH essentially keeps the original DNS message with all extensions but changes the transport from UDP (or TCP) to HTTPS.
Read: Opinion: What does DoH really mean for privacy?
The huge amount of attention received by DoH has led us at Queen Mary University of London to assess the performance impact of DoH in comparison to regular DNS. Within our recent IMC paper, we looked at the ability of different transport protocols to cope with transmission delays and out-of-order transmissions, assessed the overhead in terms of additional bytes and packets incurred, and took a preliminary look at the impact of DoH on webpage load times.
Which transport protocol works best with DoH
We first looked at the different transport choices for secure DNS. We chose to compare DNS-over-TLS (DoT), DNS-over-HTTPS/1.1 with pipelining and DNS-over-HTTPS/2.0. We also compared UDP baseline performance to understand how these new transports differ from the original one.
To achieve this, we sent 100 random queries to a local DNS resolver, which we configured to always return the same IP. This setup eliminated the effects of caching and compression, allowing us to attribute any change we observed to the choice of transport protocol.
In a second step, we delayed one in 25 queries by one second to assess the resilience of the different options against slow queries.
Figure 1 depicts the results. The upper row shows the baseline performance without artificial delay. UDP, TLS and HTTP/2.0 achieve stable resolution times in the order of 1ms to 10ms, which is expected for a local host setup.
However, in the cases of TLS and HTTP/1.1, we observed that the delayed query, also delayed subsequent queries. This happens because queries are submitted sequentially over the same stateful connection.
We also noticed that the first query via TLS and HTTP/2.0 took longer. This is due to the additional overhead to establish TLS and HTTPS sessions. HTTP/1.1 also exhibited erratic behaviour, which we attributed to differences in how pipelining was implemented in HTTP/1.1. Major browser vendors, Google and Mozilla, have also witnessed this behaviour in the wild and have stopped supporting HTTP/1.1 pipelining.
The bottom row in Figure 1 shows how the different options performed in the presence of resolution delays on the DNS layer. We saw that UDP performs fairly well with only four delayed queries suffering from longer resolution times, and there is no impact on the resolution times of the remaining queries.
This is different for the UDP case where a single stateless connection, that is another port number, can easily be used for each query. It is only HTTP/2.0 (the DoH RFC mandated protocol) that in this setup provides resilience against delayed DNS queries.
It is worth highlighting that researchers have proposed different implementations for TLS to alleviate these problems. These approaches, however, re-architect the state handling for the DNS resolver to essentially provide the same functionalities that HTTP/2.0 offers.
All in all, these investigations highlight that DoH should be used with HTTP/2.0, due to the fact that in the wild, DNS queries will have different resolution times. Thus, using HTTP/2.0 should not impede the ability of the resolver to deliver answers rapidly and predictably.
DoH overheads are noticeable but don’t penalize performance
We also wanted to better understand the additional overheads incurred by changing from UDP to HTTP/2.0. To do this, we used the cloud resolvers from Google and Cloudflare.
We found that the median DoH exchange consumes about 30 times as many bytes and 15 times as many packets as compared to UDP-based DNS. Of course, these overheads can be amortized by using a persistent connection, however, with this approach the DoH exchange consumes about four times as many bytes and packets as the UDP exchange.
When looking at the individual protocol components and headers, we saw that even the TLS and TCP headers are each already the size of the whole DNS message (explaining this growth in size even for persistent connections).
Lastly, we looked at web page load times via UDP DNS and DoH. We ran experiments from Firefox again, against the cloud resolvers of Google and Cloudflare.
Our initial results revealed that the additional overhead for DoH led to longer DNS resolution times. However, these effects were very small compared to the total time to load a page.
When looking at timings for the onload event in Firefox, we observed only marginal differences between the different DNS transport protocols. This suggests that it is possible to change to the more secure DoH without incurring observable performance penalties.
This is joint work with Timm Böttger, Felix Cuadrado, Gianni Antichi, Eder Leão Fernandes, Gareth Tyson, Ignacio Castro and Steve Uhlig and is published as ‘An Empirical Study of the Performance of DNS-over-HTTPS’ in AMC IMC 2019, DOI 10.1145/3355369.3355575.
Timm Böttger is a PhD Candidate in Computer Science at Queen Mary University of London.
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.