Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2024-02-28T12:15:39+01:00https://gitlab.nic.cz/knot/knot-resolver/-/issues/535declarative policy module and other user-supplied DNS data2024-02-28T12:15:39+01:00Petr Špačekdeclarative policy module and other user-supplied DNS dataCurrent problem
---------------
Our current imperative policy module is using chain of Lua functions: This is quite slow and hard to use for non-programmers.
Proposal
--------
Design a new method to configure "policies", preferably in a...Current problem
---------------
Our current imperative policy module is using chain of Lua functions: This is quite slow and hard to use for non-programmers.
Proposal
--------
Design a new method to configure "policies", preferably in a declarative way. By "policies" I mean a generic way to influence resolving and inject user-supplied data into DNS tree or block other stuff.
A declarative way should be more intuitive to use than writing Lua functions, and also faster if we design it right.
Here is incomplete list of stuff we might want to express.
- [x] ability to also block sub-queries, e.g. when following CNAMEs (#217)
- [ ] ability to block RR data - e.g. rebinding protection, blacklist of NS names etc. (#523)
- [x] ACLs (including negative ACLs, #370)
- [x] merge views with other policies (see also #445)?
- [x] redirecting specific zones to user-configured servers (#428, !651)
- [ ] beware that we need also port number, not just IP address
- [x] theoretical "helper" NS+glue records from kresd config should not be retrievable from outside
- FORWARDing
- TLS forwarding has many knobs and might need even more: #481
- do we still need STUB policy? If so see #218
- FORWARDing might need exceptions for some subtrees (see e.g. https://lists.nlnetlabs.nl/pipermail/unbound-users/2019-December/006560.html)
- generally special EDNS tricks: #314, #303; also improve #657
- special cache semantics (do not cache this sub-tree, limit TTL in this sub-tree)
- maybe DNS64 module should be merged with policies and ACLs: #368
- [x] maybe hints module should be merged in as well (see also #205, #349)
- [x] maybe also a way to provide other user-supplied data - #540
* (well, more ways can always be added)
- maybe prefill module should be merged as well (see also #417)
- think of interaction with daf module (beware of #183)
* `@vcunat` would prefer to deprecate DAF,
but theoretically we could think of translating DAF rules into the new policy rules
- design should be able to support full strength of RPZ (example of a problem: #194)
* the most common features are in 6.0.x – CNAME redirection in particular, and interacting well with other rules (multiple rules of different kinds can trigger when jumping through CNAME chains)
- design needs to support efficient mechanism which mimicks RPZ with zone transfer including IXFR(!) (#195)
- build mechanism for better visibility into policies (#364)
- it needs to work with huge lists (apparently users want to have long block lists, see https://lists.nlnetlabs.nl/pipermail/unbound-users/2019-December/006559.html)
* improved in 6.0.x: shared inside LMDB across all processes, but efficiency of restarts/reloads/updates could be significantly improved (as of 6.0.6)
- [x] open question: at which stage should the module kick in? Can it be e.g. used to implement `ignore-cd-flag` policy as seen in Unbound?
* the `view:` part can be used to set such options, though there's no ignore-cd in particular so far
- per-domain setting for rate-limits e.g. like `ratelimit-below-domain`, `ratelimit-for-domain` etc. like in Unbound
* [ ] first per-user changes in rate-limits in `views:` (when we have any rate-limiting)
- [x] special handling for reserved and local-only names: see #205 and think it through2020 Q2https://gitlab.nic.cz/knot/knot-resolver/-/issues/537module API redesign2020-11-30T17:52:59+01:00Petr Špačekmodule API redesignProblem statement
-----------------
- Current module API is not well defined and does not provide sufficient abstraction
- As a result, modules are not isolated and must know about internals of other modules (e.g. modules resetting reque...Problem statement
-----------------
- Current module API is not well defined and does not provide sufficient abstraction
- As a result, modules are not isolated and must know about internals of other modules (e.g. modules resetting request state must also reset `req.*_selected` arrays)
- Mixing wire-format-generating modules with modules relying on `req.*_selected` arrays leads to weird bugs (one example: !842, !851, !859)
- Lua modules seem to be slow (because of the way how C code calls Lua?)
Related tickets
---------------
- #363 Modules need generic way to persist own state
- #432 Modules need ability to not respond at all (for response rate limiting)
- #483 Modules currently cannot generate answer if no NS is responding
- #447 New server selection system should expose and use API instead of being hard-wired
- #396 SERVFAIL answer can still contain bogus RRsets
- #471 low-level protocol stuff is hard-coded (incorrectly)
- #36 make sure new API does not get in the way when implementing parallel queries
- #527 modules need a way to cooperate with fine-grained logging
- #418 engine object access - I don't know if this requirement will be still valid after redesign, but let's think about it
- #264 error reporing from modules sucks
- #234 a way to cooperate between modules??? e.g. for DNAME support???
- attempt to move `reorder_RR()` into module, ideally in a form of policy action so it can be triggered on per-client basis - what API would be necessary?
Objective
---------
Design a new API for modules in a way which prevents bugs stemming from bad API usage from ever repeating again.
Implementation is expected to be a long-term project, but we need proper design first. Hopefully #447, #535 and other tasks planned for 2020 will provide us sufficient experience for better API design.2020 Q4https://gitlab.nic.cz/knot/knot-resolver/-/issues/534CI: test server selection algorithm2019-12-18T19:41:28+01:00Petr ŠpačekCI: test server selection algorithmImplement https://gitlab.labs.nic.cz/knot/maze/ into Knot Resolver's CI.
Ideas:
- Gitlab shell executor in a VM with sudo access (yuck!)
- shell executor to a VM with a systemd build which contains https://github.com/systemd/systemd/pul...Implement https://gitlab.labs.nic.cz/knot/maze/ into Knot Resolver's CI.
Ideas:
- Gitlab shell executor in a VM with sudo access (yuck!)
- shell executor to a VM with a systemd build which contains https://github.com/systemd/systemd/pull/138232020 Q1Štěpán BalážikŠtěpán Balážik