Example:
  assert(require('ffi').C.kr_view_insert_action(
  		'127.0.0.0/24', 'policy.DENY_MSG("message")'
	) == 0)

Also switch the localhost rule there, finishing migration
of all special names from the policy module.

Picked up old work, rebase-squashed after many months;
then fixed up a little as needed in this newer version.
(and later many minor fixes got squashed in)

I broke this in 54ab3f78 or closely around, so this never worked well
since 5.4.1, and maybe structured logging (5.4.0) had related issues.

Oto Šťáva authored 2 years ago and Vladimír Čunát committed 2 years ago

Fixes #760.

Also removes a warning in policy.REROUTE that is no longer true.

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