Query log

Work in progress — content may be incomplete.

Warden logs one line per DNS query it handles — including why it answered the way it did.

What each outcome means

The result field on every query-log line isn’t the DNS RCODE — it’s Warden’s own record of which code path answered. Several outcomes can share one RCODE, and one outcome (BLOCKED) can produce four different RCODEs depending on config.

Outcome	Fires when	Wire RCODE	What to do
`ALLOWED`	logged the instant the upstream fetch returns, before Warden inspects the answer	not fixed — depends on what upstream returned	means “forwarding attempted”, not “clean” — see the note below
`BLOCKED`	profile/admin-rule/blocklist match, CNAME-chain block, or a post-fetch IP-blocklist re-check	depends on the profile’s `block_response`: `zero`→NoError+0.0.0.0, `nxdomain`→NXDOMAIN, `refused`→REFUSED, `soa_nodata`→NoError+SOA	expected if policy is working as intended; check the line’s `rule` field, and the profile’s list policy, if it shouldn’t have blocked
`REFUSED`	`[anti_bypass]` pre-query refusal, no profile matched the client (L5 miss on the resolver ladder), or DNS-tunneling rate exceeded	always REFUSED	unexpected for a known client → check its device/group/subnet mapping, or whether `default_profile` is set
`RRL_DROP`	rate-limit hard drop	none at all — the packet is never sent, a true silent drop	frequent for a legit client → check `[security]` rate-limit thresholds
`RRL_SLIP`	rate-limit anti-spoof slip	NoError, `TC=1` (forces the client to retry over TCP)	normal RRL behaviour, not an error
`LOCAL`	a per-profile or global `local_records` hit, or NODATA synthesis for a locally-authoritative name	NoError	expected for local DNS config
`CACHED`	cache hit	passthrough of whatever RCODE the cached entry stored	nothing to do
`HINFO`	RFC 8482 — a QTYPE=ANY query was intercepted	NoError	expected hardening, not an error
`STALE`	the upstream fetch failed and Warden served an expired cache entry instead	passthrough of the stale entry’s RCODE	recurring → check upstream health and `[[forwarding]]`

A single lookup can produce two log lines. ALLOWED is stamped the moment the upstream fetch returns — before Warden checks the answer for a CNAME-chain or IP-blocklist hit. If that check fires, an immediate BLOCKED line follows for the same query. ALLOWED means “forwarding was attempted,” not “traffic passed through clean.”

TUI colour coding. The query-log tab buckets these nine values into three severities for the RESULT cell’s colour: red for BLOCKED (and any CNAME-chain block, even on a line whose result string isn’t literally BLOCKED), amber for STALE and REFUSED, grey for everything else — including RRL_DROP and RRL_SLIP, which the colouring doesn’t distinguish from a clean serve even though RRL_DROP is a genuine silent drop.

This page is about the file. To read the same lines inside Warden — filtered by domain, client or time, with one key to allow or block the name you are looking at — see the query log tab.

Verify it in the code

Every claim on this page is one function away in the source. Where to look:

Where outcomes are recorded

src/dnshandler.rs → record_outcome()

src/trackingengine.rs → log_query_event()

CNAME-chain / IP-blocklist block dispatch

src/dnshandler.rs → dispatch_cname_block()

src/dnshandler.rs → dispatch_ip_block()

REFUSED dispatch

src/dnshandler.rs → send_refused()

RRL slip (TC=1)

src/dnshandler.rs → send_truncated()

RFC 8482 (HINFO)

src/dnshandler.rs → send_rfc8482()

TUI severity bucket

src/tui/tabsquery_log.rs → result_severity()