is a very large local-data list a problem?

Maciej Soltysiak maciej at
Mon Nov 28 10:49:31 UTC 2016

I have a suggestion not to redirect to and refuse instead; what
your customer is running a webserver on localhost or any other app that
runs something on port 80 (like TeamViewer at some companies). That's
needless connections and processing.

I suggest sending NXDOMAIN instead of IN A, like so:
local-zone: "" refuse

That's beneficial also because the application requesting will not even try
to issue a TCP connection to; gethostbyaddr() and friends will
return error.

Ralph, in say, 1.4.22, is refuse less, more or the same memory-consuming as
adding aditional local-data for IN A?

Best regards,

On Mon, Nov 28, 2016 at 11:23 AM, Ralph Dolmans via Unbound-users <
unbound-users at> wrote:

> Hi Spike,
> The local-zones are stored in a red-black tree, so searching will be
> O(log n).
> Your memory usage will increase *a lot*. Unbound will create an 8k
> memory region for every local-zone containing local-data, so you will
> need ~40GB of memory. Do you really need the local data for each zone?
> Maybe using a local-zone type that prevents the resolution also works
> for you. New versions of unbound (available from our repository, not
> released yet) will not allocate the 8K for local-zones without
> local-data (see
> In that case
> your local-zone tree will need ~2GB of memory.
> Regards,
> -- Ralph
> On 27-11-16 19:08, Spike via Unbound-users wrote:
> > Dear all,
> >
> > We've been using one of those ads blocklists that is basically a long
> > text file of local-data statements sending everything to This
> > kind of thing:
> >
> >
> >
> > It's worked so well for us that we'd like to grow that list... by a lot
> > (~5M entries). I'm wondering if and to what extent this is going to have
> > a negative impact on performances or if "simply" the process will grow
> > in memory usage. Also how efficient are those lookups going to be? I'm
> > not sure this is even a common use case that unbound has been optimized
> for.
> >
> > thanks,
> >
> > Spike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Unbound-users mailing list