Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2020-11-30T17:52:59+01:00https://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 Q4