Failing to bind to IPv6 link local addresses
Knot Resolver 5.4.4 appears to fail to bind to IPv6 link local addresses. This was experienced on an up-to-date Fedora 35 system. The following net.listen()
invocations produce errors:
net.listen(net.diag, 53, { kind = 'dns', freebind = true })
or, directly referencing the link local address for the diag interface:
net.listen('fe80::ae1f:6bff:fe6f:e818', 53, { kind = 'dns', freebind = true })
When asking kresd to listen on the link local address, the service fails to start and the following is observed in the log:
Feb 21 18:35:44 fedora kresd[21349]: [net ] bind to 'fe80::ae1f:6bff:fe6f:e818@53' (UDP): Invalid argument
Feb 21 18:35:44 fedora kresd[21349]: [system] error while loading config: error occurred here
stack traceback:
[C]: in function 'listen'
/etc/knot-resolver/kresd.conf:7: in main chunk
ERROR: net.listen() failed to bind (workdir '/var/lib/knot-resolver')
Feb 21 18:35:44 fedora systemd[1]: kresd@1.service: Main process exited, code=exited, status=1/FAILURE
Feb 21 18:35:44 fedora systemd[1]: kresd@1.service: Failed with result 'exit-code'.
Feb 21 18:35:44 fedora systemd[1]: Failed to start kresd@1.service - Knot Resolver daemon.
Interestingly, an IPv6 wildcard address does not result in the same error (kresd starts up just fine):
net.listen('::', 53, { kind = 'dns', freebind = true })
I was originally intending to configure kresd to listen on several named interfaces (not v4 or v6 subnets) to improve resiliency in the event networks are re-assigned by using net.listen(net.interface_name, ...)
in the config. Unfortunately this does not seem to work as it attempts to listen on the link local, producing an error and preventing the resolver process from starting.
I was initially unsure if IPv6 link local addresses were supported but noticed that #101 (closed) was opened several years ago about IPv6 LL addresses. I noticed that there was an MR referenced so I assume this is still supported? The documentation is not clear but it does not mention a limitation here either.