The Internet Engineering Task Force (IETF) has published RFC 9250 on DNS via QUIC (DoQ). It promises better name resolution at faster speeds. Name resolution (DNS) encryption protocols, including DNS over TLS (DoT) and DNS over HTTPS (DoH), have been the subject of controversy for some time. With the relatively small QUIC protocol, the IETF now wants to use its positive properties inherent in the protocol for name resolution.
Built-in TLS 1.3 encryption for better data protection and improved latency in connection establishment (compared to classic TLS over TCP) should have a positive impact on name resolution. RFC 9250 also defines various purposes in DNS for DoQ: “Stub to Recursive Resolver”, “Iterative to Reliable” and Zone Transfer scenarios.
Kein head time blocking
The QUIC protocol, which is based on UDP, offers some interesting properties of DNS transmission. With DoQ, there is no major blocking as with DNS over TCP for larger transmissions. Each request/response transaction is mapped to a separate flow. This means that a missing answer cannot slow down subsequent queries. The customer chooses a custom stream for each order.
In addition, the client and server must enable connection reuse by sending multiple requests and responses over a persistent QUIC connection. Usually there is no need for an additional QUIC handshake. Clients that send multiple queries to the DNS server should not wait for a pending response before sending another query.
DoQ has a dedicated UDP port number 853. However, depending on the specification, the client and server can also agree on other ports, where UDP port 53 is not allowed due to the risk of confusion with DNS over UDP. DoQ support relies on the Application Layer Protocol (ALPN) negotiation token “doq” in the cipher handshake. If a DoQ connection fails, customers can fall back to the DoT and thus to the plain text transmission. However, the client must remember server IP addresses that do not implement DoQ.
Although QUIC packets are encoded, a protocol analysis can show that they are the DoQ of packet lengths in requests and responses, and their timing. It is therefore recommended to apply the filler according to the EDNS filler or QUIC filler option.
Feature: Improved data protection
TLS 1.3 encryption built into QUIC provides improved data protection and also protects against downgrade attacks by default. For long lasting sessions, QUIC has the advantage that the source IP addresses on the client can change during transmission. This separates the transmission of IP addresses and uses the connection identifiers and the streams they contain.
However, compared to UDP, DoQ also has more effective correction of packet losses caused by the QUIC protocol and RFC 9002 (QUIC Loss Detection and Congestion Control). There is also better source IP validation from DNS over UDP to protect against amplification attacks.
Another advantage compared to traditional DNS encryption methods is QUIC’s 0-RTT (zero round trip) feature to resume previous sessions without additional handshakes. This reduces the latency of requests to the DNS server itself compared to setting up new sessions including relevant TLS negotiations, whether it’s for DoT or DoH.
extra speed
DoQ aims to combine the data protection of DNS over TLS with the positive latency characteristics of classic DNS over UDP. However, at the same time, protocol designers want to use a more direct alternative to DNS over HTTPS. Although the new HTTP/3 is also based on QUIC, DoH sending with HTTP/3 will add an extra layer of HTTP, adding more overhead and complexity. Therefore, DoQ should represent the most direct alternative.
As with all RFCs, it remains to be seen if and when there will be practical applications. More details about DNS via QUIC (DoQ) can be found at RFC Editor des IETF.
()