is a very large local-data list a problem?

[Maciej Soltysiak]

I have a suggestion not to redirect to 127.0.0.1 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: "cdn.sh-jxzx.com" refuse

That's beneficial also because the application requesting will not even try
to issue a TCP connection to 127.0.0.1; 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,
Maciej


On Mon, Nov 28, 2016 at 11:23 AM, Ralph Dolmans via Unbound-users <
unbound-users at unbound.net> 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
> https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=839). 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 127.0.0.1. This
> > kind of thing:
> >
> > https://deadc0de.re/articles/unbound-blocking-ads.html
> >
> > 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: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20161128/bb3945de/attachment.htm>