1 Říj
2017
1 Říj
'17
23:26
Hello,
one more question:
What is the proper way of autostarting Knot Resolver 1.4.0 on systemd (Debian Stretch in
my case) to be able to listen on interfaces other from localhost?
As per the Debian README I've set up the socket override.
# systemctl edit kresd.socket:
[Socket]
ListenStream=<my.lan.ip>:53
ListenDatagram=<my.lan.ip>:53
However after reboot the service doesn't autostart.
# systemctl status kresd.service
kresd.socket - Knot DNS Resolver network listeners
Loaded: loaded (/lib/systemd/system/kresd.socket; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/kresd.socket.d
└─override.conf
Active: failed (Result: resources)
Docs: man:kresd(8)
Listen: [::1]:53 (Stream)
[::1]:53 (Datagram)
127.0.0.1:53 (Stream)
127.0.0.1:53 (Datagram)
<my.lan.ip>:53 (Stream)
<my.lan.ip>:53 (Datagram)
Oct 01 23:17:12 <myhostname> systemd[1]: kresd.socket: Failed to listen on sockets:
Cannot assign requested address
Oct 01 23:17:12 <myhostname> systemd[1]: Failed to listen on Knot DNS Resolver
network listeners.
Oct 01 23:17:12 <myhostname> systemd[1]: kresd.socket: Unit entered failed state.
To get it running I have to type in manually:
# systemctl start kresd.socket
I apologize, I am now to systemd and its socket activation so it's not clear to me
whether service or socket or both have to be somehow set up to autostart or not.
Could anyone clarify this?
Also, this is also in the log (again, Debian default):
Oct 01 23:18:22 <myhostname> kresd[639]: [ ta ] keyfile
'/usr/share/dns/root.key': not writeable, starting in unmanaged mode
The file has permissions 644 for root:root. Should this be owned by knot, or writeable by
others?
Thanks!
--
Regards,
Thomas Van Nuit
Sent with [ProtonMail](https://protonmail.com) Secure Email.
1 Říj
1 Říj
23:34
On 10/01/2017 11:26 PM, Thomas Van Nuit wrote:
What is the proper way of autostarting Knot Resolver
1.4.0 on systemd
(Debian Stretch in my case) to be able to listen on interfaces other
from localhost?
[...]
Oct 01 23:17:12 <myhostname> systemd[1]: kresd.socket: Failed to
listen on sockets: Cannot assign requested address
Oct 01 23:17:12 <myhostname> systemd[1]: Failed to listen on Knot DNS
Resolver network listeners.
Oct 01 23:17:12 <myhostname> systemd[1]: kresd.socket: Unit entered
failed state.
I'm not sure immediately. My first guess would be that either the
address is wrong (i.e. not assigned to this machine), or some other
daemon is already listening on that IP:port combination.
Also, this is also in the log (again, Debian
default):
Oct 01 23:18:22 <myhostname> kresd[639]: [ ta ] keyfile
'/usr/share/dns/root.key': not writeable, starting in unmanaged mode
The file has permissions 644 for root:root. Should this be owned by
knot, or writeable by others?
In general, it depends on how you want to update the root.key. In
Debian it's within a package by default, and therefore it's read-only
and updates are left to on the package system. Another way is to have a
writable file and let kresd manage it according to RFC 5011.
--Vladimir
6 Říj
6 Říj
20:21
Hello,
thank you for your reply.
The IP is definitely correct and there isn't anything else installed on the system,
only Knot Resolver.
After a few reboots I've observed that sometimes the service starts OK, sometimes it
fails. Is it possible that there is some sort of race condition?
First I thought it's with systemd-resolved, which I disabled. But that didn't
help. I have to manually start kresd.socket again to get it working. After disabling the
systemd-resolved there was nothing else listening on ports 53 (TCP or UDP), the error was
the same.
Since no one else in this mailing list seems to have this problem I must be missing
something elementary.
Thanks!
--
Regards,
Thomas Van Nuit
Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------- Original Message --------
Subject: Re: [knot-dns-users] Knot Resolver autostart on systemd
Local Time: October 1, 2017 11:34 PM
UTC Time: October 1, 2017 9:34 PM
From: vladimir.cunat(a)nic.cz
To: Thomas Van Nuit <thomasvannuit(a)protonmail.ch>
knot-dns-users(a)lists.nic.cz <knot-dns-users(a)lists.nic.cz>
On 10/01/2017 11:26 PM, Thomas Van Nuit wrote:
What is the proper way of autostarting Knot
Resolver 1.4.0 on systemd (Debian Stretch in my case) to be able to listen on interfaces
other from localhost?
[...]
Oct 01 23:17:12 <myhostname> systemd[1]: kresd.socket: Failed to listen on sockets:
Cannot assign requested address
Oct 01 23:17:12 <myhostname> systemd[1]: Failed to listen on Knot DNS Resolver
network listeners.
Oct 01 23:17:12 <myhostname> systemd[1]: kresd.socket: Unit entered failed state.
I'm not sure immediately. My first guess would be that either the address is wrong
(i.e. not assigned to this machine), or some other daemon is already listening on that
IP:port combination.
Also, this is also in the log (again, Debian
default):
Oct 01 23:18:22 <myhostname> kresd[639]: [ ta ] keyfile
'/usr/share/dns/root.key': not writeable, starting in unmanaged mode
The file has permissions 644 for root:root. Should this be owned by knot, or writeable by
others?
In general, it depends on how you want to update the root.key. In Debian it's within
a package by default, and therefore it's read-only and updates are left to on the
package system. Another way is to have a writable file and let kresd manage it according
to RFC 5011.
--Vladimir 
21:51
When it's not starting is there anything else listening on UDP or TCP port
53?
Did you tweak the configuration or is it running on default config?
Ondřej
On Fri, 6 Oct 2017, 20.21 Thomas Van Nuit, <thomasvannuit(a)protonmail.ch>
wrote:
Hello,
thank you for your reply.
The IP is definitely correct and there isn't anything else installed on
the system, only Knot Resolver.
After a few reboots I've observed that sometimes the service starts OK,
sometimes it fails. Is it possible that there is some sort of race
condition?
First I thought it's with systemd-resolved, which I disabled. But that
didn't help. I have to manually start kresd.socket again to get it working.
After disabling the systemd-resolved there was nothing else listening on
ports 53 (TCP or UDP), the error was the same.
Since no one else in this mailing list seems to have this problem I must
be missing something elementary.
Thanks!
--
Regards,
Thomas Van Nuit
Sent with ProtonMail <https://protonmail.com> Secure Email.
-------- Original Message --------
Subject: Re: [knot-dns-users] Knot Resolver autostart on systemd
Local Time: October 1, 2017 11:34 PM
UTC Time: October 1, 2017 9:34 PM
From: vladimir.cunat(a)nic.cz
To: Thomas Van Nuit <thomasvannuit(a)protonmail.ch>
knot-dns-users(a)lists.nic.cz <knot-dns-users(a)lists.nic.cz>
On 10/01/2017 11:26 PM, Thomas Van Nuit wrote:
What is the proper way of autostarting Knot Resolver 1.4.0 on systemd
(Debian Stretch in my case) to be able to listen on interfaces other from
localhost?
[...]
Oct 01 23:17:12 <myhostname> systemd[1]: kresd.socket: Failed to listen on
sockets: Cannot assign requested address
Oct 01 23:17:12 <myhostname> systemd[1]: Failed to listen on Knot DNS
Resolver network listeners.
Oct 01 23:17:12 <myhostname> systemd[1]: kresd.socket: Unit entered failed
state.
I'm not sure immediately. My first guess would be that either the address
is wrong (i.e. not assigned to this machine), or some other daemon is
already listening on that IP:port combination.
Also, this is also in the log (again, Debian default):
Oct 01 23:18:22 <myhostname> kresd[639]: [ ta ] keyfile
'/usr/share/dns/root.key': not writeable, starting in unmanaged mode
The file has permissions 644 for root:root. Should this be owned by knot,
or writeable by others?
In general, it depends on how you want to update the root.key. In Debian
it's within a package by default, and therefore it's read-only and updates
are left to on the package system. Another way is to have a writable file
and let kresd manage it according to RFC 5011.
--Vladimir
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
--
Ondřej Surý <ondrej(a)sury.org>
21:54
One more thing - could you try adding
After=network-online.target
to kresd.socket?
Ondřej
On Fri, 6 Oct 2017, 21.51 Ondřej Surý, <ondrej(a)dns.rocks> wrote:
When it's not starting is there anything else
listening on UDP or TCP port
53?
Did you tweak the configuration or is it running on default config?
Ondřej
On Fri, 6 Oct 2017, 20.21 Thomas Van Nuit, <thomasvannuit(a)protonmail.ch>
wrote:
--
Ondřej Surý <ondrej(a)sury.org>
Hello,
thank you for your reply.
The IP is definitely correct and there isn't anything else installed on
the system, only Knot Resolver.
After a few reboots I've observed that sometimes the service starts OK,
sometimes it fails. Is it possible that there is some sort of race
condition?
First I thought it's with systemd-resolved, which I disabled. But that
didn't help. I have to manually start kresd.socket again to get it working.
After disabling the systemd-resolved there was nothing else listening on
ports 53 (TCP or UDP), the error was the same.
Since no one else in this mailing list seems to have this problem I must
be missing something elementary.
Thanks!
--
Regards,
Thomas Van Nuit
Sent with ProtonMail <https://protonmail.com> Secure Email.
-------- Original Message --------
Subject: Re: [knot-dns-users] Knot Resolver autostart on systemd
Local Time: October 1, 2017 11:34 PM
UTC Time: October 1, 2017 9:34 PM
From: vladimir.cunat(a)nic.cz
To: Thomas Van Nuit <thomasvannuit(a)protonmail.ch>
knot-dns-users(a)lists.nic.cz <knot-dns-users(a)lists.nic.cz>
On 10/01/2017 11:26 PM, Thomas Van Nuit wrote:
What is the proper way of autostarting Knot Resolver 1.4.0 on systemd
(Debian Stretch in my case) to be able to listen on interfaces other from
localhost?
[...]
Oct 01 23:17:12 <myhostname> systemd[1]: kresd.socket: Failed to listen
on sockets: Cannot assign requested address
Oct 01 23:17:12 <myhostname> systemd[1]: Failed to listen on Knot DNS
Resolver network listeners.
Oct 01 23:17:12 <myhostname> systemd[1]: kresd.socket: Unit entered
failed state.
I'm not sure immediately. My first guess would be that either the
address is wrong (i.e. not assigned to this machine), or some other daemon
is already listening on that IP:port combination.
Also, this is also in the log (again, Debian default):
Oct 01 23:18:22 <myhostname> kresd[639]: [ ta ] keyfile
'/usr/share/dns/root.key': not writeable, starting in unmanaged mode
The file has permissions 644 for root:root. Should this be owned by knot,
or writeable by others?
In general, it depends on how you want to update the root.key. In Debian
it's within a package by default, and therefore it's read-only and updates
are left to on the package system. Another way is to have a writable file
and let kresd manage it according to RFC 5011.
--Vladimir
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
--
Ondřej Surý <ondrej(a)sury.org>
7 Říj
7 Říj
0:09
On Fri 2017-10-06 19:54:19 +0000, Ondřej Surý wrote:
One more thing - could you try adding
After=network-online.target
to kresd.socket?
Alternately, could you try adding the following directive to your
kresd.socket override?
FreeBind=true
from systemd.socket(5):
FreeBind=
Takes a boolean value. Controls whether the socket can be bound to
non-local IP addresses. This is useful to configure sockets
listening on specific IP addresses before those IP addresses are
successfully configured on a network interface. This sets the
IP_FREEBIND socket option. For robustness reasons it is recommended
to use this option whenever you bind a socket to a specific IP
address. Defaults to false.
Regards,
--dkg
21:11
On 6. Oct 2017, at 20:21, Thomas Van Nuit
<thomasvannuit(a)protonmail.ch> wrote:
After a few reboots I've observed that sometimes the service starts OK, sometimes it
fails. Is it possible that there is some sort of race condition?
From memory "Cannot assign requested address” is when you try to bind to an IP that
isn’t local - so maybe the race condition is between whatever configures your interfaces
and what I starting knot? Presumably there will be a dependency you can declare for knot
to make sure that it doesn’t start before interfaces are up.
HTH,
Andrew
8 Říj
8 Říj
11:33
Hello everyone,
thanks for all the replies!
When it's not starting is there anything else
listening on UDP or TCP port 53? No, it's not.
Did you tweak the configuration or is it running on
default config? My config was:
net = { '127.0.0.1', '::1',
<my.lan.ip> }
user('knot-resolver','knot-resolver')
cache.size = 4 * GB
modules = { 'stats' }
verbose(false)
I set up net directive according
to:http://knot-resolver.readthedocs.io/en/stable/daemon.html#network-configuration
I've since removed the net directive since I assumed that with socket activation,
it's not necessary to specify addresses within the service but rather within the
socket.
FreeBind=true
This one helped, thanks!
I've rebooted a few times and so far kresd started in 100% cases.
Should I also try 'After=network-online.target' instead of FreeBind? And if it
helps, which of those two is a more proper way to handling this issue?
Thanks again!
--
Regards,
Thomas Van Nuit
Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------- Original Message --------
Subject: Re: [knot-dns-users] Knot Resolver autostart on systemd
Local Time: October 7, 2017 9:11 PM
UTC Time: October 7, 2017 7:11 PM
From: andrew(a)ugh.net.au
To: Thomas Van Nuit <thomasvannuit(a)protonmail.ch>
knot-dns-users(a)lists.nic.cz <knot-dns-users(a)lists.nic.cz>
On 6. Oct 2017, at 20:21, Thomas Van Nuit
<thomasvannuit(a)protonmail.ch> wrote:
After a few reboots I"ve observed that sometimes the service starts OK, sometimes it
fails. Is it possible that there is some sort of race condition?
From memory "Cannot assign requested address” is when you try to bind to an IP that
isn’t local - so maybe the race condition is between whatever configures your interfaces
and what I starting knot? Presumably there will be a dependency you can declare for knot
to make sure that it doesn’t start before interfaces are up.
HTH,
Andrew
9 Říj
9 Říj
17:08
On Sun 2017-10-08 05:33:47 -0400, Thomas Van Nuit wrote:
I think FreeBind=true is a marginally safer choice than
After=network-online.target, but only because it closes a small race
window -- that is, if you bind to the address before the network comes
up (or indeed, as soon as anything is bound on the system, while PID 1
is still in the process of setting up all of its sockets) then no other
process will be able to grab the ports in question.
if instead you wait until the network-online.target is ready, then any
process that is run *before* that point with the CAP_NET_BIND_SERVICE
can potentially collide with the port you'd rather have kresd use.
--dkg
FreeBind=true
This one helped, thanks!
I've rebooted a few times and so far kresd started in 100% cases.
Should I also try 'After=network-online.target' instead of FreeBind?
And if it helps, which of those two is a more proper way to handling
this issue?
18:16
On 10/09/2017 05:08 PM, Daniel Kahn Gillmor wrote:
On Sun 2017-10-08 05:33:47 -0400, Thomas Van Nuit
wrote:
One tiny disadvantage I can see about FreeBind: if you e.g. make a typo
in IP, I expect the service will just *seem* OK, but it won't do what
you expected. Still, any serious deployment will probably have checks
for the service from outside, ideally from a different machine.
--Vladimir
> FreeBind=true
> Should I also try 'After=network-online.target' instead of FreeBind?
> And if it helps, which of those two is a more proper way to handling
> this issue?
I think FreeBind=true is a marginally safer choice than
After=network-online.target, [...]
2413
days inactive
2421
days old
9 comments
5 participants
participants (5)
-
Andrew Stevenson -
Daniel Kahn Gillmor -
Ondřej Surý -
Thomas Van Nuit -
Vladimír Čunát