Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2022-07-18T10:01:11+02:00https://gitlab.nic.cz/knot/knot-resolver/-/issues/752Protocol layers2022-07-18T10:01:11+02:00Oto ŠťávaProtocol layersSee snippet $1448See snippet $1448https://gitlab.nic.cz/knot/knot-resolver/-/issues/651dnstap module spawns a thread2020-12-07T11:00:36+01:00Vladimír Čunátvladimir.cunat@nic.czdnstap module spawns a threadThat's not consistent with kresd architecture, though I can't think of a particular reason why it might cause a problem. Note that this thread will get spawned for each kresd process, so it might be a bit wasteful.
We might prefer to r...That's not consistent with kresd architecture, though I can't think of a particular reason why it might cause a problem. Note that this thread will get spawned for each kresd process, so it might be a bit wasteful.
We might prefer to rewrite the module by utilizing the shared libuv loop (to know when socket is ready to receive more data), but maybe the [fstrm tools](https://farsightsec.github.io/fstrm/overview.html) don't provide good support for that. If we drop the thread, this library might not be worth depending on anymore (as the framing is trivial).https://gitlab.nic.cz/knot/knot-resolver/-/issues/638[discussion] cache backend redesign2020-12-04T16:34:21+01:00Petr Špaček[discussion] cache backend redesignLet's discuss problems we have with current LMDB-based cache backend. We need to analyze if these are fixable or we need to redesign cache backend.
Problems with LMDB itself
- Database overfill leads to irrecoverable state where while D...Let's discuss problems we have with current LMDB-based cache backend. We need to analyze if these are fixable or we need to redesign cache backend.
Problems with LMDB itself
- Database overfill leads to irrecoverable state where while DB practically becomes read only and the only ways forward are either enlarge database or delete it. Together with inability to detect if committing a transaction will lead to this state prevents us from reliably keeping cache with constant size, leading to race conditions in overflow handling etc. (#605)
- Transactions have [undefined limits](https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/message/VI7K5NWV46J6DACITXVS7X2SM3HZIXVB/) on them, forcing us to [jump through hoops](https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1042/diffs?commit_id=c651fbf24017f26435b86e69e9ce73c7f5976b97).
- LMDB depends on unique PID values - this assumption does not hold when sharing cache across containers (#637).
Other cache-related problems: #602, #604https://gitlab.nic.cz/knot/knot-resolver/-/issues/621always keep RRSIG and its RRset in single data structure2020-10-07T18:04:01+02:00Petr Špačekalways keep RRSIG and its RRset in single data structureProblem: At the moment RRset and its RRSIG are two independent `knot_rrset_t` structures.
This leads to problems like !1072 where things get mixed and weird things happen after that.
Idea: Refactor code so RRset is always tied to all as...Problem: At the moment RRset and its RRSIG are two independent `knot_rrset_t` structures.
This leads to problems like !1072 where things get mixed and weird things happen after that.
Idea: Refactor code so RRset is always tied to all associated RRSIGs (multiple of them!).
Investigation how this could be done in most efficient way is needed.
Maybe this approach could be beneficial also to libknot/Knot DNS so let's not forget to talk to them.
Cc @lpeltan @dsalzman and gang.https://gitlab.nic.cz/knot/knot-resolver/-/issues/605cache: explore better ways to detect cache changes made by other processes2020-11-04T11:53:32+01:00Petr Špačekcache: explore better ways to detect cache changes made by other processeskresd 5.2.0 does periodic check which might take too long on very busy systems. Maybe we could use some event-based mechanism?
See [discussion](https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1042#note_168310).
The following ...kresd 5.2.0 does periodic check which might take too long on very busy systems. Maybe we could use some event-based mechanism?
See [discussion](https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1042#note_168310).
The following discussion from !1042 should be addressed:
- [ ] @pspacek started a [discussion](https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1042#note_168310): (+1 comment)
> Why not use https://docs.libuv.org/en/v1.x/guide/filesystem.html#file-change-events ?https://gitlab.nic.cz/knot/knot-resolver/-/issues/459maintenance daemon2022-05-08T12:13:54+02:00Petr Špačekmaintenance daemonKnot Resolver has bunch of tasks which need to be done only once, so it does not make much sense to do them from all workers independently.
Examples:
- [x] cache cleanup - #257
- [ ] cache import - `zimport` into cache
- [ ] TLS certif...Knot Resolver has bunch of tasks which need to be done only once, so it does not make much sense to do them from all workers independently.
Examples:
- [x] cache cleanup - #257
- [ ] cache import - `zimport` into cache
- [ ] TLS certificate maintenance (DNS-over-TLS, HTTP module)
- [ ] TLS ticket rotation
- [ ] RFC 5011
- [ ] TA bootstrap
... and possibly others.
In long term we might create a "maintenance" daemon which could take care of these tasks so they would not block worker threads (it would also avoid duplication of tasks).
This would require means to communicate between maintenance daemon and workers.https://gitlab.nic.cz/knot/knot-resolver/-/issues/455ugly uv_foo_t * casts all over the place2019-03-12T12:47:18+01:00Vladimír Čunátvladimir.cunat@nic.czugly uv_foo_t * casts all over the placeThe following discussion from !786 should be addressed:
- [ ] @pspacek started a [discussion](https://gitlab.labs.nic.cz/knot/knot-resolver/merge_requests/786#note_100831): (+2 comments)
> Wondering out loud: Would it be nicer if ...The following discussion from !786 should be addressed:
- [ ] @pspacek started a [discussion](https://gitlab.labs.nic.cz/knot/knot-resolver/merge_requests/786#note_100831): (+2 comments)
> Wondering out loud: Would it be nicer if we used union for this? That would avoid explicit retyping all over the place ...https://gitlab.nic.cz/knot/knot-resolver/-/issues/326Use connected UDP sockets for outgoing queries2019-04-02T17:26:25+02:00Marek VavrusaUse connected UDP sockets for outgoing queriesIt'd be nice to use connected UDP sockets for outgoing queries as it makes it a little bit harder to spoof, and a bit more efficient as kernel can discard dgrams from different source addresses than the connected one.
Currently libuv do...It'd be nice to use connected UDP sockets for outgoing queries as it makes it a little bit harder to spoof, and a bit more efficient as kernel can discard dgrams from different source addresses than the connected one.
Currently libuv doesn't have a facility for connected UDP sockets, so I'm creating the issue to track this when it gets it: https://github.com/libuv/leps/pull/10https://gitlab.nic.cz/knot/knot-resolver/-/issues/291refactor excessively long functions2018-12-17T13:29:42+01:00Marek Vavrusarefactor excessively long functionsFor readability's sake, we should refactor functions so that they're reasonably short.
The screen size is ~80 lines, some functions are >300 lines, which makes it easier to make mistakes.
The !432 added an upper bound limit of 400 statem...For readability's sake, we should refactor functions so that they're reasonably short.
The screen size is ~80 lines, some functions are >300 lines, which makes it easier to make mistakes.
The !432 added an upper bound limit of 400 statements / 500 lines, but we should do better.
These functions exceed the 200 statements / 300 lines limit:
* [ ] layer/validate.c:824 function 'validate' 337 statements (threshold 200)
* [ ] resolve.c:1310 function 'kr_resolve_produce' 250 statements (threshold 200)
* [x] worker.c:1406 function 'qr_task_step' 221 statements (threshold 200)
* [x] worker.c:1872 function 'worker_process_tcp' 260 statements (threshold 200)
* [ ] main.c:425 function 'main' 247 statements (threshold 200)https://gitlab.nic.cz/knot/knot-resolver/-/issues/262simplify DNS64 code2017-10-22T14:25:03+02:00Petr Špačeksimplify DNS64 codeNew code introduced in #203 seems ugly because it introduced FFI spaghetti into DNS64 module. When you have some time, we should refactor that so it is readable again.New code introduced in #203 seems ugly because it introduced FFI spaghetti into DNS64 module. When you have some time, we should refactor that so it is readable again.