daemon refactoring 2018
Current kresd daemon is hard to maintain and extend as we have seen when introducting TLS client during end of 2017 and beginning of 2018.
We need to refactor the daemon to:
-
get rid of copy&pasted code -
split connection handling to smaller functions with proper documentation of conditions -
possibly share connection management between TCP and TLS -
do something about qr_task_step()
in particular https://gitlab.labs.nic.cz/knot/knot-resolver/issues/245 -
prepare structure which can accomodate new features. This is a thought experiment to force us to think about generics, we are not going to implement this list as it is:
-
transport like DTLS -
actual structure of daemon allows to implement this without larger changes
-
-
transports like DNS-over-HTTP -
transports like DNS-over-QUIC -
Highly depends on structure of available QUIC implementations. https://github.com/quicwg/base-drafts/wiki/Implementations Additional research required.
-
-
DNS Transport over TCP - Implementation Requirements -
libuv
doesn't support client-side TCP fast-open. Other requirements have either already been implemented or can be implemented without significant structural changes.
-
-
The edns-tcp-keepalive EDNS0 Option -
no significant changes required
-
-
ability to keep TCP/TLS connections open until we approach limit for number of open connections -
Requies minor refactoring to minimize access time to certain internal structures (qtrie should be used instead of array_t). It must be done anyway. Expected complexity - low. However, profiling is highly recommended.
-
-
passive DNS - ability to send out information about cache misses to some external database -
Complexity depends on the sending strategy; some clarificatoins needed.
-
-
ATR: Additional Truncation Response for Large DNS Response -
Daemon doesn't require changes in existing structures, but it is necessary to add some additional structures. Expected level of complexity - minor up to meduim.
-
-
distributed cache (? multicast); older discussions: https://gitlab.labs.nic.cz/knot/knot-resolver/issues/276 and linked -
it would be better if we made this outside of the daemon
-
-
proper NOTIMP answers for unsupported opcodes and message structures (e.g. when a DNS Stateful Operation is received). #225 -
no significant changes required
-
-
parallel queries #36 -
requires a lot of work
-
-
support for rate-limiting, in some form -
it doesn't belongs to the daemon
-
It is important to keep in mind that some of these features (e.g. ATR) could be solved outside of kresd itself and it might be okay to say "no, this does not fit into the resolver".