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.
-------- 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
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