HTTP/3 negative cache never expires: one transient QUIC failure permanently disables HTTP/3 for a resolver until restart

[Omoeba]

I was running dnscrypt-proxy 2.1.16 with http3 = true and noticed that after a while, the server would always fall back to h2. I noticed the issue did not occur in dnscrypt-proxy 2.1.8 (the version in debian trixie's apt repo), and did some digging to find the cause.

When an HTTP/3 request to a DoH server fails, the server is added to the Alt-Svc negative cache with port 0 and is never retried over HTTP/3 again for the lifetime of the process. A single transient QUIC failure (packet loss, brief UDP/443 interference, a momentary blip) permanently downgrades that resolver to HTTP/2 until dnscrypt-proxy is restarted. SIGHUP / hot reload does not clear it.

Origin

Introduced with http3_probe in commit 5d41d10, first shipped in 2.1.9 and present unchanged through 2.1.16. 2.1.8 and earlier are unaffected, as they had no failure-triggered negative cache.

Mechanism

• On an h3 transport error, altSupport.cache[host] is set to 0. This write is not gated on http3_probe; only the surrounding debug-log wording is.
• altSupport entries have no TTL and no eviction. The map is created once in NewXTransport() at startup and is never reset.
• Selection skips h3 whenever the cached port is 0 (the altPort > 0 guard), so a pinned host is never tried over h3 again.
• Once a host is in the cache at all, hasAltSupport is true, so the post-response Alt-Svc re-parse block (guarded by !hasAltSupport) is never re-entered for that host. There is no recovery path.
• SIGHUP only reloads plugins; it does not rebuild xTransport, so a reload does not clear the cache. Only a full restart does.

Scope

This affects the default Alt-Svc path (http3 = true, http3_probe = false), not just http3_probe, and has since 2.1.9. A server that legitimately supports HTTP/3 is abandoned permanently after one transient failure, because the cache cannot distinguish a transient failure from genuine lack of support.

Reproduction

1. Set http3 = true and log_level = 0. Use a DoH resolver that advertises h3 via Alt-Svc.
2. Send queries until the debug log shows the HTTP/3 transport in use.
3. Briefly block outbound UDP/443 to that resolver and send a query, so the h3 attempt fails and falls back to HTTP/2.
4. Unblock UDP/443.
5. Subsequent queries to that resolver never use h3 again, even though QUIC is now reachable. Only restarting dnscrypt-proxy restores HTTP/3.

[jedisct1]

Should be fixed. Thanks to the two of you!

[Omoeba]

Much appreciated!