| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
|
| |\|
| | |
| | |
| | |
| | | |
This is the last commit in `6.0` before it is shifted into `master`,
with 5.x support being moved to `master-5`.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit makes lots of changes to the C code to appease the
Clang-Tidy linter. Some of the less obvious ones are due to C's weird
semantics regarding handling of numeric literals.
We also disable a bunch of the detections because they are
super-pedantic, arguably useless, or we have our own unwritten coding
style rules that solve the issues.
|
| |\|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- some knot_wire_next_label() calls were added since master,
so those get changed as in a083f3fe63cffbabb19e6b67848151f4bb6d623c
- some code has moved since master (to lib/resolve-produce.c),
and unfortunately the MR !1509 did change some of it,
and git was unable to handle this automatically
This merge commit is separate, only bringing !1509 and no other
changes from master, so that it's easier to understand.
|
| | |
| | |
| | |
| | |
| | | |
knot_wire_next_label used to return NULL when applied to . (root)
but that's not allowed anymore, and some of our calls relied on that.
|
| | |
| | |
| | |
| | | |
knot_wire_next_label isn't allowed with NULL wire anymore.
|
|\ \ \ |
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| / /
| |/ / |
|
| |\| |
|
| | |
| | |
| | |
| | |
| | | |
The issue was exposed when working on rrl-wip branch:
lib/dnssec/nsec.c:19:10: fatal error: resolve.h: No such file or director
|
| | | |
|
| | |
| | |
| | |
| | | |
The check for name equality didn't cover the case of repeated SOA.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The file is sparse, which really is supported by all sane filesystems
nowadays I think. But for 32-bit systems I'm a bit afraid for the
ability to reliably get such a large contiguous mapping in process memory,
so there we take the 500M limit tested in knot-dns:
https://gitlab.nic.cz/knot/knot-dns/-/blob/v3.3.5/src/knot/conf/schema.c#L39
|
| |\| |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Ideally we would've done that at once with increasing NSEC3 strictness,
i.e. in 5.7.1 + 6.0.6, as otherwise we could run into some recoverable
assertions until the records got removed or expired.
We at least do the bump now.
|
| | |
| | |
| | |
| | | |
It was no longer correct after commit cc5051b444130 (KeyTrap).
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The spec even requires (at least one) NS record in apex
https://datatracker.ietf.org/doc/html/draft-vixie-dns-rpz-00#section-2
but until now the implementation took it as override for the root NS,
which obviously broke resolution (depending on the supplied name/s).
|
| | |
| | |
| | |
| | |
| | | |
No idea why it started causing issues now and for me, with:
lib/dnssec/nsec.c:19:10: fatal error: resolve.h: No such file or director
|
|/ / |
|
| |
| |
| |
| | |
Fix cross-references, heading levels, etc.
|
| |
| |
| |
| | |
Suggested by Libor Peltan.
|
| |
| |
| |
| |
| |
| |
| |
| | |
- The "ksk" and "zsk" in names were confusing,
as they did NOT match the normal terms of KSK and ZSK.
- Add _usable() as a more useful function than _zsk() was.
- don't use 16-bit flag-sets; it's way easier to extract on byte level
- use inline for the simplified code
|
| | |
|
|\ \ |
|
| |\|
| | |
| | |
| | |
| | |
| | | |
There were some nontrivial conflicts to resolve, NEWS + the line
ctx->vld_limit_crypto = KR_VLD_LIMIT_CRYPTO_DEFAULT;
(I had this resolution prepared for a long time.)
|
| | |
| | |
| | |
| | | |
Improve: don't retry in this case.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Keep the first error in case priorities are equal.
At least with the current KeyTrap topic that should work better,
but blaming a single error is alchemy anyway, at least in some cases.
|
| | | |
|
| | |
| | |
| | |
| | | |
The value is in IANA registry, so it's very constant anyway.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
That's when searching NSEC3 aggressive cache.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Limit combination of iterations and salt length, based on estimated
expense of the computation. Note that the result only differs for
salt length > 44 which is rather nonsensical and very rare:
https://chat.dns-oarc.net/community/pl/h58qx9sjkbgt9dajb7x988p78a
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Also done by BIND9 >= 9.19.19:
https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8515
The latest real-life measurements show that values above 50 are rare:
https://chat.dns-oarc.net/community/pl/aadp9wwrp7g7ux1b8chbzebmze
|
|/ /
| |
| |
| |
| | |
- only with libknot >= 3.4 though (which is not released yet)
- use stack instead of static buffer (saves RAM; see code comment)
|
| |
| |
| |
| |
| | |
This extends the new 5.x commit 673c8d2b56b6.
Now I can build fine against knot-dns master again.
|
|\| |
|
| |
| |
| |
| |
| | |
I'm adding this as a function, as in knot-resolver 6.x we have
one more place where it is used, and I find this more readable.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Replaces all mentions of `knot-resolver.readthedocs.io` with
`www.knot-resolver.cz/documentation/latest`.
Some of the links used to point to the `latest` documentation, which
meant the latest `master` commit, but the current system does not really
allow us to do this, so instead we link to the latest stable (which is
what `www.knot-resolver.cz/documentation/latest` basically is).
We also cannot reliably get the documentation for a particular version
in the code, so it all just points to `latest` as well. This may change
in the future, although I do not yet have a good approach in mind
(particularly, I don't want to bother our admins with nginx
configuration updates for each newly released version).
|
| |
| |
| |
| |
| | |
Now that manager is integrated into kresd,
I expect these will naturally keep it in sync.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This filtering was dropped in 4565cc596680 (v5.3.0).
Now it's reintroduced - but inside the function, as that seems nicer.
Nit: naming and comment were updated to fit the current usage.
As the code is designed so far (in whole history probably), in order
to detect whether we need to choose a zone cut closer to the root,
we need to do something like this in lib/zonecut.c already,
instead of just during server selection.
I don't think this change can break anything.
Fetching unusable addresses from cache seems pointless,
as selection wouldn't be allowed to use them or try resolving them.
|
| |
| |
| |
| | |
It seems such an edge case that I chose to avoid the issue this way.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Examples:
- tagging based on dst_subnet is useful for providing different
filtering setting on different resolver addresses
- tagging based on protocols is useful to signal used transport
(change in DNS data that can be read by the final app)
(docs added in a later commit)
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This doesn't yet search among the multiple values.
The rules/api parts that write rules were adapted or commented on.
|