DNS over QUIC (DoQ)—Working and Implementation Guide

In today’s world of digital connectivity, the Domain Name System (DNS) has a seemingly simple job of converting human-readable names to machine-readable addresses. But without it functioning correctly, you won’t be able to make online banking transactions, attend an online business meeting, or post a social media message. Unfortunately, traditional DNS implementations have struggled to meet modern security and reliability demands without compromising performance. 

This article discusses the DNS system’s evolution from the past to the future and how DNS over QUIC plays an essential role in safer, faster, and more resilient internet infrastructure.

Summary of key DNS over QUIC concepts

Concept	Description
Threats to Domain Name System	DDOS attacks, cache poisoning, and eavesdropping
Evolution of DNS security	DNS security is evolving with time to address the threats with updated standards like DNSSEC, DoT, DoH, and the latest DoQ
Need for DoQ	DoT and DoH provide privacy but incur some performance overhead, which DoQ overcomes
Advantages of DoQ	DoQ is encrypted by default and provides better reliability and improved performance than DoT and DoH
Adoption of DoQ	Standardized in 2022, it is relatively new and adopted gradually. It will take some time to be implemented across all resolvers and servers.

The evolution of the Domain Name System

IETF standardized the Domain Name System over three decades ago to ease access to the different resources on the Internet via names instead of numerical addresses—like accessing a website or exchanging email with the mail exchanger. Security was not a primary concern at that time. (“The fact that the DNS doesn’t have much security was pretty much intentional at the start because the problem was to get people to accept the whole idea of a distributed system, which at the time was quite controversial.”—Dr. Paul Mockapetris, inventor of DNS)

However, with the expansion of the global Internet, cybercriminals have started exploiting vulnerabilities in the domain name system. For example, Distributed Denial of Service Attacks, poisoning the resolver cache or redirecting end users to malicious websites. Another security issue is DNS hijacking—eavesdropping on DNS communications to gain unauthorized access to the user’s network settings, like router configurations, to identify vulnerabilities for other types of attacks.

The Domain Name System has been evolving to improve its security aspects, which were missing from the initial standard. 

DNSSEC

The DNS Security Extension (DNSSEC) was proposed by the IETF in 2005. It added data origin authentication and data integrity to the Domain Name System. The standard’s purpose is to protect end users from DNS cache poisoning and man-in-the-middle attacks. DNSSEC uses public/private key cryptography to authenticate the DNS responses. The standard protects the DNS queries from tampering by adding digital signatures to the responses, but it does not encrypt the data itself. The DNS traffic remains in clear text and is susceptible to eavesdropping.

Other standards were introduced to address these privacy concerns.

DNS over TLS

The DNS over Transport Layer Security (DoT) standard was proposed in 2016. The standard aimed to protect the end user’s privacy and eliminate the opportunities for on-path tampering with DNS queries. The DoT uses the security and encryption of Transport Layer Security (TLS) to exchange messages between the DNS client and the resolver, eliminating the possibility of eavesdropping on the network.

DNS over HTTPS

DNS over HTTPS (DoH) was proposed in 2018 to provide an additional mechanism to safeguard end users’ privacy. DoH utilizes the standard HTTP protocol to encapsulate and transport DNS traffic over TLS, making the DNS queries indistinguishable from HTTPS traffic.

Limitations of DoT and DoH

Both DoT and DoH do a very good job of ensuring privacy by utilizing the well-established encryption mechanism of TLS. However, this privacy comes at the cost of additional delays in resolving DNS queries. The TCP transport layer introduces a delay due to the TCP three-way handshake. Head-of-line blocking occurs as TCP enforces packet ordering, causing additional latency in communications. Additionally, TLS adds its own processing and establishment time to the DNS resolution.

DNS over QUIC

To address all these additional overheads, a new standard DNS over QUIC was proposed in the IETF standard RFC 9250 in 2022. It improves on its predecessors’ strengths and overcomes their shortcomings. The Association for Computing Machinery (ACM) published a performance study in October 2022. The study performed distributed DoQ measurements from different vantage points to measure the impact of DoQ on the web browsing experience. As per the study, with DoQ, web page load times were 10% faster compared to DoH. Compared to simple UDP DNS, DoQ performed only 2% slower, even with the additional encryption overhead. 

Before reviewing how DNS over QUIC works, let’s examine the QUIC protocol and its advantages for network communication.

How QUIC works

The Quick UDP Internet Connections (QUIC) protocol was initially developed by Google engineers (gQUIC) to improve the performance of websites and video streaming. Because of all its potential benefits, gQUIC was adopted and standardized by IETF (QUIC – RFC9000). The QUIC protocol was improved from the original design of gQUIC with the collaboration of many organizations and individuals. One of the notable changes from gQUIC is that the encryption used by Google was customized, and IETF introduced TLS 1.3 as the standard encryption mechanism in QUIC. Also, gQUIC was specifically built for HTTP, while IETF QUIC is a standardized generic transport protocol capable of carrying multiple application protocols, like HTTP, DNS, etc. The significant advantages of the QUIC protocol are discussed below.

Connection establishment and security

QUIC is a secure general-purpose transport protocol that integrates TLS 1.3 encryption by default. It works over UDP and creates its own stateful interaction between the client and server. Thus, it combines cryptographic functions and transport parameters into one protocol, eliminating many overheads. 

Compared to TCP+TLS, where you first perform a TCP three-way handshake and then a TLS handshake, QUIC requires only one round-trip time (RTT) for new interactions. It combines the Hello message, encryption algorithm, and unique connection ID into one packet. The connection information is repeated with Zero-RTT for a repeat connection between the client and server.

Packet multiplexing

The QUIC supports multiplexing of packets using multiple streams within the same connection. Once the connection is established, the client and server can open multiple streams for concurrent data transfer. This avoids head-of-line blocking issues present in TCP transport.

Congestion control and packet loss recovery

QUIC is a highly adaptive protocol. It can quickly respond to changes in network conditions, ensuring efficient utilization of available bandwidth and minimizing packet loss and delay. QUIC dynamically adjusts various parameters, such as the congestion window size, retransmission timeout values, and pacing rate, based on real-time network feedback. 

To better support real-time applications, the QUIC standard has been updated to include the capability to recover from errors or lost packets before retransmission using Forward Erasure Correction (FEC). 

Connection migration

QUIC maintains a session state using a unique connection ID to maintain continuity across changing IP addresses of the client and server. This allows the QUIC protocol to transparently switch end-user sessions, say, while switching from a WiFi to a 4G connection. This gives the advantage of seamless connection migration and a smooth browsing experience while using the QUIC protocol for transport.

How DNS over QUIC works

In traditional DNS, we have clear-text communication. Transport is over UDP for efficiency reasons. TCP transport is used if the DNS packet size increases above 512 bytes or where guaranteed data exchange is required (like in zone transfers). 

Compared to this, DNS over QUIC (DoQ) defines dedicated UDP port 853 for the DoQ server. The client and server can mutually agree on another port, but they must not use port 53 to avoid confusion. The protocol works as follows:

1. The client and the server establish a QUIC connection
2. The client initiates the DoQ query by sending a DNS message encapsulated within a QUIC packet. The packet includes the DNS query and metadata specifying it as a DNS over QUIC request. 
3. The DNS query is encrypted using the already established QUIC handshake.

The client can send multiple queries in parallel using separate QUIC streams within the same connection, and the DoQ server can respond to each query using the same streams. This provides a much-improved response time regardless of the encryption overhead used to encapsulate the data transfer. 

Compared to the traditional DNS protocol, DoQ also has all the advantages of the QUIC protocol.

• QUIC encrypts all communications, providing confidentiality and integrity to DNS queries between clients and servers.
• QUIC allows multiple DNS queries and responses to be sent concurrently over a single QUIC connection, reducing latency and improving efficiency.
• QUIC has built-in congestion control mechanisms, resulting in more reliable and faster DNS queries and responses, especially in networks with high packet loss.
• QUIC provides 1-RTT or even 0-RTT for repeat connections, which provide better performance even with the encryption overhead.

Implementation and adoption

DNS over QUIC, with all its benefits, has the potential to become the de facto standard in DNS resolution. However, given that DoQ is a relatively newer standard, it will take some time for it to be widely accepted as a global standard and implemented ubiquitously across DNS resolvers and servers.

Current implementations

Few organizations are taking the lead in the implementation of DoQ. 

Organization	Tools
Adguard DNS (first public resolver to implement DoQ)	dnslookup is a client which supports DoT, DoH, and DoQdnsproxy is a proxy server for DoT, DoH, and DoQDnsLibs is open source C++ library for the implementation of DoT, DoH, and DoQ
European public DNS resolver	DNS0.EU
PowerDNS	The latest version of dnsdist 1.9.0 supports DoQ in addition to DoT and DoH.
Other open-source implementations	aioquic, quicdoc, and doq-proxy.

Apart from them, Technitium,  an open-source authoritative and recursive DNS server, DNSPerf and Flamethrower, and open-source DNS performance testing tools all support DoT, DoH, and DoQ protocols.

The LogicMonitor offers a network monitoring solution to set up proactive observability for the Internet’s most critical services, including DNS, CDN, BGP, and other third-party services. DNS monitoring enhances DNS availability, performance and security for your applications.

Implement own DoQ Server with DNSDIST

Follow the steps below to implement your private DoQ resolver using PowerDNS dnsdist. PowerDNS provides repositories for the most popular Linux distributions to make installing dnsdist easier. Head over to the PowerDNS repo site and follow the instructions for installing dnsdist 1.9.x on your chosen platform.

After installation, dnsdist needs to be configured. It is a load-balancer that requires backend DNS resolvers. You can define your private resolvers or use any public ones. Edit the configurations file (/etc/dnsdist/dnsdist.conf) and enter the following configurations

-- define downstream servers, aka backends
-- https://dnsdist.org/guides/downstreams.html
newServer("1.1.1.1")
newServer("2606:4700:4700::1111")
newServer("8.8.8.8")
newServer("2001:4860:4860::8888")

Next, we need to enable DNS listeners to accept incoming connections from end users. Dnsdist is a versatile application that supports simple DNS listeners over TCP/UDP port 53. It also supports DoT over TCP/853, DoH over TCP/443, and DoQ over UDP/853.

-- accept plain DNS (Do53) queries on UDP/53 and TCP/53
addLocal("0.0.0.0:53")

-- accept DNS over QUIC (DoQ) queries on UDP/853
addDOQLocal('0.0.0.0:853', '/etc/ssl/domain-cert.pem', '/etc/ssl/domain-cert.key')

-- accept DNS over TLS (DoT) queries on TCP/853
addTLSLocal('0.0.0.0:853', {"/etc/ssl/domain-cert.pem"}, {"/etc/ssl/domain-cert.key"})

-- accept DNS over HTTPS (DoH) queries on TCP/443
addDOHLocal("0.0.0.0:443", {"/etc/ssl/domain-cert.pem"}, {"/etc/ssl/domain-cert.key"}, "/dns-query")

Restart the dnsdist service, and your DNS resolver is set to support all the standard and secure DNS protocols.

Last thoughts

In the article, we discussed how the DNS standard is evolving and how DNS over QUIC, is designed to leverage the efficiency and security of QUIC transport protocol. DoQ provides reduced latency, improved congestion control, and enhanced privacy through encryption. It is well suited for use cases of mobility or networks with high packet loss. However, its widespread adoption depends upon ensuring interoperability and standardization across all the different implementations of DNS clients and servers.