since this defines an ExecStart= but doesn't set the Type=, this service defaults to a 'simple' type service, which means systemd considers it 'started' essentially immediately (specifically, as soon as systemd forks a thread to run the ExecStart=). So anything that is set to After=named.service (or, set that way indirectly, e.g. with After=nss-lookup.target) will be started when the process running the named binary has been started, not when named actually is "up and running".
The named.service should be adjusted to be a different Type=, probably 'forking' though it would depend on the exact behavior of when named actually forks when the -f param isn't used. Essentially, the named.service file should be configured to not be 'running' until named is actually 'running'. See 'man systemd.service' for details on the the Type= options.
> Do you have any idea for the described behavior with nginx then
I looked in hirsute, so not sure if things are different upstream, but in that release the named.service is:
[Service] =-/etc/ default/ named /usr/sbin/ named -f $OPTIONS /usr/sbin/ rndc reload /usr/sbin/ rndc stop
EnvironmentFile
ExecStart=
ExecReload=
ExecStop=
Restart=on-failure
since this defines an ExecStart= but doesn't set the Type=, this service defaults to a 'simple' type service, which means systemd considers it 'started' essentially immediately (specifically, as soon as systemd forks a thread to run the ExecStart=). So anything that is set to After=named.service (or, set that way indirectly, e.g. with After=nss- lookup. target) will be started when the process running the named binary has been started, not when named actually is "up and running".
The named.service should be adjusted to be a different Type=, probably 'forking' though it would depend on the exact behavior of when named actually forks when the -f param isn't used. Essentially, the named.service file should be configured to not be 'running' until named is actually 'running'. See 'man systemd.service' for details on the the Type= options.