What does this implement/fix?

This adds DNS-over-QUIC (RFC 9250) in both directions, on top of the inbound DoT/DoH server in #2989 (this PR is stacked on new/dotdoh-server and should be reviewed after it).

DoQ is the last IETF standards-track encrypted DNS transport we did not speak, and it is by far the cheapest one left to add: the DNS message rides a QUIC stream with the same 2-byte length prefix DoT already uses, so on top of the OpenSSL QUIC stack the DoH3 work brought in there is no HTTP layer at all. Up- and downstream land together because they share that stack.

Outbound. doq://host becomes a dns.upstreams scheme, defaulting to UDP port 853; the quic:// spelling AdGuard and dnsproxy configs use is accepted as an alias so a copy-pasted resolver address just works. The exchange is fail-closed exactly like DoT/DoH/DoH3 - a bad chain, a reset stream or a timeout drops the query so dnsmasq fails over to the next server rather than downgrading to plaintext. Per RFC 9250 Sec. 4.2.1 the Message ID goes out as 0 and dnsmasq's own ID is restored on the answer, which is what several public DoQ resolvers enforce.

Inbound. dns.doq (default on, like dns.dot) brings up a listener on UDP/853 - the same port number DoT uses on TCP, which does not collide because the transports differ. It is a single-threaded event loop in the shape of the DoT listener: OpenSSL owns the QUIC transport (handshake, loss recovery, flow control, address validation) while every in-flight query is a small non-blocking state machine, so a slow resolve never stalls another connection and a flood costs a bounded state record rather than a thread stack. Queries are attributed to the real downstream client through the same private-EDNS handoff DoT and DoH use, and answers are padded per RFC 8467 when the client asked for it.

Shared plumbing. The socket, handshake and timer code the DoH3 client already carried moves into quic_common.c, so both QUIC clients share one context, one trust store and one fail-closed verify instead of two copies. DoQ is gated on a new HAVE_QUIC (OpenSSL >= 4.0) rather than HAVE_HTTP3, so a build without nghttp3 still speaks DoQ.

On hardening: QUIC address validation (Retry) stays on so we cannot be used to amplify towards a forged source, 0-RTT is explicitly disabled because a replayed early-data query would be answered and logged twice, only the doq ALPN is accepted, and connections, per-source connections, concurrent streams and per-connection queries are each capped. RFC 9250 Sec. 5.5.2 makes edns-tcp-keepalive a protocol error on DoQ, so a query carrying it closes the connection.

One wrinkle needed solving. OpenSSL's QUIC API exposes the peer address but no per-connection local address, and the listener is wildcard-bound, so - unlike DoT and DoH - we cannot simply read off which of our addresses a client reached. Conveying nothing is not an option: the answer is then built from the interface of our own loopback handoff, so pi.hole resolves to 127.0.0.1 for every DoQ client, and a CNAME chain reaching it writes that into the shared cache record other clients are served from. So we ask the kernel which source address it would use to reach that peer - the address it would itself put on a reply datagram, and therefore the one a plain-DNS answer is built from - and convey that as the private EDNS destination option. On a normal LAN this is exactly the address the client used. Should OpenSSL ever expose the real per-connection local address, this becomes a one-line change.

How to test the change during review

Automated coverage (all of it runs in CI):

• test/dotdoh_regression.c - doq:// and quic:// URI parsing: defaults, sni@ip pinning, bracketed IPv6, and the rejections (empty host, port 0/out of range, a path, doqx:// not prefix-matching doq).
• test/dotdoh.bats - outbound: a query resolves over the DoQ proxy path against the aioquic DoQ server in test/dotdoh_shim.py (port 8854), the forwarded query is padded (RFC 8467), and every forwarded query carries Message ID 0 (RFC 9250). That the answer is still accepted proves we map dnsmasq's ID back.
• test/dotdoh_server.bats - inbound: the listener comes up on UDP/853, a query resolves, it is attributed to the real downstream client (sourced from 127.0.0.4, which no other test uses, so the API evidence can only come from this query), several queries multiplex over one connection, a client not offering the doq ALPN is refused, a malformed query does not wedge the reactor, an IPv6 query resolves, and - the one that pins the destination hint down - pi.hole/AAAA over a v4 DoQ transport returns NODATA rather than leaking ::1. I verified that last one discriminates by suppressing the hint and re-running: it fails with expected NODATA but got 1 answer record(s) while its DoT twin still passes.

Manual, against a running Pi-hole:

1. Outbound - point Pi-hole at a public DoQ resolver and confirm queries flow and are attributed to the real upstream, not the internal loopback tuple:

   pihole-FTL --config dns.upstreams '["doq://dns.adguard.com"]'
   dig @127.0.0.1 example.com
   

   The query log / /api/queries must show the doq:// upstream, not 127.47.11.N. Cross-check the resolver itself with kdig +quic @94.140.14.14 A example.com.
2. Inbound - with dns.doq = true and a valid webserver.tls.cert, query the Pi-hole from another machine:

   kdig +quic @<pi-hole-ip> -p 853 A example.com
   

   The answer must be correct and the query must appear in the dashboard under the querying device's IP, not under the Pi-hole itself. q -t A example.com quic://<pi-hole-ip> works as a second client.
3. Fail-closed check - point a doq:// upstream at a host presenting the wrong certificate and confirm the query is dropped (dnsmasq fails over) rather than answered.
4. pi.hole over DoQ - from another machine, kdig +quic @<pi-hole-ip> -p 853 A pi.hole must return the Pi-hole address that machine reaches, not 127.0.0.1.
5. Build check - configure without nghttp3. The build must still report DoQ (DNS-over-QUIC) support: YES and HTTP/3 support: NO, and DoQ must work. Against an OpenSSL older than 4.0 the build must succeed with DoQ (DNS-over-QUIC) support: NO; -Werror makes that configuration easy to break, so it is worth checking.

Related issue or feature (if applicable): N/A

Pull request in docs with documentation (if applicable): N/A

By submitting this pull request, I confirm the following:

1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the EUPL 1.2 license
5. I have squashed any insignificant commits. (git rebase)

Checklist:

• The code change is tested and works locally.
• I based my code and PRs against the repositories development branch.
• I signed off all commits. Pi-hole enforces the DCO for all contributions
• I signed all my commits. Pi-hole requires signatures to verify authorship
• I have read the above and my PR is ready for review.