DNS over QUIC (DoQ) is currently being standardized within the DNS PRIVate Exchange IETF working group. The design goal is to provide DNS privacy with minimum latency, for which DoQ uses QUIC as the underlying transport protocol. QUIC features mandatory encryption, provides multiplexing, and improves on connection establishment time by combining the transport and encryption handshakes into a single round trip. Although encrypted DNS protocols such as DNS over TLS (DoT) and DNS over HTTPS (DoH) are already established and in use, these protocols have several shortcomings due to being based on TCP, which DoQ attempts to overcome with QUIC’s features.
Despite the current development status of DoQ, multiple experimental implementations already exist that offer DoQ support for clients and servers. Moreover, AdGuard and NextDNS already use DoQ in production systems for their DNS-based ads as well as tracker blocking services offering public DoQ resolvers.
To get a deeper understanding of the currently unfolding DoQ ecosystem and its availability on the public Internet, we at the Technical University of Munich (TUM) performed an extensive DoQ measurement study, covering 29 weeks in 2021-2022. In the study, we first determined the adoption of DoQ on resolvers worldwide, before measuring and analysing response times of DoQ in comparison to DNS over UDP (DoUDP), DNS over TCP (DoTCP), DNS over TLS (DoT), and DNS over HTTPS (DoH).
We, therefore, provide a first look at DNS over QUIC with our study, which will be presented at this year’s Passive and Active Measurement (PAM) Conference (28-30 March 2022). In this post, we present an overview of our major findings. For more details, please refer to the conference talk (see the conference program page) and the paper itself. We have also shared all measurement-related material on our GitHub repository.
Adoption
In order to identify DoQ adoption on the public Internet, we began by scanning the IPv4 address space for DoQ resolvers, using all proposed ports (UDP/784, /853, and /8853), over the course of 29 weeks, starting 5 July 2021. We then attempted to connect to the identified IP endpoints, recording the negotiated QUIC and DoQ versions in the process. For QUIC, we supported versions draft-34, draft-32, and draft-29, and started to support QUIC version 1 in week 43 of 2021. Moreover, we supported DoQ versions draft-00 to draft-06, for which we added support for new versions within two weeks of the draft release. In addition to the QUIC and DoQ versions, we additionally recorded the X.509 certificates offered by the resolvers and use their IP addresses to determine geolocations.
Figure 1 presents the DoQ-verified resolvers per week, grouped by negotiated DoQ and QUIC versions. Overall, we observe that the number of DoQ-verified resolvers rises steadily. Starting with 833 resolvers in week 27 of 2021, we see an increase by 46.1% to 1,217 verified resolvers in week 3 of 2022. After we added support for QUIC version 1 in week 43, we observe a steady usage of DoQ Draft 02/QUIC 1 (dark blue bars) until week 50, followed by a steep increase until week 1.
Analysing this observation, we find that the open source DNS server implementation AdGuard Home changed the default DoQ/QUIC pair from DoQ Draft 02/QUIC Draft 34 (orange bars) to DoQ Draft 02/QUIC 1 (dark blue bars) starting at week 51, which matches the pattern we observe; therefore, we attribute the observed increase in usage of DoQ Draft 2/QUIC 1 to this implementation.
Moreover, we find that only 430 (51.6%) of the initial 833 resolvers are still verified in week 3 of 2022. As a comparison, 96.5% of the verified DoUDP resolvers from week 27 of 2021 are still verified in week 3 of 2022. This fluctuation of DoQ reflects the development process; while DoQ is still in standardization, implementations and services change frequently and are expected to be used in experimental rather than production environments.
Next, we examine the geographical locations of the 1,217 DoQ-verified resolvers of week 3 of 2022 presented in Figure 2, with counts per continent based on an IPv4 geolocation lookup service. Notably, we observe a strong focus of resolvers operated in Asia (45.19%) and Europe (32.37%), whereas only 17.83% are operated in North America.
Response times
To study the response times of DoQ in comparison to DoUDP, DoTCP, DoT, and DoH, we developed DNSPerf, an open-source DNS measurement tool. Using DNSPerf to target all DoQ resolvers identified in week 2 of 2022, we issued response time measurements over the course of week 3 of 2022, where we found 264 resolvers, each supporting all the stated DNS protocols. The geographical distribution of these resolvers follows the distribution observed in the adoption scan: Asia dominates with 123 (46.59%) of the resolvers, followed by Europe with 83 (31.44%), and North America with 51 (19.32%). The remainder are attributed to Oceania (five resolvers, 1.89%) and Africa (two resolvers, 0.76%).
For our response time measurements, we sent every request with a new session for every protocol as a single query. Moreover, we populated the DNS cache of the resolver prior to the actual measurement itself, which ensured that the actual DNS response time measurement query was directly answered by the resolver from a cached record. For this post, we focus on the Round-Trip time (RTT) and the handshake time between client and resolver to detail our findings for the different transport protocol mechanisms leveraged by the different DNS protocols.
The RTT represents the protocol-specific RTT between our vantage point and the resolver, and we define the handshake time as the time between the moment the first packet of the session establishment is sent until the moment the (encrypted) session to the resolver is established.
Figure 3 presents the handshake time and handshake-to-RTT ratio, where the handshake-to-RTT ratio is calculated by dividing each handshake time measurement by its consecutive RTT measurement. Note that DoUDP is omitted, as it has no connection establishment. DoTCP (green line) offered the fastest handshake times over all protocols with a median of 156ms, which is expected due to DoTCP only requiring the TCP handshake (one RTT) for the establishment of the session. This is confirmed in the subplot, where we observed a handshake-to-RTT ratio of one. On the other hand, DoT (grey line) and DoH (magenta line) show almost identical handshake times, with medians of around 322ms. As both protocols require a TCP handshake plus a TLS handshake for session establishment, the handshake times should resemble three RTTs when TLS 1.2 is used, and two RTTs when TLS 1.3 is used. Analysing the negotiated TLS versions, we observe that 99.6% of DoT and 96.7% of DoH measurements use TLS 1.3, whereas the remaining ones use TLS 1.2. Looking at the handshake-to-RTT ratio, we find that DoT and DoH again overlap and converge into a long tail, roughly resembling the expected two RTTs for TLS 1.3 up until the median.
Analysing DoQ, we find an unexpected result (solid cyan line). Since QUIC combines the connection and encryption handshakes into one RTT, DoQ is expected to have the same distribution as DoTCP. However, with a median of 235ms, the DoQ handshake times observed are higher than expected, having its distribution in between the distributions of DoTCP, and DoT and DoH. Looking at the handshake-to-RTT ratio, we find that around 20% of measurements show an RTT of one, however, DoQ converges to two RTTs at the 60th percentile. So, roughly 40% of DoQ measurements require more than two RTTs, which is twice as much as expected in comparison.
We investigate this observation by analysing the qlogs of the DoQ measurements, which enable us to analyse the packet exchanges in detail. Using the qlogs, we can attribute the additional RTT to the Address Validation feature of QUIC, which is a requirement for every session to prevent traffic amplification attacks by validating that the client is able to receive packets. However, our response time measurement actually performs address validation by stating a previously received TOKEN in the INITIAL packet, which is confirmed by the analysis of the qlogs.
Despite the successful Address Validation, however, we find that resolvers still enforce the traffic amplification limit of three times the amount of data they received. Depending on the X.509 certificate issued by a resolver, its size might exceed the traffic amplification limit, which requires the client to ACK data before the resolver sends the remaining bytes. Hence, an additional RTT is required, resulting in two RTTs in total as observed in roughly 40% of DoQ measurements — two times as much as expected.
While the QUIC standard states that the traffic amplification limit is to be enforced until a client is successfully validated, we argue that our observations are most likely an unintentional effect of the QUIC implementations used by the DoQ resolvers. So, we suggest resolvers to not enforce the traffic amplification limit on already validated client addresses to optimize the performance, which would result in a reduction by one RTT during the handshake.
Conclusion
DNS over QUIC promises to improve on the established encrypted DNS protocols by leveraging the QUIC transport protocol. In this post, we detailed a slowly but steadily increasing adoption of DoQ on resolvers worldwide, where the observed week-over-week fluctuations reflect the ongoing development and standardization process with rapidly changing implementations and services.
Analysing the response times of DoQ, we showed that the DoQ handshake times fully use QUIC’s potential in around 20% of measurements. However, roughly 40% of measurements show considerably higher handshake times than expected, which traces back to the enforcement of the traffic amplification limit despite successful validation of the client’s address. While this shows still unused optimization potential, DoQ already outperforms DoT as well as DoH, making it the best choice for encrypted DNS to date.
Mike Kosek is a PhD Student at TUM, Germany. His research interests include Internet measurements in general, and transport protocol standardization, development, and deployment, in particular.
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.