An Empirical Study of the Cost of DNS-over-HTTPS
Timm Böttger, Felix Cuadrado, Gianni Antichi, Eder Leão Fernandes, Gareth Tyson, Ignacio Castro, Steve Uhlig
https://doi.org/10.1145/3355369.3355575
This research compares the cost of DNS over HTTPS (DoH) to that of its predecessor protocols, plaintext UDP DNS and DNS over TLS (DoT). DNS over HTTPS requires about four times the bytes and four times the packets of UDP-based DNS (when costs are amortized over a persistent connection) and has higher latency per query, though the actual impact on web page load times is small. DNS over HTTPS must be implemented over HTTP/2 in order to avoid head-of-line blocking delays.
The first experiment tests the performance of various ways of doing a DNS query in the absence of any network delays, running both client and server on the same host, with all computation done locally and no recursive requests. The four protocols they tested are UDP, DoT, DoH with HTTP/1.1, and DoH with HTTP/2. When the DNS server is allowed to respond as quickly as possible, both UDP and DoT provide responses in less than 1 ms; DoH with HTTP/1.1 varies between 1 and 50 ms; and DoH with HTTP/2 requires about 3 ms. In a second measurement run, the authors caused the DNS server to delay the response to 1 out of 25 queries, which uncovered notable differences (Figure 2). With UDP, only those queries whose responses the server decided to delay were actually affected. With DoT and DoH with HTTP/1.1, however, a single delayed response alse delayed the later responses (head-of-line blocking). DoH with HTTP/2, because of its stream multiplexing, was like plaintext UDP, with each delay only affecting a single query, though the baseline response time was still higher than in UDP. The authors explain that while head-of-line blocking is inherent in DoH with HTTP/1.1, it is not necessarily so in DoT; but the majority of DoT servers do not implement the out-of-order processing required to avoid head-of-line blocking.
The authors made a list of 281,414 unique domain names by fetching the web pages of an Alexa 100K list as well as their recursively included resources. They then tested re-resolving that list of names at Google and Cloudflare DNS servers, using UDP, DoH without persistent connections, and DoH with HTTP/2 persistent connections (a total of six conditions). The median query and response costs 2 packets and less than 200 bytes with UDP-based DNS. A single query and response with DoH is much more expensive: 31 packets / 7000 bytes for Google and 27 packets / 5700 bytes for Cloudflare. But most of this overhead is related to connection establishment; reusing a connection for multiple queries brings the per-query overhead down to about a factor of four for both packets and bytes. The authors further break down the overhead according to the contribution of TCP, TLS, HTTP/2 management messages, HTTP headers, and HTTP bodies.
Finally the authors use Firefox to download an Alexa 1K list under five conditions: with a local UDP DNS resolver, with a Google or Cloudflare UDP resolver, and with a Google or Cloudflare DoH resolver. While the time to resolve any single name is slower with a remote DoH server than with a remote UDP server, there is virtually no effect on page load times. The slowest page loads happened with using a local UDP resolver.
The authors also check the features and security of 10 public DoH servers from the list at the curl wiki. All the servers support at least TLS 1.2 and most of them support TLS 1.3. About half support DoT as well. All the servers appear in Certificate Transparency logs; only Google’s support DNS Certification Authority Authorization; and none require OCSP stapling.
Thanks to Timm Böttger for commenting on a draft of this post.