The RequestDuration histogram is declared with labels server, zone and view
only (plugin/metrics/vars/vars.go) and report.go observes it with those three
values. The type label belongs to requests_total, not to the duration
histogram, so remove it from the README metric list.
Signed-off-by: yuwk <1729065730@qq.com>
* plugin/cache: cache SERVFAIL when the resolver fails without a response
The forward plugin returns (SERVFAIL, err) on an upstream timeout without
calling WriteMsg, so the response never reaches the cache ResponseWriter
and is not stored. Every client retry then hits the upstream again and
pays the full forward timeout, while a SERVFAIL sent by the upstream is
cached normally.
Store a SERVFAIL generated from the failure, bounded by the existing
servfail TTL, so identical queries are answered from the cache while it is
valid. A servfail TTL of 0 keeps the previous behaviour.
Signed-off-by: Ahmad Mehrabi <mehrabi@post.com>
* plugin/cache: do not cache SERVFAIL caused by a canceled request
forward also returns SERVFAIL together with an error when the request
context is canceled. DoH propagates the HTTP request context, so caching
that failure would make every subsequent request with the same cache key
fail until the servfail TTL expires, even though the upstream is healthy.
Only insert the synthetic SERVFAIL when the request context is still live,
and add a regression test that cancels the first request and then verifies
that a subsequent healthy request reaches the backend.
Signed-off-by: Ahmad Mehrabi <mehrabi@post.com>
---------
Signed-off-by: Ahmad Mehrabi <mehrabi@post.com>
The proxyproto plugin parsed PROXY protocol v2 headers only to recover the real
client address; the TLV vector was discarded, so downstream plugins had no way to
read values such as the AWS VPC endpoint ID, SSL client CN, or vendor-specific
custom TLVs.
Add an opt-in `tlv_metadata` option. When set, the connection's raw PPv2 TLV
vector is captured and the plugin, acting as a metadata.Provider, publishes it
under the `proxyproto/tlv` label as a hex-encoded string. Consumers decode and
split it with proxyproto.SplitTLVs. The option is off by default, so existing
deployments skip the extra per-connection processing and behave exactly as before.
PROXY protocol v1 connections, which carry no TLVs, are unaffected.
Capture spans all transports: dns:// (UDP and TCP), tls:// (DoT), https:// (DoH),
grpc://, quic:// (DoQ), and https3:// (DoH3). QUIC-based transports require
udp_session_tracking, since the PPv2 header arrives as a standalone first datagram
ahead of the QUIC handshake.
Includes unit tests for capture, the metadata provider (direct and through the
real metadata chain), v1 compatibility, and option parsing, plus README and man
page updates.
Fixes#8633
Signed-off-by: Mekias Yohannes <mekias@amazon.com>
Co-authored-by: Mekias Yohannes <mekias@amazon.com>
The Pod object stored only the primary pod IP (status.podIP), causing
PodIndex lookups to fail for IPv6 clients in dual-stack clusters. This
prevented the metadata plugin from populating client-pod-name and
client-namespace.
Replace the PodIP string field with a PodIPs []string slice populated
from status.podIPs, and update podIPIndexFunc to index all IPs.
Signed-off-by: Christian Norbert Menges <christian.norbert.menges@sap.com>
Without IP_RECVERR, Linux passes only some ICMP errors, such as port
unreachable, to a connected UDP socket. It drops net and host unreachable
(net/ipv4/udp.c, __udp4_lib_err), so a query to an upstream behind an
unreachable route waits out the read timeout before forward tries the
next upstream, and health checks wait out theirs before marking it down.
Set IP_RECVERR (IPV6_RECVERR for IPv6) on the UDP sockets for upstream
queries and health checks, so the read fails when the ICMP error arrives.
TCP sockets are left alone, and nothing changes outside Linux. The health
check client gets an explicit 2s dial timeout, since a Dialer replaces
dns.Client's default one. Because the Dialer now exists from the start,
setDialer no longer creates a bare one when source_address is set, which
also lost the dial timeout before.
Fixes#8621
Signed-off-by: MohibShaikh <mohibuddin9@gmail.com>
Brings clouddns to parity with route53, which already exposes
aws_endpoint for overriding the API endpoint (useful for pointing at a
local emulator or test environment). clouddns has no equivalent - its
client constructor only ever accepts a credentials option.
Changes f's single option.ClientOption parameter to variadic
...option.ClientOption so credentials and endpoint can be combined, and
adds the endpoint case wired to option.WithEndpoint, Google's own
client option for this exact purpose.
Extends TestSetupCloudDNS with endpoint coverage (valid value, missing
arg). Verified it fails without the setup.go change (unknown property
error) and passes with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
Brings azure to parity with route53, which already exposes a refresh
directive to control how often zones are re-synced. azure currently
hardcodes this to 1 minute (Run calls h.run(ctx, time.Minute)) with no
way to change it, even though the internal run() method already takes
an arbitrary interval parameter - the plumbing exists, it just wasn't
exposed as a Corefile option.
Adds a refresh field to the Azure struct, threads it through New(), and
has Run() use h.refresh instead of the hardcoded value. Parses the
refresh directive in parse() mirroring route53's exact validation
(accepts a plain number as seconds or a duration string, must be
greater than 0).
Extends TestSetup with refresh coverage (valid duration, valid plain
number, missing arg, non-numeric, zero, negative). Verified it fails
without the setup.go change (unknown property error) and passes with
it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
Brings clouddns to parity with route53, which already exposes a
refresh directive to control how often zones are re-synced. clouddns
currently hardcodes this to 1 minute (delay := 1 * time.Minute in Run)
with no way to change it.
Adds a refresh field to the CloudDNS struct, threads it through New(),
and has Run() use h.refresh instead of the hardcoded delay. Parses the
refresh directive in setup() mirroring route53's exact validation
(accepts a plain number as seconds or a duration string, must be
greater than 0).
Extends TestSetupCloudDNS with refresh coverage (valid duration, valid
plain number, missing arg, non-numeric, zero, negative). Verified it
fails without the setup.go change (unknown property error) and passes
with it.
Signed-off-by: stackedbyaradhya <aradhyaj736@gmail.com>
* 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>
The `tools.ietf.org` site now redirects to `www.rfc-editor.org`.
* Update various URLs to the new site.
* Make links to `www.rfc-editor.org` consistent.
Signed-off-by: SuperQ <superq@gmail.com>
