Since its introduction in 1987, the DNS has become one of the core components of the Internet. While it was designed to work with both TCP and UDP, DNS-over-UDP (DoUDP) has become the default option due to its low overhead. As new Resource Records were introduced, the sizes of DNS responses increased considerably. This expansion of the message body has led to truncation and IP fragmentation more often in recent years where large UDP responses make DNS an easy vector for amplifying denial-of-service attacks which can reduce the resiliency of DNS services. This paper investigates the resiliency, responsiveness, and usage of DoTCP and DoUDP over IPv4 and IPv6 for 10 widely used public DNS resolvers. The paper specifically measures the resiliency of the DNS infrastructure in the age of increasing DNS response sizes that lead to truncation and fragmentation. Our results offer key insights into the management of robust and reliable DNS network services. While DNS Flag Day 2020 recommends 1232 bytes of buffer sizes, we find out that 3/10 resolvers mainly announce very large EDNS(0) buffer sizes both from the edge as well as from the core, which potentially causes fragmentation. In reaction to large response sizes from authoritative name servers, we find that resolvers do not fall back to the usage of DoTCP in many cases, bearing the risk of fragmented responses. As the message sizes in the DNS are expected to grow further, this problem will become more urgent in the future. This paper demonstrates the key results (particularly as a consequence of the DNS Flag Day 2020) which may support network service providers make informed choices to better manage their critical DNS services.

The DNS is a key component of the Internet. Originally designed to facilitate the resolution of host names to IP addresses, its scope has continuously expanded over the years, today covering use cases such as load balancing or service discovery. While DNS was initially conceived as a rather static directory service in which resource records (RR) only change rarely, we have seen a number of use cases over the years where a DNS flavor that isn't purely based upon requesting and caching RRs, but rather on an active distribution of updates for all resolvers that showed interest in the respective records in the past, would be preferable. In this paper, we thus explore a publish-subscribe variant of DNS based on the Media-over-QUIC architecture, where we devise a strawman system and protocol proposal to enable pushing RR updates. We provide a prototype implementation, finding that DNS can benefit from a publish-subscribe variant: next to limiting update traffic, it can considerably reduce the time it takes for a resolver to receive the latest version of a record, thereby supporting use cases such as load balancing in content distribution networks. The publish-subscribe architecture also brings new challenges to the DNS, including a higher overhead for endpoints due to additional state management, and increased query latencies on first lookup, due to session establishment latencies.

Internet congestion management is once again undergoing radical change: QUIC has ignited a cambrian explosion in congestion control (CC) implementations while the many versions of BBR alone have increased the diversity in algorithms used with TCP, both making the congestion landscape more complex. At the same time, the interplay of CC and AQM is also evolving but congestion unresponsiveness remains a threat. In particular, L4S crucially requires a fine-grained CC and AQM interaction to provide its benefits and suffers from unresponsive traffic. Overall, we need more responsive traffic on the Internet as well as mechanisms that can cope with unresponsiveness. We present Congestion-Responsive Queuing (CRQ), our L4S-inspired system which is designed to promote responsive CC, manage unresponsive traffic, and handle QUIC and TCP flows alike. Similar to L4S, CRQ uses two queues for flow isolation. Yet, in contrast to L4S, we isolate flows based on their actual congestion responsiveness, moving responsive flows to one queue and leaving the remaining flows in the other. Our evaluation with an eBPF prototype highlights the efficacy of our design and shows that CRQ can provide effective incentives for responsive CC.

Every Web session involves a DNS resolution. While, in the last decade, we witnessed a promising trend towards an encrypted Web in general, DNS encryption has only recently gained traction with the standardisation of DNS over TLS (DoT) and DNS over HTTPS (DoH). Meanwhile, the rapid rise of QUIC deployment has now opened up an exciting opportunity to utilise the same protocol to not only encrypt Web communications, but also DNS. In this paper, we evaluate this benefit of using QUIC to coalesce name resolution via DNS over QUIC (DoQ), and Web content delivery via HTTP/3 (H3) with 0-RTT. We compare this scenario using several possible combinations where H3 is used in conjunction with DoH and DoQ, as well as the unencrypted DNS over UDP (DoUDP). We observe, that when using H3 1-RTT, page load times with DoH can get inflated by >30% over fixed-line and by >50% over mobile when compared to unencrypted DNS with DoUDP. However, this cost of encryption can be drastically reduced when encrypted connections are coalesced (DoQ + H3 0-RTT), thereby reducing the page load times by 1/3 over fixed-line and 1/2 over mobile, overall making connection coalescing with QUIC the best option for encrypted communication on the Internet.

TCP and QUIC can both leverage ECN to avoid congestion loss and its retransmission overhead. However, both protocols require support of their remote endpoints and it took two decades since the initial standardization of ECN for TCP to reach 80% ECN support and more in the wild. In contrast, the QUIC standard mandates ECN support, but there are notable ambiguities that make it unclear if and how ECN can actually be used with QUIC on the Internet. Hence, in this paper, we analyze ECN support with QUIC in the wild: We conduct repeated measurements on more than 180 M domains to identify HTTP/3 websites and analyze the underlying QUIC connections w.r.t. ECN support. We only find 20% of QUIC hosts, providing 6% of HTTP/3 websites, to mirror client ECN codepoints. Yet, mirroring ECN is only half of what is required for ECN with QUIC, as QUIC validates mirrored ECN codepoints to detect network impairments: We observe that less than 2% of QUIC hosts, providing less than 0.3% of HTTP/3 websites, pass this validation. We identify possible root causes in content providers not supporting ECN via QUIC and network impairments hindering ECN. We thus also characterize ECN with QUIC distributedly to traverse other paths and discuss our results w.r.t. QUIC and ECN innovations beyond 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.