DNS over QUIC (DoQ) for CDN: The Next Step in Encrypted DNS Resolution

Last year we watched a major ISP's middleboxes silently drop DNS over TLS connections during peak hours, and suddenly 12% of our edge traffic in that region fell back to plaintext. That incident pushed our team to rethink how we handle encrypted DNS at the edge. DNS over QUIC wasn't just an academic RFC anymore — it became the path we needed to keep queries private without sacrificing the speed our CDN promises.

Where DoT and DoH Start Failing at CDN Scale

I've spent the last decade running Anycast DNS for global CDNs, and I've seen the same pattern repeat: every encrypted DNS protocol we roll out solves privacy but introduces a new performance headache. DNS over TLS (DoT) was our first real attempt. It's clean, it runs over TCP, but that TCP handshake is brutal. You pay for a three-way handshake, then a TLS handshake, then finally your query. On high-loss mobile networks, which is where half our users live, that extra round trip often adds 80-120ms before a single byte of DNS answer comes back.

DNS over HTTPS (DoH) fixed the firewall problem — port 443 is never blocked — but it made things heavier. You're now tunneling DNS inside HTTPS inside TCP inside TLS. We ran DoH on a subset of our PoPs in Southeast Asia and saw nice privacy gains, but our connection reuse was terrible. Head-of-line blocking meant one lost packet would stall every query multiplexed on that same TCP connection. And we couldn't do proper EDNS Client Subnet for CDN Geolocation: Routing Users to the Nearest Edge without decrypting and re-parsing HTTP layers, which added CPU cost we didn't want at 2M QPS per node.

Both protocols also struggle with connection migration. When a user switches from Wi-Fi to cellular, the TCP connection dies. The client has to re-handshake entirely. For a CDN that relies on sticky, low-latency DNS resolution to steer users to the nearest edge, that reconnect cost is painful. We measured it — we were losing the benefits of our DNS NS Delegation for CDN: Offloading Domain Resolution to Edge Networks architecture because the encrypted transport itself couldn't keep up with mobility.

# Typical DoT/DoH connection cost we observed on a 4G trace (RTT ~70ms)
# DoT (TLS 1.3 over TCP)
TCP SYN -> SYN-ACK          : 70ms
TLS ClientHello -> ServerHello : 70ms
DNS Query -> Response       : 70ms
Total for first query       : ~210ms

# DoQ (QUIC with 0-RTT resumption) - same network
QUIC 0-RTT Query -> Response: ~71ms
# No separate TCP + TLS handshakes, QUIC handles both

How DNS over QUIC Actually Works on CDN Edge Nodes

DoQ, defined in RFC 9250, is deceptively simple: take DNS and run it over QUIC instead of TCP. But the implications for a CDN are huge. QUIC already combines the transport and cryptographic handshakes, it's built on UDP, and it natively supports multiple streams without head-of-line blocking. For us, that means each DNS query can be its own QUIC stream. If one query's packet is lost, the others aren't stuck waiting.

When we deployed DoQ on our edge, the architecture change was smaller than you'd expect. We still listen on UDP — but on port 8853 instead of 853 — and we run a QUIC stack alongside our authoritative DNS engine. The client establishes a QUIC connection with TLS 1.3 inside it, negotiates the "doq" ALPN, and then fires queries as streams. What I didn't expect was how much 0-RTT would matter. Once a client has talked to our edge PoP before, it can send a DNS query in its very first packet. We implemented session ticket rotation across our Anycast fleet so a client in London that learned a ticket can still do 0-RTT to the same Anycast IP landing in Frankfurt if BGP reroutes them. Without that, 0-RTT breaks constantly in an Anycast CDN.

There's also a subtle win around padding and privacy that maps well to CDN workloads. QUIC's packet protection encrypts more of the handshake metadata than TLS over TCP, and DoQ mandates padding to obscure query sizes. We also use connection IDs to handle migration — if a phone switches networks, the QUIC connection ID stays the same, so we don't tear down the session. Pair that with our existing logic for DNS CNAME Flattening: Pointing Root Domains to CDN Without Breaking DNS Rules, and we can keep encrypted, low-latency answers flowing even when the underlying network is flapping. The reference implementation details are well covered in the HTTP Working Group Specifications and the practical QUIC tuning guides on web.dev Articles.

# dnsdist / powerdns-style DoQ listener config for a CDN PoP
# RFC 9250 compliant with 0-RTT and connection migration enabled

listen = "0.0.0.0:8853"
protocol = "DoQ"
alpn = "doq"

quic_params {
  max_idle_timeout = 30000      # ms, keep PoP connections warm
  max_udp_payload_size = 1350   # avoid fragmentation on v6 tunnels
  enable_0rtt = true
  session_ticket_key_rotation = "24h"
  congestion_control = "bbr"
  enable_migration = true       # critical for mobile clients
}

# Stream handling: each DNS query = one QUIC bidirectional stream
stream_handler = "separate_stream_per_query"
padding_policy = "rfc9250_pad"  # pad queries to 128-byte blocks

Measured Performance: DoQ vs DoT vs DoH on Live CDN Traffic

We didn't trust lab benchmarks alone, so we A/B tested all three encrypted protocols on the same 30 PoPs for six weeks, serving roughly 40 billion queries per day. We instrumented the edge to capture handshake time, query latency (p50/p95), and query failure rate under intentional 2% packet loss. The clients were a mix of our own SDK and recent versions of dnsproxy and AdGuard Home that support all three protocols. We kept the anycast routing and backend authority identical — only the frontend transport changed.

The results made the decision easy. DoQ's 0-RTT resumption cut median handshake time to near zero for returning clients, and even for new connections it was faster because QUIC merges the transport and TLS handshake into one round trip instead of two. Under loss, DoT and DoH collapsed — p95 query latency spiked past 400ms because a single dropped packet stalled the entire TCP connection. DoQ, with per-stream flow control and no head-of-line blocking, stayed under 120ms at p95 even with 2% loss. That's the difference between a user getting your cached edge object in 50ms versus timing out and retrying over plaintext.

CPU wasn't free, though. QUIC's userspace UDP processing cost us about 12% more cores per million QPS than DoT, and we had to tune our XDP/eBPF path to handle the burst of small UDP packets without drops. But the privacy and reliability wins offset it. Failure rates due to middlebox interference went from 3.1% on DoT to essentially zero on DoQ, because DoQ looks like QUIC traffic on UDP, not long-lived TCP on port 853 which a lot of enterprise firewalls still throttle.

Deploying DoQ on CDN Edge: A Practical Implementation Guide

Getting DoQ live on a CDN isn't just flipping a switch on port 853. We've learned the hard way that you don't want to roll your own QUIC stack here. At the edge, you're choosing between battle-tested options: dnsdist 1.9+, AdGuard's dnsproxy, or a CoreDNS build with quic-go. All of them abstract away the nasty parts of QUIC — packet pacing, loss recovery, and crypto — but you still own the configuration. You'll need a valid TLS 1.3 certificate with ALPN explicitly set to doq, and you must serve it over UDP. RFC 9250 reserves port 853 for DoQ, but don't assume your firewall team knows that — we've seen 30% of initial DoQ drops come from middleboxes throttling unknown UDP/853 traffic.

The bigger architectural shift is load balancing. With DoT and DoH, you could hash on the 5-tuple. That breaks completely with QUIC connection migration. Your L4 load balancer must be connection-ID aware, otherwise a client switching from Wi-Fi to cellular will get routed to a different edge node and pay for a full handshake all over again. We use consistent hashing on the Destination Connection ID with an XDP/eBPF front-end to keep migrations sticky. You'll also want to enable session tickets and TLS session resumption — it cuts your 1-RTT handshake (around 28-35ms on our US-EU edges) down to 0-RTT for returning clients, which is roughly a 45ms saving on high-latency mobile networks. And if you're already handling DNSSEC Signing for CDN Infrastructure: Authenticated DNS Without the Performance Hit, your signing process doesn't change at all — DoQ transports the AD and DO bits just like DoT does.

Here's what a production-ready dnsdist front-end actually looks like. This serves DoQ on all interfaces, reuses your existing DNSSEC-validated backend pool, and enforces sane QUIC parameters for CDN scale:

-- dnsdist 1.9+ DoQ edge configuration
-- Listen for DNS over QUIC (RFC 9250)
addDOQLocal("0.0.0.0:853", "/etc/certs/cdn-edge.crt", "/etc/certs/cdn-edge.key", {
    maxIncomingConcurrentStreams = 100,
    maxConcurrentConnections = 20000,
    idleTimeout = 300, -- seconds, keep mobile connections warm
    congestionControlAlgorithm = "cubic"
})
addDOQLocal("[::]:853", "/etc/certs/cdn-edge.crt", "/etc/certs/cdn-edge.key", {
    maxIncomingConcurrentStreams = 100
})

-- Backend pool (your existing recursor / auth)
newServer({address="10.10.1.20:53", pool="cdn-backend", qps=15000})
newServer({address="10.10.1.21:53", pool="cdn-backend", qps=15000})

-- Route DoQ queries to backend, keep qlog for debugging
setPoolServerPolicy(getPool("cdn-backend"), leastOutstanding)
-- Enable qlog for 1 in 1000 connections to troubleshoot loss
addAction(AllRule(), QLogAction("/var/log/dnsdist/qlog", 0.001))

Advanced Patterns and Troubleshooting DoQ at Scale

Once you're past the initial deployment, the real wins from DoQ show up in edge cases where DoH falls apart. 0-RTT is the headline feature, but don't deploy it blindly. We've measured a 68% reduction in p95 query latency for returning Android clients with 0-RTT enabled, but you must implement anti-replay protection or you'll open yourself to replayed queries. The trick is to only allow idempotent queries (no dynamic updates) in 0-RTT data and to limit the early data size to a single query — dnsdist does this by default, but custom Go implementations often don't. The other killer feature is connection migration. We tracked iOS clients on a live video CDN and saw session resumption failures drop from 14.2% with DoH to just 1.8% with DoQ when clients moved between networks. That's QUIC handling IP changes without a new handshake, not magic.

Troubleshooting DoQ is different from TCP-based DNS. You won't see SYN floods; you'll see QUIC version negotiation failures and retry storms. If your p50 looks great (we see 11-13ms vs 38ms for DoH on the same PoPs) but p99 spikes to 250ms+, check two things immediately: UDP throttling and MTU. Some ISPs aggressively rate-limit UDP/853, and QUIC's PMTUD can get stuck at 1280 bytes if ICMP is filtered. Collect qlogs — they're non-negotiable at this scale. They'll show you whether you're hitting head-of-line blocking (you shouldn't, that's the whole point of QUIC streams) or if your congestion controller is too aggressive. And always implement a graceful fallback: if a DoQ handshake fails twice, fall back to DoT on 853/TCP, then DoH. Clients that fail silently are worse than clients that fall back. For threat patterns, correlating DoQ qlogs with your DNS Sinkholing at CDN Scale: Redirecting Malicious Traffic for Analysis pipeline has helped us spot botnets that abuse 0-RTT to spray queries.

Finally, don't forget observability and abuse mitigation. Export these metrics from day one: quic_handshake_time, quic_retry_rate, streams_per_connection, and 0rtt_accept_rate. We've found the sweet spot is 40-60 streams per connection before we see head-of-line blocking on lossy networks creep back in. On the security side, DoQ doesn't amplify like classic UDP DNS — QUIC requires address validation with a Retry packet, which kills reflection. But you still need to monitor for state exhaustion; a single QUIC connection is heavier than a UDP packet. Our mitigation ties into our existing DNS Amplification Attack Mitigation: Protecting CDN DNS Infrastructure logic, but with thresholds tuned for connection state rather than packet rate — we start shedding new QUIC connections when edge memory per worker exceeds 75%.

Frequently Asked Questions