9 Bře
2024
9 Bře
'24
15:45
Hi,
I am in the process to migrate from unbound to knot-resolver.
This is on FreeBSD 14-STABLE, knot-resolver 5.7.1, and on a very small instance serving a
handful users, around 100 mails a day and such.
The resolver is up and running, but I still have some questions left I cannot answer
myself after reading the documentation et al.
1) I managed to run 'kres-cache-gc -c /var/run/kresd' but I am unsure whether I do
need the garbage collector at all?
I read that after filling up of '/var/run/kresd/data.mdb' that file would become
reset to 0 bytes, correct?
FYI: After 3 days '/var/run/kresd/data.mdb' uses less than 1 MB currently.
2) Does knot-resolver automatically update 'root.hints' and 'root.keys',
or do I have to install a script in crontab doing the updates instead?
FYI: I didn't unload the modules 'ta_signal_query' and 'ta_sentinel‘
3) I am still struggeling to understand, how to get access to the statistics produced by
the module 'stats'?
FYI: If I do try to use knotc (I know, it's experimental), I'll get:
|dns> kresc /var/run/kresd/control/17158
|Warning! kresc is highly experimental, use at own risk.
|Please tell authors what features you expect from client utility.
|
FYI: There is no 'kresd>' prompt …
I tried to modify that socket's privileges but to no avail.
4) If that socket is the way to get hold on all statistics information, how can one name
that socket file? Currently, it is just the PID of kresd.
Thanks in advance and regards,
Michael
10 Bře
10 Bře
9:21
Hello.
On 09/03/2024 15.45, Michael Grimm via knot-resolver-users wrote:
1) I managed to run 'kres-cache-gc -c
/var/run/kresd' but I am unsure whether I do need the garbage collector at all?
I read that after filling up of '/var/run/kresd/data.mdb' that file would become
reset to 0 bytes, correct?
Yes, when cache fills up completely, it gets reset to empty. So it is
possible to run that way; you'll just temporarily get worse latency
whenever the reset happens.
FYI: After 3 days '/var/run/kresd/data.mdb'
uses less than 1 MB currently.
I expect your DNS traffic isn't very diverse.
2) Does knot-resolver automatically update
'root.hints' and 'root.keys', or do I have to install a script in crontab
doing the updates instead?
That depends on your packaging and configuration. Certainly not
something for crontab. Note that rotation of root keys has only
happened once in the whole history so far. It's a very slow and careful
process.
My preferred way is to use these as read-only files, updated by software
updates. But we also have code for automatic maintenance according to
RFC 5011. I think in the FreeBSD port it's configurable
https://cgit.freebsd.org/ports/tree/dns/knot-resolver/Makefile?id=e8c9d591e…
3) I am still struggeling to understand, how to get
access to the statistics produced by the module 'stats'?
FYI: If I do try to use knotc (I know, it's experimental), I'll get:
|dns> kresc /var/run/kresd/control/17158
|Warning! kresc is highly experimental, use at own risk.
|Please tell authors what features you expect from client utility.
|
FYI: There is no 'kresd>' prompt …
I tried to modify that socket's privileges but to no avail.
kresc was an experiment, incomplete and abandoned years ago. I expect
you could use something like
echo 'tojson(stats.list())' | sudo socat - /var/run/knot-resolver/control/0
but usually people consume it by the prometheus format and then feed it
to whatever they prefer (e.g. grafana).
https://knot-resolver.readthedocs.io/en/stable/modules-stats.html#prometheu…
4) If that socket is the way to get hold on all
statistics information, how can one name that socket file? Currently, it is just the PID
of kresd.
It is possible to change or add these control sockets. It's just
net.listen('path', nil, { kind = 'control' })
Defaults depend on your init scripts, e.g. with systemd it's typically
not named by PID but by service name.
Some of these aspects get improved in versions >= 6.0. Control of the GC
and kresd processes is integrated inside, also stats aggregation and
there's new kresctl command (and user config gets rewritten completely,
from Lua to YAML). But honestly we don't do any BSD ourselves, so I
don't expect you want to package and try it at this point...
--Vladimir
11:20
Hi
Vladimír Čunát via knot-resolver-users <knot-resolver-users(a)lists.nic.cz> wrote:
Thanks, that was new to me.
Cool, that is absolutely sufficient for my purposes, thanks.
Perfect, I just added net.listen('/var/run/kresd/control/kresd.sock', nil, { kind
= 'control' }).
Sorry, I missed that as well.
On 09/03/2024 15.45, Michael Grimm via
knot-resolver-users wrote:
Yes, it isn't. Actually the resolver is bored to death ;-)
I think I can live with very occasionally latency drops, as my cache is set to 100 MB.
1) I managed to run 'kres-cache-gc -c /var/run/kresd' but I am unsure whether I
do need the garbage collector at all?
I read that after filling up of '/var/run/kresd/data.mdb' that file would become
reset to 0 bytes, correct?
Yes, when cache fills up completely, it gets reset to
empty. So it is possible to run that way; you'll just temporarily get worse latency
whenever the reset happens.
FYI: After 3 days
'/var/run/kresd/data.mdb' uses less than 1 MB currently.
I expect your DNS
traffic isn't very diverse. 2) Does
knot-resolver automatically update 'root.hints' and 'root.keys', or do I
have to install a script in crontab doing the updates instead?
That depends on your
packaging and configuration. Certainly not something for crontab. Note that rotation of
root keys has only happened once in the whole history so far. It's a very slow and
careful process. My preferred way is to use these as read-only files,
updated by software updates. But we also have code for automatic maintenance according to
RFC 5011. I think in the FreeBSD port it's configurable
https://cgit.freebsd.org/ports/tree/dns/knot-resolver/Makefile?id=e8c9d591e…
My bad, I should have checked that first. Yes, both options ROOTKEYS and TRUSTANCHOR are
set on default.
Well, then I can omit my crontab settings.
3) I am still
struggeling to understand, how to get access to the statistics produced by the module
'stats'?
FYI: If I do try to use knotc (I know, it's experimental), I'll get:
|dns> kresc /var/run/kresd/control/17158
|Warning! kresc is highly experimental, use at own risk.
|Please tell authors what features you expect from client utility.
|
FYI: There is no 'kresd>' prompt …
I tried to modify that socket's privileges but to no avail.
kresc was an
experiment, incomplete and abandoned years ago. I expect you could use something like
echo 'tojson(stats.list())' | sudo socat - /var/run/knot-resolver/control/0
4) If that
socket is the way to get hold on all statistics information, how can one name that socket
file? Currently, it is just the PID of kresd.
It is possible to change or add these control sockets. It's just
net.listen('path', nil, { kind = 'control' }) Defaults depend on your init scripts, e.g. with
systemd it's typically not named by PID but by service name.
The FreeBSD init script doesn't provide this.
I tried to start the resolver daemon by adding "-S
/var/run/kresd/control/kresd.sock" but to no avail:
Mar 10 10:49:45 <daemon.notice> kresd[32252]: [system] incorrect value passed to
'-S/--fd': /var/run/kresd/control/kresd.sock
[endless loop]
Anyway, as long as the user is able to name the control socket in the config file there is
no need to debug this, IMHO, because of:
Some of these aspects get improved in versions >=
6.0. Control of the GC and kresd processes is integrated inside, also stats aggregation
and there's new kresctl command (and user config gets rewritten completely, from Lua
to YAML). But honestly we don't do any BSD ourselves, so I don't expect you want
to package and try it at this point…
Perhaps I will ;-)
I thank you very much for your invaluable help and kind regards,
Michael
14:05
On 10/03/2024 11.20, Michael Grimm wrote:
I tried to start the resolver daemon by adding
"-S
/var/run/kresd/control/kresd.sock" but to no avail:
Mar 10 10:49:45 <daemon.notice> kresd[32252]: [system] incorrect
value passed to '-S/--fd': /var/run/kresd/control/kresd.sock
[endless loop]
Just for completeness, that option is for passing open system sockets,
e.g. like systemd's socket activation. (which isn't done in our Linux
packaging for years now)
16:40
ne 10. 3. 2024 o 11:20 Michael Grimm via knot-resolver-users
<knot-resolver-users(a)lists.nic.cz> napísal(a):
Yes, it isn't. Actually the resolver is bored to death ;-)
I think I can live with very occasionally latency drops, as my cache is set to 100 MB.
Just to note: also take into the account the default value 1 day for
cache.max_ttl parameter.
FYI: After 3 days '/var/run/kresd/data.mdb'
uses less than 1 MB currently.
I expect your DNS traffic isn't very diverse.
11 Bře
11 Bře
11:13
Blažej Krajňák <blazej.krajnak(a)gmail.com> wrote:
ne 10. 3. 2024 o 11:20 Michael Grimm via
knot-resolver-users
<knot-resolver-users(a)lists.nic.cz> napísal(a):
Yes, it isn't. Actually the resolver is bored to death ;-)
I think I can live with very occasionally latency drops, as my cache is set to 100 MB.
Just to note: also take into the account the default value 1 day for
cache.max_ttl parameter.
Thanks for this information.
I reduced my cache to 50 MB and removed the garbage collector.
I do have the feeling that in my case, a crontab midnight entry a la "service kresd
stop ; rm /var/run/kresd/data.mdb ; service kresd start" should work as a garbage
collector process as well. Although, a very brute force one ;-)
Regards,
Michael
FYI: After 3 days '/var/run/kresd/data.mdb'
uses less than 1 MB currently.
I expect your DNS traffic isn't very diverse.
16 Bře
16 Bře
14:18
New subject: knot-resolver-v6.0.6 , FreeBSD (was: Newbie questions regarding knot-resolver)
Michael Grimm via knot-resolver-users <knot-resolver-users(a)lists.nic.cz> wrote:
I did give it a try, knot-resolver-v6.0.6 [1], created a local port, stole the Makefile
from knot-resolver (5.7.1), and failed further down meson.build ...
Questions:
#) is the the right mailing list to report this?
#) is it to early in the development process to start porting it to FreeBSD?
FYI: I do have more spare time then knowledge of meson and lua, though ;-)
Regards,
Michael
[1] downloader tarball from https://gitlab.nic.cz/knot/knot-resolver/-/tags
Vladimír Čunát via knot-resolver-users
<knot-resolver-users(a)lists.nic.cz> wrote:
Some of these
aspects get improved in versions >= 6.0. Control of the GC and kresd processes is
integrated inside, also stats aggregation and there's new kresctl command (and user
config gets rewritten completely, from Lua to YAML). But honestly we don't do any BSD
ourselves, so I don't expect you want to package and try it at this point…
Perhaps I will ;-)
22 Bře
22 Bře
20:35
New subject: knot-resolver-v6.0.6
Michael Grimm via knot-resolver-users <knot-resolver-users(a)lists.nic.cz> wrote:
I did give it a try, knot-resolver-v6.0.6 [1], created a local port, stole the Makefile
from knot-resolver (5.7.1), and failed further down meson.build ...
FYI: In the meantime I succeeded in compiling knot-resolver-v6.0.7 as of today's
commit:
MWN> git log -1mer-waases|root> git log -1
commit 561b40762ea45a6332a0b108b19f1649b5a5cfd7 (HEAD -> 6.0, origin/HEAD, origin/6.0)
A local knot-resolver-current port is up compiling knot-resolver-v6.0.7 and handling all
possible dependencies.
kresd is up and running fine.
BUT:
1) I needed to patch
'manager/knot_resolver_manager/kresd_controller/supervisord/plugin/notifymodule.c'
to complete successful compilation.
2) The reason is FreeBSD's different structures and credentials regarding sockets.
3) I don't know if I did this in a proper way.
4) I cannot test that socket patched in 1), yet, because I cannot get kresctl run (python
modules loading or ...?)
5) But I can use knotc-5.7.1 to retrieve statistics from a socket defined by:
'net.listen('/var/run/kresd/control/kresd.sock', nil, { kind =
'control' })',
but I don't know if that patch in 1) addresses the very same socket and if my test
is relevant at all?
That patch mentioned in 1) addresses:
#) include sys/ucred.h
#) use LOCAL_PEERCRED instead of SO_PASSCRED
#) use 'struct xucred' instead of 'struct ucred'
#) use SCM_CREDS instead of SCM_CREDENTIALS
#) use cred.cr_pid instead of cred.pid as returned value
If you are interested in getting hold on a 'git diff' patch, please let me know
how (mail, git).
Regards,
Michael
Michael Grimm via knot-resolver-users <knot-resolver-users(a)lists.nic.cz> wrote:
> Vladimír Čunát via knot-resolver-users <knot-resolver-users(a)lists.nic.cz>
wrote:
Some of these aspects get improved in versions >=
6.0. Control of the GC and kresd processes is integrated inside, also stats aggregation
and there's new kresctl command (and user config gets rewritten completely, from Lua
to YAML). But honestly we don't do any BSD ourselves, so I don't expect you want
to package and try it at this point…
Perhaps I will ;-)
47
days inactive
60
days old
knot-resolver-users@lists.nic.cz
7 comments
3 participants
participants (3)
-
Blažej Krajňák -
Michael Grimm -
Vladimír Čunát