* plugin/quic: add max_connections directive
Brings quic to parity with https and https3, which both already expose
max_connections. The server-side plumbing already exists and is already
wired up: core/dnsserver/config.go declares MaxQUICConnections *int, and
server_quic.go already consumes it (DefaultQUICMaxConnections = 200,
gates accepted connections on a semaphore sized from it). It was just
never parsed from a Corefile directive for the quic plugin itself, so
setting it today fails with "unknown property 'max_connections'".
Adds the max_connections case to parseQuic, mirroring https3's exact
validation (non-negative integer, 0 disables the limit, duplicate
definition rejected) since the two share a config field. #8187 did the
same shaped fix for https3 reaching parity with https; this does the
equivalent for quic, the one remaining sibling without it.
Extends TestQuicSetup with max_connections coverage (valid value, 0,
missing arg, non-numeric, negative, duplicate definition, extra arg).
Verified it fails without the setup.go change (unknown property error)
and passes with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
* core/dnsserver: propagate MaxQUICConnections across server block keys
Addresses review feedback on this PR: Caddy only runs directive setup
for the first key in a server block, and the QUIC server reads
MaxQUICConnections from group[0]. propagateConfigParams copies
listener-wide settings from the first config in a block to the others,
but it did not propagate this field. In a multi-transport block where
the quic key isn't first, e.g.:
.:53 quic://.:8853 {
quic {
max_connections 1
}
}
the value was stored on the first (DNS) config while the QUIC config
kept MaxQUICConnections nil, so NewServerQUIC silently fell back to the
default limit of 200 instead of the configured one.
Adds the propagation line, mirroring the existing MaxHTTPSStreams entry
(and its comment) added for the equivalent key-order issue on https.
Added TestPropagateConfigParamsMaxQUICConnections, mirroring the
existing TestPropagateConfigParamsMaxHTTPSStreams. Verified it fails
without the register.go change and passes with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
---------
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
Add a max_streams option to the *https* plugin to limit the number of
concurrent HTTP/2 streams per DoH connection. This lets operators cap
per-connection concurrency (guarding against resource exhaustion) or
raise it above the Go default for high-fan-in clients that multiplex
many requests over a single connection.
Semantics match the existing *https3* plugin's max_streams:
- omitted -> Go HTTP/2 server default is used
- 0 -> use the underlying HTTP/2 transport default
- positive -> advertise exactly that many concurrent streams
- negative -> rejected at config parse time
The limit is applied via the standard library http.Server.HTTP2
(HTTP2Config.MaxConcurrentStreams) so it is advertised in the server's
SETTINGS frame.
Signed-off-by: Mekias Yohannes <mmyohannes@gmail.com>
Keep miekg/dns's default request policy unless a plugin explicitly registers an additional opcode. Aggregate the policy at the listener, then enforce it again after zone routing so mixed server blocks on one socket remain isolated.
Apply the same policy to UDP, TCP, and DNS-over-TLS while preserving TSIG verification and the one-question requirement.
Signed-off-by: houyuwushang <liuluoqianqiu@outlook.com>
Add comprehensive tests for multiple components including server blocks
inspection, configuration handling, DoH/DoQ writers, and server startup
functions. Increases overall test coverage from 27% to 38.4% with
particular focus on register.go, https.go, quic.go, and config.go.
Signed-off-by: Ville Vesilehto <ville@vesilehto.fi>
