This orphaned kr_ta_get_longest_name() so it got removed as well,
even though it's a potentially useful abstraction.

It was word-for-word identical with kr_ta_get_longest_name() anyway,
except for additional pointer->bool conversion.

The closer (N)TA will win now.  That wasn't the case
if we had a positive TA underneath a negative TA.
(Well, I can't recall ever seeing anything close to a use case.)

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 7107faeb :-(

Really support 64-bit return value even there.
Currently we only use such large value in an unimportant case
(lua_Number seed).

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

Some less common HW (not x86, usually ARM) doesn't tolerate unaligned
access to memory and it's breakage of C as well.

It's easiest to check by meson's -Db_sanitize=undefined (on any HW).
I pushed millions of real-life QNAME+QTYPE queries over UDP in default
mode and the sanitizer seems clear now.

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

libknot >= 2.9 provides it and their version is less buggy :-)
In particular, it works with unaligned pointers.

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

In particular, ignore ENOSPC from LMDB for a short time unless the
space-usage estimate is over 90%.  See code comments for details.

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

I suspect there's an edge case where cache thinks it provided enough
data but iterator (or who) disagrees and resolution continues.
We observed (flags.CACHED == true) even when processing a reply from
internet, and that could be confusing and even trigger a segfault.
Clearing the flag sounds OK semantically; it never meant that no cached
data have been used within the kr_query (e.g. zone cut, DS/DNSKEY, ...)

Our aggressive NSEC cache doesn't handle these well and the case
with only the end-label being like this was forgotten.
See the parent commit for a test case.

Also, larger NSEC* sets are now considered weird.

Example case: denying existence of ok.rdns.dev by
oj\255.rdns.dev. NSEC ok\000.rdns.dev.
This NSEC end was incorrectly ordered with the QNAME.
https://gitter.im/CZ-NIC/knot-resolver?at=606055b82beb1e1da3d73892

The code is Libor's :-)

(in aggressive cache part)  Also bump cache version, so that we clear
those that have been left by previous kresd releases.

It seems better to check RRSIGs before checking negative proofs,
in terms of reasoning, being less error-prone, etc.

I'm overall unsure here, but this does seem as improvement.

The target of STUB might commonly not have good support
for "advanced" features like TCP.

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

Practical example was now in dnstap (060349c9).  This way we detect
such mistakes more often and closer to their point of origin.

Štěpán Balážik authored 4 years ago and Tomas Krizek committed 4 years ago

This patch caps the timeout set on UDP queries to servers chosen in the
EXPLORE phase of the selection algorithm to two times the timeout that
would be set if we were EXPLOITing.

This measns that we no longer spend an unreasonable amount of time
probing servers that are probably dead anyway while ensuring that we do
probe them from time to time to check if they didn't come to life.

If the timeout value is capped and the server fails to respond, we don't
punish the server for it i.e. we don't cache the timeout.

Previously, qry->flags.TCP flag was incorectly set, which led
to incorrect logging and maybe other troubles down the line.

Details are described in code comments.

Switching to TCP instead of querying very slow servers over UDP has had
unwanted side effect – we would sometimes get stuck with a server
permanently switched to TCP. And if the server happens to not reply over
TCP we were in trouble.

Therefore after we TCP connect fails or timeouts we provide one last
chance for the server over UDP. This will not prevent the next request
to try TCP again on this server again, but we don't care because
DNS MUST ******* work over TCP.

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's now consistent with KNOT_RCODE_FORMERR and the official name
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6

It wasn't really used for a long time and became completely obsolete after
!1030.

This way leaves less room for mistakes, etc.  It's just the idea from:
dd0c99bd (comment 191580)

Previously the mitigation would stop some longer benign resolutions.
We can safely zero the subquery counter when choose a concrete transport
for the query (i.e. NS name with known IP address).

Lame delegations are weird, they breed more lame delegations on broken
zones since trying another server from the same set usualy doesn't help.
We force resolution of another NS name in hope of getting somewhere.

Previously a 12B reply with FORMERR would be treated as malformed
creating a need for a workaround (switching off EDNS for every malformed
answer).

Instead copy it from the request's options.

Reasoning: Minimization might have been turned off as a workaround for
broken authoritative servers which doesn't support it. There is no
reason to drop minimization when switching zones when following a CNAME.