The following actions will now be logged in debug level (or request
tracing): ANSWER, DENY, DENY_MSG, DROP, REFUSE, TC

This can be useful for RPZ and other policy debugging.

Purposefully ommitted actions:
PASS - since it's the same as normal processing
REROUTE - the action itself comes from renumber module
STUB,FORWARD,TLS_FORWARD - this could be more confusing than useful
  (e.g. when response comes from cache)

To allow for easier debugging, each origin of an extended DNS error has
a unique 4-byte identifier that is included in the extra_text message.

The identifiers are random 4-letter base32 strings, generated with:
base32 /dev/random | head -c 4

Tomas Krizek authored 3 years ago and Vladimír Čunát committed 3 years ago

Answers to EDNS requests from certain lua policies that use the
answer_clear() function would lack OPT RR and thus violate the MUST
condition in RFC6891.6.1.1.

Josh Soref authored 3 years ago and Tomas Krizek committed 3 years ago

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

Vladimír Čunát authored 3 years ago and Tomas Krizek committed 3 years ago

Issues affecting functionality of the RPZ should NOT be hidden
by default.

Vladimír Čunát authored 3 years ago and Tomas Krizek committed 3 years ago

The logs can be triggered from policy actions, in per-request fashion:
- they're on LOG_DEBUG level but always sent, regardless of log config
- those messages will show double group tags: "[reqdbg][foo   ]"
  (but they lack proper meta-data - about location of the log's origin)
- reqdbg is *in addition* to normal logs, so the lines may be duplicated
  if that's how the logging was configured

Vladimír Čunát authored 3 years ago and Tomas Krizek committed 3 years ago

It's mainly in tests.

Vladimír Čunát authored 3 years ago and Štěpán Balážik committed 3 years ago

Perhaps this bug was now more pronounced since 5.3.0 changes.
Example problem was disabling minimization or 0x20 (globally or
for some problematic requests); without this change they would get
re-enabled during some fallback actions... which might be exactly
the wrong moment wrt. the motivation to setting these.
https://gitter.im/CZ-NIC/knot-resolver?at=60a221e86a950f3d46ed1cd9

- return SOA in NODATA answers and allow customizing it
- only call ensure_answer() if really generating an answer
  (otherwise we might e.g. deplete XDP buffers, in extreme cases)

Štěpán Balážik authored 5 years ago and Vladimír Čunát committed 4 years ago

Design discussion: #447
Code discussion: !1030

This amends commit 99e014ac.

For now I was too afraid to use "multi-flag" kr_request::state,
so I kept it at _FAIL; anyone can recognize it by NULL answer anyway.

Lua wrapper: using exception was considered but didn't seem good.
I utilized the fact that modules can return nil meaning no state change.

FIXME: see FIXMEs in diff, document the API change, re-review.

... by allowing .rdata to be a table.  Larger RRsets seem useful.

- use parser-detected $ORIGIN instead of looking at SOA owner
- skip records outside $ORIGIN (and warn) instead of nesting them
- simplify a bit, and tweak warnings

Also utilize table indexing.
This was a "regression" from extending RPZ support in 5.1.0.
NS and SOA are even mandatory, as RPZ is supposed to be a valid zone:
https://tools.ietf.org/html/draft-ietf-dnsop-dns-rpz-00#section-2

Some rules need it and it was nil until now.

DENY, DENY_MSG, DROP, REFUSE and TC will now clear the _selected RRs.
I believe that's what people usually expect of these actions anyway.

This new approach uses per-request variables in Lua and creates new
callback for each DEBUG_IF call instead of each request.

It creates new callback functions for every request which
uses "callback chaining" but these should be rare.

It seems there is no reason to keep this function private in policy
module.

DEBUG_IF accepts user-supplied function which decides which requests
should be logged.