Mirrors/coredns
1
0
Fork 0
mirror of https://github.com/coredns/coredns.git synced 2026-10-09 03:55:21 -04:00
Code Issues Packages Projects Releases Wiki Activity

plugin/quic: add max_connections directive (#8610)

Browse Source 
* 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>
This commit is contained in:
Aradhya Jain
2026-10-08 17:54:25 +05:30
committed by GitHub
parent e886525620
commit 45ac7fe659
5 changed files with 112 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
core/dnsserver/config_test.go
View File

@@ -118,6 +118,19 @@ func TestPropagateConfigParamsMaxHTTPSStreams(t *testing.T) {
}
}
func TestPropagateConfigParamsMaxQUICConnections(t *testing.T) {
n := 7
first := &Config{MaxQUICConnections: &n}
first.firstConfigInBlock = first
second := &Config{firstConfigInBlock: first}
propagateConfigParams([]*Config{first, second})
if second.MaxQUICConnections == nil || *second.MaxQUICConnections != n {
t.Fatalf("expected MaxQUICConnections to propagate to second config as %d, got %v", n, second.MaxQUICConnections)
}
}
func TestPropagateConfigParamsAllowedOpcodes(t *testing.T) {
first := &Config{}
first.firstConfigInBlock = first

4
core/dnsserver/register.go
View File

@@ -320,6 +320,10 @@ func propagateConfigParams(configs []*Config) {
// Propagate MaxHTTPSStreams so a `https { max_streams N }` set once in a
// server block applies to the block's HTTPS key regardless of key order.
c.MaxHTTPSStreams = c.firstConfigInBlock.MaxHTTPSStreams
// Propagate MaxQUICConnections so a `quic { max_connections N }` set once
// in a server block applies to the block's QUIC key regardless of key order.
c.MaxQUICConnections = c.firstConfigInBlock.MaxQUICConnections
}
}