The unbound reload was deliberately introduced with the commit shown earlier.
Previously unbound could not reload its configuration and also dropped the existing cache.
So the old code had lots of lines looking at the diff of the cache to see what to keep and what to remove but unbound was kept running with no reload and hence no restart.
So to me it seems that having the restart of service after doing the unbound reload is a natural consequence of the change of the code.
All the old diff code to update the cache is gone.
Instead unbound has the configuration reloaded and the command used is reload_keep_cache which keeps the RRSet and message cache info.
This option apparently did not exist in earlier versions of unbound.
You could only reload which caused the cache to be completely flushed so all DNS queries had to start from scratch again so hence that was not done in the past and the diff code was developed and used.
Is the unbound reload causing a high memory or cpu consumption.
Maybe it is just a natural consequence of the changes that were made to the unbound-dhcp-leases-bridge code.
This question may need to be raised on the Dev mailing list as I think the devs are very busy at the moment.
If the unbound bridge scrip is the source of the restart problem then this needs fixed.
But one more question arrises.!
This RFC2136 Page in the WUI maybe broken if it is not updating correctly.
I have bin reading a little on the subject.
Sounds like it may use Bind And a database to keep track of this info.
Shouldn’t this update the localdomain and IP. somewhere?
it’s self a database?
on my system red,green,blue,orange.
Only Green and Blue are listed in this RFC2136 section.
So I would guess this is only a local Database.
Which may be partly broken.?
