Previously, all those actions caused resolver to return SERVFAIL,
because the lua code failed to evaluate.

Notably, deny action now properly returns NXDOMAIN instead of SERVFAIL.
The drop action still returns SERVFAIL.

Petr Špaček authored 4 years ago and Tomas Krizek committed 4 years ago

Old favicon used Knot DNS colors (dark blue) instead of Knot Resolver
colors (light blue).

Petr Špaček authored 5 years ago and Tomas Krizek committed 4 years ago

Omission in a339ee10.

Related: #529

Petr Špaček authored 5 years ago and Tomas Krizek committed 4 years ago

Rule ID is a number, not a string.

Petr Špaček authored 5 years ago and Tomas Krizek committed 4 years ago

consensus() function is affected by
https://gitlab.labs.nic.cz/knot/knot-resolver/issues/554
so this fix helps only with single-instance scenarios.

Petr Špaček authored 5 years ago and Tomas Krizek committed 4 years ago

It is broken at least since 1223599d,
i.e. 4.0.0.

realPy authored 5 years ago and Tomas Krizek committed 4 years ago

The id rule is not the same as the index of the array.

Fixes: #553

tests: revert broken commits in Deckard repo

See merge request !970

I don't know why exactly it fails ... let's unblock release.

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

From our TCP benchmarks, values over 128 don't seem to have any
measurable benefits, even with hundreds of thousands of connections.

On the contrary, during very high TCP and CPU load, smaller backlog
seems to dramatically improve latency for clients that keep idle TCP
connections.

During normal/low load, smaller backlog doesn't seem to have any
benefits.

When measured against "aggressive" clients that immediately close the
TCP connection once their query is answered, backlog smaller than 128
was measured to hurt performance.

The application's backlog size is ultimately limited by
net.core.somaxconn, which has been set to 128 prior to Linux 5.4.
Therefore, this change only affects newer kernels and those who have
manually set this value to a higher size.

For more, see
https://gitlab.labs.nic.cz/knot/knot-resolver/-/merge_requests/968

lua resolve(): correctly include EDNS0 in the virtual packet

See merge request !963

Deckard does not support these and it leads to confusing errors.
In long term we need to migrate Deckard to different network backend:
https://gitlab.labs.nic.cz/knot/deckard/issues/42

The new allocation approach isn't perfectly optimal, but it seems
relatively easy to understand and handles OOM conditions OK (I think).

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

Intended usage: Quick resolution attempt with an empty cache.

export QNAME=...
export QTYPE=...
sudo -E docker run -e QNAME -e QTYPE krestest:latest '-n' '-c' '/etc/knot-resolver/kresd.conf'

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.

It did not log through request->trace_log and is not very useful anyway.

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

Attempt to avoid duplicating ten lines in debug_logfinish_cb lead me
to splitting kr_log_qverbose_impl into two functions kr_log_q and kr_log_req.
This is another minor change to API exposed to modules.

Formerly both logs used slightly different formats and duplicated code.
From now on verbose log and request tracing are generated using the same
code.

This required a small change to request trace_log_f definition so it
might affect external modules.

We de-randomize qname letter case very early so kr_pkt_text() should see
all lowercase. Any uppercase means mismatch.

I've considered moving debug print to an earlier place but this way it
is more visible so I like more.