The DNS is one of the most crucial parts of the Internet. Since the original DNS specifications defined UDP and TCP as the underlying transport protocols, DNS queries are inherently unencrypted, making them vulnerable to eavesdropping and on-path manipulations. Consequently, concerns about DNS privacy have gained attention in recent years, which resulted in the introduction of the encrypted protocols DNS over TLS (DoT) and DNS over HTTPS (DoH). Although these protocols address the key issues of adding privacy to the DNS, they are inherently restrained by their underlying transport protocols, which are at strife with, e.g., IP fragmentation or multi-RTT handshakes - challenges which are addressed by QUIC. As such, the recent addition of DNS over QUIC (DoQ) promises to improve upon the established DNS protocols. However, no studies focusing on DoQ, its adoption, or its response times exist to this date - a gap we close with our study. Our active measurements show a slowly but steadily increasing adoption of DoQ and reveal a high week-over-week fluctuation, which reflects the ongoing development process: As DoQ is still in standardization, implementations and services undergo rapid changes. Analyzing the response times of DoQ, we find that 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. However, DoQ already outperforms DoT as well as DoH, which makes it the best choice for encrypted DNS to date. 

/pdf/one-to-rule-them-all-a-first-look-at-dns-over-quic-24wpal8x.pdf

One to Rule them All? A First Look at DNS over QUIC

Over the last decade, Web traffic has significantly shifted towards HTTPS due to an increased awareness for privacy. However, DNS traffic is still largely unencrypted, which allows user profiles to be derived from plaintext DNS queries. While DNS over TLS (DoT) and DNS over HTTPS (DoH) address this problem by leveraging transport encryption for DNS, both protocols are constrained by the underlying transport (TCP) and encryption (TLS) protocols, requiring multiple round-trips to establish a secure connection. In contrast, QUIC combines the transport and cryptographic handshake into a single round-trip, which allows the recently standardized DNS over QUIC (DoQ) to provide DNS privacy with minimal latency. In the first study of its kind, we perform distributed DoQ measurements across multiple vantage points to evaluate the impact of DoQ on Web performance. We find that DoQ excels over DoH, leading to significant improvements with up to 10% faster loads for simple webpages. With increasing complexity of webpages, DoQ even catches up to DNS over UDP (DoUDP) as the cost of encryption amortizes: With DoQ being only ~2% slower than DoUDP, encrypted DNS becomes much more appealing for the Web.

/pdf/dns-privacy-with-speed-evaluating-dns-over-quic-and-its-12cnmaod.pdf

DNS privacy with speed?: evaluating DNS over QUIC and its impact on web performance

The Domain Name System (DNS) is one of the most crucial parts of the Internet. Although the original standard defined the usage of DNS over UDP (DoUDP) as well as DNS over TCP (DoTCP), UDP has become the predominant protocol used in the DNS. With the introduction of new Resource Records (RRs), the sizes of DNS responses have increased considerably. Since this can lead to truncation or IP fragmentation, the fallback to DoTCP as required by the standard ensures successful DNS responses by overcoming the size limitations of DoUDP. However, the effects of the usage of DoTCP by stub resolvers are not extensively studied to this date. We close this gap by presenting a view at DoTCP from the Edge, issuing 12.1M DNS requests from 2,500 probes toward Public as well as Probe DNS recursive resolvers. In our measurement study, we observe that DoTCP is generally slower than DoUDP, where the relative increase in Response Time is less than 37% for most resolvers. While optimizations to DoTCP can be leveraged to further reduce the response times, we show that support on Public resolvers is still missing, hence leaving room for optimizations in the future. Moreover, we also find that Public resolvers generally have comparable reliability for DoTCP and DoUDP. However, Probe resolvers show a significantly different behavior: DoTCP queries targeting Probe resolvers fail in 3 out of 4 cases, and, therefore, do not comply with the standard. This problem will only aggravate in the future: As DNS response sizes will continue to grow, the need for DoTCP will solidify.

/pdf/measuring-dns-over-tcp-in-the-era-of-increasing-dns-response-2nhcaq42.pdf

Measuring DNS over TCP in the era of increasing DNS response sizes

In this paper, we revisit the performance of the QUIC connection setup and relate the design choices for fast and secure connections to common Web deployments. We analyze over 1M Web domains with 272k QUIC-enabled services and find two worrying results. First, current practices of creating, providing, and fetching Web certificates undermine reduced round trip times during the connection setup since sizes of 35% of server certificates exceed the amplification limit. Second, non-standard server implementations lead to larger amplification factors than QUIC permits, which increase even further in IP spoofing scenarios. We present guidance for all involved stakeholders to improve the situation.

/pdf/on-the-interplay-between-tls-certificates-and-quic-lcdgx7w3.pdf

On the interplay between TLS certificates and QUIC performance

Single-Board Computers (SBCs) are increasingly used in applications by scientists and hobbyists due to their versatility, affordable prices, reduced energy consumption, small size, and the support of an increasing community. Several manufacturers are now proposing them, but the SBCs of the Raspberry Pi Foundation have been by far more successful. In this paper, an empirical study of the network capabilities of several Raspberry Pi (RPi) models (RPi Zero W, RPi Zero 2 W, RPi 3 Model B, RPi 3 Model B+, and RPi 4 Model B) is done. The performance evaluation is based on benchmarks and several metrics are reported, such as the TCP and UDP throughput, the TCP and UDP round-trip time, and the performance achieved when transferring files with SSH. In the experiments, a number of parameters are varied, including the network technology (WiFi in the 2.4 GHz band, WiFi in the 5 GHz band, and Ethernet), the network protocol (IPv4 and IPv6), and the TCP and UDP payload. According to the experiments done in this paper, IPv4 has a better performance than IPv6. However, the differences between the two network protocols are slight for most experiments. At the level of Ethernet, the variations in performance among the different Raspberry Pi models are noticeable, where the RPi Zero W has the poorest performance, while the RPi 4 Model B shows the best performance.

Network performance evaluation of several raspberry Pi models for IPv4 and IPv6

In recent years, the open source operating system OpenWrt has become a popular option for replacing proprietary firmware on networking devices such as home routers or access points. In order to configure an OpenWrt system, like setting up firewall rules, the user has to either sign in to the web interface or use SSH to manually change configuration files on the device. While the current approach is sufficient for small home networks, it only allows for limited automation of management tasks and configuration management becomes time-consuming, for example, on larger campus networks where access control lists on OpenWrt access points need updates regularly.This paper describes our efforts to implement the RESTCONF configuration management protocol standardized by the IETF on OpenWrt systems that have limited CPU and memory resources. We detail our design choices that make our implementation resource efficient for the use cases we target and we compare our implementation against other similar solutions. Our implementation is available on GitHub under an open source license1.

A Resource Efficient Implementation of the RESTCONF Protocol for OpenWrt Systems

. The DNS is one of the most crucial parts of the Internet. Since the original DNS speciﬁcations deﬁned UDP and TCP as the underlying transport protocols, DNS queries are inherently unencrypted, making them vulnerable to eavesdropping and on-path manipulations. Consequently, concerns about DNS privacy have gained attention in recent years, which resulted in the introduction of the encrypted protocols DNS over TLS (DoT) and DNS over HTTPS (DoH). Although these protocols address the key issues of adding privacy to the DNS, they are inherently restrained by their underlying transport protocols, which are at strife with, e.g., IP fragmentation or multi-RTT handshakes— challenges which are addressed by QUIC. As such, the recent addition of DNS over QUIC (DoQ) promises to improve upon the established DNS protocols. However, no studies focusing on DoQ, its adoption, or its response times exist to this date—a gap we close with our study. Our active measurements show a slowly but steadily increasing adoption of DoQ and reveal a high week-over-week ﬂuctuation, which reﬂects the ongoing development process: As DoQ is still in standardization, implementations and services undergo rapid changes. Analyzing the response times of DoQ, we ﬁnd that roughly 40% of measurements show considerably higher handshake times than expected, which traces back to the enforcement of the traﬃc ampliﬁcation limit despite successful validation of the client’s address. However, DoQ already outperforms DoT as well as DoH, which makes it the best choice for encrypted DNS to date.

Malte Granderath

Papers

One to Rule them All? A First Look at DNS over QUIC

A Resource Efficient Implementation of the RESTCONF Protocol for OpenWrt Systems

A First Look at DNS over QUIC