Quad9 Enables DNS Over HTTP/3 and DNS Over QUIC
Quad9 has enabled DNS over HTTP/3 (DoH3) and DNS over QUIC (DoQ) across its global resolver network. DNS transport protocols have continued to evolve since Quad9 first launched and following that evolution is part of how Quad9 serves users who care about the privacy and security of their queries.
Both protocols are built on QUIC as the underlying transport protocol, and that is where most of their improvements over existing encrypted DNS transports come from.
The QUIC Protocol
QUIC was designed as a general-purpose transport protocol with encryption as a core requirement, not an afterthought. Every QUIC connection is encrypted, and there is no such thing as cleartext mode. QUIC also requires TLS 1.3 specifically, which is faster and more cryptographically secure than earlier versions. Quad9 already requires a minimum of TLS 1.2 on its DoH service, so QUIC-based transports take that further. This is the architectural difference from TCP, where TLS is a separate layer negotiated after the connection is established. Similarly, the UDP protocol (which is still used in the majority of queries Quad9 processes) is unencrypted in almost all cases.
Some of the inherent limitations of TCP-based DNS protocols are addressed directly in QUIC’s design. TCP carries metadata that TLS alone cannot protect including packet sequence numbers, connection flags, and other transport-level information that remains visible on the network path regardless of whether the payload is encrypted. In QUIC, more of the transport is protected than in TCP+TLS including packet numbers and parts of the header, which reduces how much can be inferred by an on-path observer.
QUIC also reduces connection setup time. A new TLS-over-TCP connection requires the TCP handshake to complete before the TLS handshake can begin. QUIC merges these steps, reaching an encrypted session in fewer round trips. DNS is latency-sensitive by nature, so lower connection setup overhead has a real effect on response times. QUIC also allows clients to move between networks without unnecessary renegotiation overhead, so an active session survives a network change where a TCP-based transport would not.
DNS over HTTP/3
DoH3 is DNS over HTTPS (RFC 8484) carried over HTTP/3, which runs on top of QUIC. For anyone already using Quad9’s DoH endpoint at https://dns.quad9.net/dns-query, no configuration change is needed.
Quad9 signals its HTTP/3 availability through several standard mechanisms. Clients configured with only the resolver’s IP address can use DDR (Discovery of Designated Resolvers) by querying SVCB records at _dns.resolver.arpa to learn which encrypted transports are supported. Clients that already know the resolver hostname use SVCB records for dns.quad9.net as the primary source of protocol discovery; HTTPS records for the same name are also published for consistency. For clients that initially connect over HTTP/2, Quad9 returns an alt-svc header indicating that HTTP/3 is available, which the client may use to attempt an upgrade. Clients that implement any of these mechanisms can upgrade to DoH3 automatically. Notably, modern versions of Chrome or Chromium-based systems perform this update without intervention by the end user.
DoH3 has meaningful deployment across the broader web ecosystem already. Browsers and CDN infrastructure have been supporting HTTP/3 for some time, which means the client-side libraries and tooling are mature. Quad9 supporting it means users do not have to trade away that infrastructure maturity in exchange for a resolver that takes privacy seriously.
DNS over QUIC
DoQ, defined in RFC 9250, is a different design choice. Rather than layering DNS inside HTTP, it carries DNS queries directly over QUIC. There is no HTTP stack involved; the protocol is purpose-built for DNS. Clients connect on port 853, the same port used by DNS over TLS.
DoQ is still earlier in its adoption than DoH and DoT. Quad9 is making it available globally with the aim of contributing to broader adoption - we believe more choices for user privacy are always a better outcome. Client developers, router firmware maintainers, and privacy-focused software authors need production infrastructure to build and test against; a specification without a widely-deployed implementation is harder for the ecosystem to pick up. Quad9’s approach with DoQ mirrors its earlier approach with DoT: deploy it in production, at scale, to give the people building DNS clients something real to work with.
Using DoH3 and DoQ
For DoH3, no changes are needed. Clients that implement DDR, DNS SVCB, HTTPS discovery, or Alt-Svc handling can discover and use HTTP/3 automatically without changing the configured DoH endpoint.
For DoQ, use the hostname for the Quad9 service variant you want on port 853.
Both protocols are available across all Quad9 variants. The filtering resolver, the non-filtering resolver, and the ECS-enabled endpoint all support DoH3,DoQ, DOH (version 2), DOT, and DNSCrypt equally.
What Comes Next
DNS protocol adoption tends to move gradually. DoT had a long runway from specification to widespread client support. DoH moved faster, largely because it ran on infrastructure that already existed for other purposes, namely web browsers. QUIC-based protocols have a head start on that front as well. QUIC libraries and tooling are already deployed at scale for web traffic, which lowers the barrier for DNS clients to add support.
Quad9 will continue tracking how the ecosystem around DoH3 and DoQ develops. If you work on resolver client software or DNS tooling and want to test against a production DoQ deployment, now is a good time to try Quad9’s implementations, and please let us know if you encounter any issues in the process.