listener.Dnstap holds clientsMu.RLock() while iterating connected sink
clients. In the flush-error branch it called removeClient(c) synchronously,
but removeClient takes clientsMu.Lock(). A sync.RWMutex is not reentrant, so
the goroutine blocks forever waiting to acquire the write lock it can never
get while holding the read lock. The queued Lock() then blocks every
subsequent Dnstap broadcast and close(), and the goroutine leaks.
A flush error is the normal failure mode for a slow or disconnected sink
client (writeMsg buffers into framestream and succeeds; flush does the real
socket write and fails), so a single misbehaving client wedged the whole
listen path. Because Dnstap runs inline in the request-serving goroutine via
TapMessageWithMetadata, this could cascade into stalled request handling.
The write-error branch one line up already offloaded with `go removeClient(c)`.
Do the same in the flush-error branch and drop the early return so the
broadcast still reaches the remaining clients.
Assisted-by: Claude Opus 4.8
Signed-off-by: Pavel Lazureykis <pavel@lazureykis.dev>
LookupStaticHostV4/V6 dereferenced h.hmap and h.inline as call arguments,
which are evaluated before lookupStaticHostFamily takes the read lock. The
reload path (readHosts) swaps h.hmap under h.Lock() on every reload, so the
field read raced the swap for every A/AAAA lookup. This was introduced when
wildcard support (#8185) refactored these methods to pass the maps as
parameters; LookupStaticAddr still reads the fields inside the lock and was
unaffected.
Read h.hmap/h.inline inside the RLock by selecting the address family with a
bool instead of passing pre-dereferenced maps.
Also read h.mtime under the existing RLock in readHosts: it was read without a
lock while the reload writes it under h.Lock(), and readHosts runs from both
the OnStartup handler and the reload ticker goroutine.
Both races are confirmed by go test -race.
Signed-off-by: Pavel Lazureykis <pavel@lazureykis.dev>
* plugin/file: run additional processing for wildcard answers
The wildcard branch of Zone.Lookup returned a nil additional section, so a
wildcard-synthesized MX/SRV/SVCB/HTTPS answer with an in-bailiwick target
did not include the target's A/AAAA glue. The non-wildcard path already
does this, so call additionalProcessing in the wildcard branch as well.
Fixes#6629
Signed-off-by: Salih Muhammed <root@lr0.org>
* plugin/file: move wildcard additional test into wildcard_test.go
Requested in review: keep the wildcard tests in one file.
Signed-off-by: Salih Muhammed <root@lr0.org>
---------
Signed-off-by: Salih Muhammed <root@lr0.org>
Remove fixed TLS 1.2 cipher suite list and maximum TLS version so
crypto/tls can use its maintained defaults. Keep TLS 1.2 as the
minimum supported version.
Document the shared TLS default behavior for plugins that expose TLS
configuration and add coverage to ensure CoreDNS leaves Go-managed
TLS fields unset.
Signed-off-by: Ville Vesilehto <ville@vesilehto.fi>
The cache key is hashed on qname, qtype, DO and CD, but deliberately not on the AD bit, so a single entry serves both AD- and non-AD-requesting clients. The AD bit returned must therefore be derived per request from the cached answer's authentication status, not frozen from the query that populated the entry.
This pins both orderings (noad-then-ad and ad-then-noad) so the historical asymmetry reported in #6642 cannot regress.
Signed-off-by: baltasarblanco <baltablanco9008@gmail.com>
* plugin/rewrite: Fix nil-pointer panic in EDNS0 response reversion with no OPT record
This PR fix a nil-pointer panic in EDNS0 response reversion when downstream responses do not contain an OPT record,
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
* Fix
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
---------
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Avoid a potential nil pointer dereference in PacketConn.ReadFrom() when malformed PROXY protocol headers cause readFrom() to return a nil address.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
When serve_stale is enabled, a cached SERVFAIL in ncache shadows a valid
positive entry in pcache because ncache is always checked first. SERVFAIL
is transient and should not mask a known-good answer.
When the ncache hit is a SERVFAIL, check pcache for a valid entry before
returning the SERVFAIL. NXDOMAIN and NODATA are unaffected and still
follow the existing ncache-first lookup per RFC 2308.
Fixes#7956
Signed-off-by: umut-polat <52835619+umut-polat@users.noreply.github.com>
* Added fs.FileInfo.ModTime() based reload feature
Signed-off-by: Endre Szabo <git@end.re>
* Updated the plugin documentation.
Signed-off-by: Endre Szabo <git@end.re>
---------
Signed-off-by: Endre Szabo <git@end.re>
