This reverts commit 0b9524b7.

The hack shouldn't be needed anymore:
https://github.com/Homebrew/homebrew-core/commit/4369052170f4360b7ad545f23b8a01a4ccb37683#diff-59a7902ada251dd9dba99b5bd323c1dba1d102d244ce766c06ce00097fb82e8fL71

This isn't an exact revert, but differences are minor.

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

Until now, kresd would refuse to start when a log_groups Lua call
contained a non-existent group. After this change, only a warning is
printed, which helps during development while switching between branches
with new logging groups. I don't think changing the configuration all
the time just for a logging group is warranted.

The debug dumps of packets used UNIX timestamps (in RRSIG validity)
instead of the customary human stamps.
This was an unintentional regression of 0555828e, i.e. since v5.4.1

I looked again at all other differences from default kdig style,
and the only ones are that we don't show class and don't do IDN.
(both seem suitable here)

Let's specify more of the dependencies explicitly.
I suspect it was pkg-config that was missing;
https://github.com/CZ-NIC/knot-resolver/actions/runs/4241689540/jobs/7372234570

These packaging tests are dying anyway;
the manager branch reworked them.
So at least the breakages won't be shown in red until then.

https://gitlab.nic.cz/knot/knot-resolver/-/jobs/852665
https://build.opensuse.org/request/show/1050454

obs:leap15 after updating fails later in the vagrant step though:
https://gitlab.nic.cz/knot/knot-resolver/-/jobs/852799

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

Added the option to run `kresd` inside `pytests` under `valgrind` and
`rr`, which can help with debugging. Also added a clarifying note that I
personally would have liked to have while exploring this.

Since commit a0cbbde1 we don't ignore trailing bytes in queries.

release 5.6.0

See merge request !1381

They've been failing for many months, e.g. see
https://gitlab.nic.cz/knot/knot-resolver/-/pipelines/104497
This way it at least won't be confusing by showing red in CI.

avoid excessive TCP reconnections in some cases

See merge request !1380

Vladimír Čunát authored 2 years ago and Aleš Mrázek committed 2 years ago

On most fundamental issues like DNS message not parsing,
we did not call this.  Selection needs such information.

That setting is recommended by documentation but it would still leave
the timer triggering repeatedly.  Maybe it didn't cause any practical
difference, but it was unnecessary and possibly confusing.

Closes #127 and #736

(and minor other changes)

- apply to first (uncached) answer already
- don't extend over signature validity

Nit: the tests were using too high TTL (RFCs disallow the "sign bit").
It was working because (manual) cache-insertion was applying bounds,
but now the bounds don't get applied anymore, so it would fail.

Allowing too much seems to have more risk than benefit.  For example,
the 2-day TTL on DS records in .com zone (e.g. Slack issue months ago).

When a whole packet is cached (instead of individual RRs),
let's simplify the way the packet's TTL gets computed.

The previous mechanism came from commit 5b383a2b,
probably a misunderstanding of:
https://datatracker.ietf.org/doc/html/rfc2308#section-5
Anyway, I see no motivation to do it, and this way we should
get rid of some weird cases where we might extend TTL of some records,
except if they were below the cache.min_ttl() setting (5s default).

Fixing all instances of the same issue on the same docs page.

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

This silences the following warning given on newer version of meson:

WARNING: Running the setup command as `meson [options]` instead of
`meson setup [options]` is ambiguous and deprecated.

We can get stricter here;
with negligible fraction of real-life names regressing.

The separate function wasn't really doing anything.
Also add a debug log.