| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
adds libjemalloc-detector
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This is so that it is more obvious that the PyPI package actually has
the `python-` prefix.
|
|
|
|
| |
Adds just https://gitlab.nic.cz/knot/deckard/-/merge_requests/220
|
| |
|
|
|
|
|
|
|
|
|
| |
The NSEC validation code has been written very mechanically
according to RFC 4033..4035, but those explain wildcard-related
topics in a way that's hard to understand right.
So here I rewrite it with a different philosophy, so it should be
easier to understand, a bit faster, and less buggy and bug-prone.
|
| |
|
|
|
|
| |
Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>
|
|
|
|
|
|
|
| |
Case: NSEC3 with too many iterations used for a positive wildcard proof.
To really fix the answers, this also needed fixing the `any_rank` part
which I somehow forgot in commit 7107faebc :-(
|
|
|
|
|
|
|
| |
https://docs.gitlab.com/ce/ci/unit_test_reports.html
https://mesonbuild.com/Unit-tests.html#testlogjunitxml
Implemented fully: build, build-asan; partially: pytests, deckard.
|
|
|
|
|
|
|
|
|
|
| |
In particular, non-support of EDNS is implied iff FORMERR without OPT
comes. If OPT is there, one possibility is that there was something
wrong in the OPT that *we* sent, but it seems much more likely that
this particular server is just bad and we want to try another one.
https://tools.ietf.org/html/rfc6891#section-7
In particular, we would be in trouble if we dropped OPT in a zone
that is covered by DNSSEC.
|
|
|
|
|
| |
It wasn't really used for a long time and became completely obsolete after
!1030.
|
|
|
|
|
|
|
| |
Previously there where resolve_badmsg and resolve_error functions used
to apply workarounds. This is now moved to selection.c and iterate.c
just provides feedback using the server selection API. Errors are now
handled centrally in selection.c:error.
|
| |
|
| |
|
|
|
|
|
|
| |
It failed on a CNAME to a sibling name that's a zone cut.
Fixed by a minimalistic approach - tweaking the conditions
to always ask each CNAME step separately when forwarding.
|
|
|
|
| |
Fixes: #611
|
| |
|
|
|
|
| |
Resolvers must answer queries even if the shared cache overflown during query processing.
|
| |
|
|
|
|
|
|
| |
Branch on Deckard tree tracked in this repository was left unmerged in
Deckard. The two trees therefore diverged and broke CI in knot-resolver
repo on a few commits retroactively.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is about situations when validator *thinks* it's in a signed zone
but an unsigned answer comes in. The assumption was that RRSIGs didn't
make it through some middle-boxes and it retried with explicit QTYPE=RRSIG.
There were two issues with that.
1. It seems that in most cases the cause of the situation is that
we skipped over a zone cut that transitioned to insecure state,
so the signatures correctly don't exist.
2. An explicit RRSIG query appears to be more trouble than worth;
it seems reasonable for servers not to answer it (fully);
see RFC 8482 sect. 7.
The new approach simply tries to find a proof that the name is insecure,
by spawning a QTYPE=DS sub-query on that name. That fixes some
real-life cases; usually this happens in iteration mode where one IP
address serves zones on both sides of a cut that transitions to insecure.
For details see new comments in that rrsig_not_found() function.
The change resulted in the iterator fallback not making sense anymore
so it was removed.
|
| |
|
|
|
|
|
|
| |
New Deckard repo without conflicting iter_refused.rpl test
does not contain libswrap and libfaketime anymore
so I had to remove hacks in build system for these.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MISSING triggers re-query to auth in attempt to find missing RRSIGs.
It causes reduntant queries and also puts some BOGUS RRsets in answers.
(It sounds bad but we were correctly setting rcode=SERVFAIL and AD=0
even before this commit.)
Formerly RRSIG ranks did not reflect results of validation.
Now we mark them as BOGUS and upgrade them to SECURE if they validate.
New validator phase answer_finalize prevents BOGUS RRsets from being
put even into SERVFAIL answers.
Closes: #396
|
| |
|
| |
|
|
|
|
| |
I don't know why exactly it fails ... let's unblock release.
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
These files did not have GNU GPL v3 boilderplate in them so
I've added machine readable tag with appropriate license.
|
|
|
|
| |
Now we hopefully won't need to touch it for a long time.
|
| |
|
|
|
|
|
| |
Previous version would add the TA and then print error message, which is
not expected.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|