Should dnscrypt-proxy limit oversized HTTP/3 response trailers?

[wallace0409]

dnscrypt-proxy now uses quic-go v0.63.0. Could a peer sending a near-limit HTTP/3 trailer HEADERS frame and then stalling still cause excessive memory use? Would it be reasonable to set a stricter MaxResponseHeaderBytes limit or reject oversized trailers as defense in depth? This appears related to, but distinct from CVE-2026-40898.

[jedisct1]

Thanks for the heads up.

quic-go already includes a fix for that CVE, but the default limit too large for DNS traffic. There's now a 4K limit for HTTP/3, matching HTTP/2.

[wallace0409]

Ok, thanks for the quick fix!