What happened:
Reloading a CoreDNS instance that serves DNS-over-QUIC causes a panic:

CoreDNS-1.13.1
linux/arm64, go1.25.2, 1db4568
[INFO] Reloading
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x67367c]

This is because tls is reinitiallized with an empty key. When putting the wrapper around it, the actual error occours:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x6a4544]

$ echo 0x6a4544| go tool addr2line ./coredns
github.com/coredns/coredns/core/dnsserver.(*ServerQUIC).ServePacket()
core/dnsserver/server_quic.go:<line>
github.com/quic-go/[email protected]/server.go:143

ServePacket dereferences a nil s.quicListener because the new server instance never rebuilt it before the reused UDP socket was handed over.

What you expected to happen:
Reload should reuse the existing QUIC socket without crashing.

How to reproduce it (as minimally and precisely as possible):

1. Start CoreDNS with the Corefile below (QUIC + reload).
2. Modify the configmap, add a plugin for example
3. The process panics in ServePacket.

Anything else we need to know?:
On reload, Caddy skips a new ListenPacket() call and invokes ServePacket() directly with the old net.PacketConn. ServePacket assumes s.quicListener was initialised already, so the dereference crashes. Lazily wrapping the provided PacketConn when s.quicListener is nil fixes it; I have a patch ready.

Environment:

• the version of CoreDNS: 1.13.1
• Corefile:

    quic://.:784 {
        tls /etc/coredns/ssl/tls.crt /etc/coredns/ssl/tls.key {
            client_auth nocert
        }
        quic
        reload
    }

• logs, if applicable: see panic trace above.
• OS (e.g: cat /etc/os-release): its the default coredns/coredns container