DNS-Firewall causes a nearly 2 minute boot-delay

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.

Can i investigate somewhere deeper?

Log with DnS-Firewall

Log without DNS-Firewall

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.

That could be the reason, its an Intel Celeron 847 Dual Core with 1.1 GHz and 8GB RAM

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 ).

There is indeed a /usr/sbin/unbound-control -q fast_reload that is launched at startup and lasts 30 seconds.
I traced /etc/rc.d/init.d/unbound.

[18:29:04 unbound:67] echo '# This file is automatically generated and any changes'
[18:29:04 unbound:68] echo '# will be overwritten. DO NOT EDIT!'
[18:29:04 unbound:69] echo
[18:29:04 unbound:966] '[' off '!=' on ']'
[18:29:04 unbound:967] exit 0
[18:29:04 unbound:1016] /usr/sbin/unbound-control -q fast_reload
[18:29:37 unbound:1019] resolve ping.ipfire.org
[18:29:37 unbound:1021] '[' update-forwarders = update-forwarders ']'
[18:29:37 unbound:1023] fix_time_if_dns_fails
[18:29:37 unbound:520] resolve 0.ipfire.pool.ntp.org
[18:29:38 unbound:522] return 0
Adding static routes...                                                [  OK  ]
Adding static routes...                                                [  OK  ]
Mounting network file systems...                                       [  OK  ]
Starting the Cyrus SASL Server...                                      [  OK  ]
Setting time on boot...                                                [  OK  ]
Starting ntpd...                                                       [  OK  ]
Starting DHCP Server...
/usr/sbin/unbound-dhcp-leases-client: /var/run/unbound-dhcp-leases-brid[  OK  ]does not exist
Starting Unbound DHCP Leases Bridge...                                 [  OK  ]
Starting SSH Server...                                                 [  OK
IPFire v2.29 - www.ipfire.org
===============================
ipfireTest.pshome running on Linux 6.18.7-ipfire x86_64
ipfireTest login:

You are right.
After start of unbound, which reads the config, ‘red up’ event does an update-forwarders operation, which results in a fast_reload.