Why are unbound-control local_zone_remove/local_zone/local_data so incredibly slow ?

Ralph Dolmans ralph at nlnetlabs.nl
Wed Nov 30 13:36:30 UTC 2016


Unbound-control sets up a TLS connection for every command. Setting up
30k TLS connections one after another does take some time.

If your unbound daemon and unbound-control are on the same machine you
could try to communicate over a secured local socket and disable
control-use-cert. This might speed it up a little.

I just added some code to Unbound to bulk add and remove local-zones and
local-data, by reading input from stdin. This gives the possibility to
do the update over a single connection using local_zones,
local_zones_remove, local_datas and local_datas_remove. This code will
be in the next Unbound release.

-- Ralph

On 28-11-16 13:18, Tim Smith via Unbound-users wrote:
> Hello list,
> I'm running Unbound 1.5.9 on OpenBSD 6.
> I have the need to periodically add certain local data to unbound as
> part of a dynamic security block list (i.e. redirect to null).  These
> lists can be 30k+ items in length.
> Originally, I had this scripted as follows :
>    - Get and parse data into unbound config format
>    - Reload unbound
> Obviously the problem with that approach is that reloading unbound
> causes cache to be flushed .... which is not cool.  However on the
> plus side the script runs super-quick as its just a config reload !
> So I looked at my options and came up with a second script :
>    - Get and parse data into two groups :  remove and add
>    - On "remove" set run unbound-control local_zone_remove
>    - On "add" set run unbound-control local_zone and unbound-control local_data
> The problem is its taking forever to process that because calls to
> unbound-control are so slow !  e.g. its been well over an hour now and
> it *still* hasn't finished processing 30k items.   The server is not
> slow, the server is not heavily loaded, and my script is simple ....
> the problem is very much the slowness of the calls to unbound-control.
> Help !!
> Thanks
> Tim

More information about the Unbound-users mailing list