Domain Name Service: New combination of DoQ in the alphabet soup

The communication of almost all Internet services begins with the name resolution of the target domain. The necessary requests from users and responses from the Domain Name System Server (DNS server) are mostly unencrypted, so that third parties can see who is visiting which destinations on the web. The Internet Engineering Task Force (IETF) has long planned to encrypt this significant traffic and has already launched two secure methods with DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT). For example, Mozilla has implemented Firefox in the web browser.

Now specialists have their say and bring a third IETF process comes into play, DNS-over-Quic (DoQ). The method is based on the new transport protocol Quick UDP Internet Connections, originally initiated by Google (Quic). Name resolution would automatically benefit from better performance and higher security, since Quic is designed for the modern encryption method TLS 1.3.

According to various measurements, 7 to 9 percent of web traffic is already going through Quic. Google’s Chrome was the first browser to use the protocol, and now there’s an experimental implementation for Firefox too.

The advantages of Quic include multiplexing for parallel requests and the avoidance of head-of-line blocking, in which a blocked request (e.g. due to packet loss at the TCP level) also blocks the processing of subsequent requests sent via the same TCP stream will. Quick already avoids this problem by working UDP-based.

Version 1.0 of the Quic transport protocol is practically ready. Christian Huitema of the IETF working group “DNS Privacy” (DPRIVE) recommends that this is the best opportunity to teach Quic how to transport DNS. The founder of the software company Private Octopus presented a simple design for DoQ together with Sara Dickinson from Sinodun and Allison Mankin from Salesforce. It is remarkable that Dickinson has already implemented the DNS-over-TLS method in the Stubby client and has promised DNS-over-HTTPS for Stubby.

The authors emphasize the increase in confidentiality in their DoQ proposal. Because TLS 1.3 is built into Quic, it becomes much more difficult for uninvolved third parties to eavesdrop on the DNS traffic. Quic also bans more metadata from the header to the encrypted body. The protocol is similar in this point to DNS-over-TLS and also specifies the authentication of the domain name servers. If you believe the design, DoQ combines the advantages of UDP and DNS over TLS / TCP.

So far, DoQ has only specified the connections between the user’s stub resolver and the DNS server of the DNS provider (recursive resolver). The IETF has also been planning for some time to encrypt the part of the DNS communication between the recursive resolver and the server responsible for a domain (authoritative name server). However, this requires cooperation with all the name server operators worldwide, which is time-consuming and slows down the work on this DoT extension.

But the DoQ group does not want to anticipate this work. Nevertheless, there are many questions on this point. Huitema told heise online via email: “There is interest in using DoQ between the recursive and authoritative server. However, this requires a method for finding DoQ-compatible name servers.”

Huitema explains that if you suspected that a name server would first be addressed via DoQ, and repeating the query via DoT or classic DNS in the event of an error, the DNS responses would be unnecessarily delayed. Only if it were clear beforehand which name servers could be addressed via DoQ would DoQ offer an “interesting combination of security and performance”.

So could DoQ end up being the compromise protocol in the race between DoT and DoH? “It would be nice, but probably not,” is Huitema’s laconic answer. DoQ is similar to DoT in many ways, with Quic replacing the TCP transport protocol. DoH, on the other hand, currently still uses TCP indirectly, but can switch to the almost finished HTTP / 3, i.e. the IETF continuation of Quic. So the abbreviation DoH, which stands for DNS-over-HTTPS, becomes the abbreviation DoH3 if DNS is transmitted via HTTP / 3. Huitema believes that the DoH-DoT race may end up becoming the DoQ versus DoH3 race.

The first discussions in the two groups tasked with Quic and DPRIVE showed that he could be right. Apple developer Tommy Pauly, for example, found that DoQ’s advantages over DoH3 were questionable. DoH3 is more practical, simply because DNS-over-HTTPS can be set up organically on HTTP / 3. In contrast, DNS experts, such as Ralf Weber, Principle Architect at Akamai in Frankfurt, warn against the shift of DNS traffic towards HTTP. The web protocol with its extra layer of metadata is a nightmare when it comes to data protection. So the race will probably continue for a while.

More from c't magazine

More from c't magazine


To home page