Bug 11743

Summary: unbound: Reloading hosts takes very long
Product: IPFire Reporter: Tapani Tarvainen <ipfire>
Component: ---Assignee: Michael Tremer <michael.tremer>
Status: CLOSED FIXED QA Contact:
Severity: Minor Usability    
Priority: Will affect all users CC: michael.tremer, peter.mueller
Version: 2   
Hardware: all   
OS: Linux   
Attachments: Patched /etc/init.d/unbound

Description Tapani Tarvainen 2018-05-29 17:38:12 UTC
/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.
Comment 1 Tapani Tarvainen 2018-05-29 17:58:14 UTC
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.
Comment 2 Peter Müller 2018-05-30 06:43:19 UTC
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...
Comment 5 Peter Müller 2020-03-07 09:36:06 UTC
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