/etc/init.d/unbound start has a race condition with potential security implications, especially with split dns setups: unbound is started with minimal configuration and local hostnames and forwarders are added one by one with unbound-control. Until that is completed unboud responds to DNS queries with incomplete and possibly erroneous data. Most often it will give NXDOMAIN for hostnames that do exist, but with split DNS setup it could return external IP instead of internal one, as forwarders are enabled before local hostnames are loaded. Situation is made worse by adding local hostnames one by one, which can easily take several minutes if host file is long.
Created attachment 587 [details] Patched /etc/init.d/unbound Quick hack that fixes at least the obvious security issues by putting own_hostname and local hosts to config files of their own, namely /etc/unbound/local.d/hostname.conf and /etc/unbound/local.d/localhosts.conf, before starting unbound. Forwarders are still initialized with unbound-control but only after local hosts have been loaded; NXDOMAIN could still result for an external hostname but that's less likely to be dangerous and time window when it can happen is very small. It would be better to initialize forwarders with a config file, too, but that'd be a bit more complicated and move to systemd in IPFire 3 will make this moot anyway.
I also consider this being an information leak. Besides of that, I did not really get the security impact here. Indeed, a clean forward file would be much better...
https://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=commitdiff;h=6137797cb39b32e49d97eee572478a92099ded23
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=6137797cb39b32e49d97eee572478a92099ded23
As far as I am concerned, this was shipped with Core Update 140/141. https://blog.ipfire.org/post/ipfire-2-25-core-update-141-release