For long arrays we really want to increase their length by a fraction.
Otherwise it will cost lots of CPU.  Doubling seems customary,
though I could imagine e.g. keeping the +50% growth on longest arrays.

I finally got sufficiently angry with this piece of code when debugging
https://forum.turris.cz/t/how-to-debug-a-custom-hosts-file-for-kresd/17449
though in that case it wasn't the main source of inefficiency.

CI: two of the mysterious/bogus warnings around arrays disappeared.

Fixes #760

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.

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

Fixes CIDs 355763 and 355764. Also fixes a minor typo.

Other LTS than 22.04 have really old versions in the repo (<= 3.2.1),
so better not advertise those at all.

The address won't work anymore, and Jakub says this field isn't needed.

https://gitlab.nic.cz/knot/knot-resolver/-/jobs/635837#L219

This reverts commit ac3e7ac7.
They have been fixed and seem reliable now.

It broke down and it isn't relevant anymore.

That way we get at least basic testing before 3.2 is made default in CI.

Our strategy was (and remains) that the in-header QNAME is overwritten
in-place, so most of our code was already (correctly) assuming that
knot_pkt_qname() returns lower-case only.  That simplifies this commit.

We've been unable to progress with these failures for some time,
and it's not good to have them red in CI all the time.
Manual start should allow easier testing of future fixes,
without doing the futile runs automatically.

Fixes #758

Héctor Molinero Fernández authored 2 years ago and Vladimír Čunát committed 2 years ago

Fixes a regression on Meson 0.57.0 that produces a timeout in config.ta_bootstrap test.

Some of our CI jobs use project-specific GitLab runners (e.g. requiring
the `dind` tag). The jobs then fail when someone forks the repository
and opens a merge request. This commit confines those jobs to the
`knot/knot-resolver` repository.

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

The double-free may have happened in some cases when the upstream
resolver was stopped while answering a forwarded query. I was reliably
reproducing it by running resperf on two kresd instances with one forwarded
to the other, and killing the upstream one.

When kresd starts without working internet connection, these would spam
logs by default every 10 seconds, which doesn't seem useful.

I can't see sufficient motivation here.  The cache will be slightly
less ready, but it's not often that you need to contact a root server.

Most importantly, kresd must work well anyway, even with empty cache.
Also, the compiled-in address set of root servers should be quite
accurate - the NS set has never changed, and the last address change
was five years ago with just one of 26 records changing.