While boot-up with activated dns-firewall-lists there is a boot-delay from nearly two minutes while initializing the dns-firewall, so far i could find out. I have attached the logs from my test-ipfire, which is on productive core 201 release.
The first log is with activated dns-firewall-lists, see line 922ff (after suricata reports: Signature(s) loaded, Detect thread(s) activated)., the second is without activated dns-firewall-lists.
It seems that unbound reloads the RPZs at startup. /usr/sbin/unbound-control -q fast_reload
On my VMware test platform with a Core i7 and 4 GB of RAM, it takes 30 seconds to boot with all RPZ lists enabled.
It must certainly depend on the hardware used and the number of lists to be loaded.
It isn’t the fast_reload operation. It is just the initialization. Building up the internal database can not be done in 0 time.
That is the old realtime problem, either good responsiveness after an intensive startup(reading all conditions) or short startup and less responsiveness because of partial reading of conditions.
Unbound does the first way. For small changes the fast_reload operation was developed, this is used by IPFire 's unboundctrl program. There are some issues with this operation, which should be corrected soon ( I hope ).