Description of problem: Unit file for named/named-chroot can allow daemon to start before the network is ready. If named is configured to bind to a specific IP, this will cause startup to fail. Version-Release number of selected component (if applicable): bind-chroot-9.18.14-1.fc38.x86_64 I am using the bind-chroot package, but I believe the non-chroot unit file has the same problem How reproducible: 100% Steps to Reproduce: 1. systemctl enable named-chroot 2. add 'query-source <server IP>;' to named.conf options {}; section 3. reboot Actual results: After reboot, 'systemctl status bind-chroot' shows "Active: failed" with the following errors logged: named[650]: could not get query source dispatcher (192.168.0.11#0) named[650]: loading configuration: address not available named[650]: exiting (due to fatal error) systemd[1]: named-chroot.service: Control process exited, code=exited, status=1/FAILURE systemd[1]: named-chroot.service: Killing process 651 (named) with signal SIGKILL. systemd[1]: named-chroot.service: Failed with result 'exit-code'. systemd[1]: Stopped named-chroot.service - Berkeley Internet Name Domain (DNS). Expected results: named running Additional info: It appears that adding: Wants: network-online.target After: network-online.target to the unit file will fix this problem
Yes, that is known problem. named can detect listening sockets being available later and listen on them. But if you instruct query-source to specific address, it has to start after that address is available. Unlike addresses in listen-on {} clauses those have to be available when it is starting to do root priming queries. So it cannot postpone them. At the same time, named might be under some configurations required to reach network-online.target, so configuring named start later in all cases is not possible. Please use just systemctl edit named-chroot.service as part of your configuration. query-source requires that and I do not think there is possible way to solve that. Yes, even named.service has exactly the same problem. Just include in editor: [Unit] Wants: network-online.target After: network-online.target I think we may need other systemd target, which would be triggered as soon as all addresses are configured on interfaces. network-online.target ensures default route is configured and working. I think we often do not require that, but local addresses have to be configured already. For static obtained addresses that should be simple to know.
Possible solution might be way to make source-address just desired, but not strongly required. Requested that feature upstream: https://gitlab.isc.org/isc-projects/bind9/-/issues/4065
ISC does not seem to be in favor of new features to work with this. It seems to me improved documentation would help configuring it properly. At the bottom of [1] is how to start the service only after network is configured. [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_managing_networking/systemd-network-targets-and-services_configuring-and-managing-networking
When using any option *-source, it requires named to wait until that address is present. It is part of configuration, which is not the default.