Unbound 1.6.0rc1 prerelease

[Spike]

thanks for the insight Ralph.

comments inline below:

On Mon, Dec 12, 2016 at 2:19 AM Ralph Dolmans via Unbound-users <
unbound-users at unbound.net> wrote:

A module (C or Python) can now dictate that the Unbound cache should be
> bypassed when receiving queries containing the by the module registered
> EDNS options. This makes the module responsible to do the cache lookup.
> If you disable cache lookup and don't implement the cache lookup in your
> module, you wont use any cache at all!
>

mmmh, not quite sure I get it. Do you have an example somewhere? right now
I'm using something very similar to
https://www.unbound.net/documentation/pythonmod/examples/example2.html .

Did you mean that somehow I could change that code to ignore the cache? I
thought that module wasn't called to begin with if the cache had a hit,
which is my problem to begin with. At the same time I'm not sure I wanna
run that python script every single request even when there's a cache hit
available.

am I making any sense?


> In your case you could better use the local-zones and data with tags, or
> views, to do the overrides based on client addresses.
>

unfortunately in some cases I need inverted regexps/whitelists, for example
allow sub.domain.tld but otherwise block *.domain.tld. As far as I could
see you can't do that with local-data.


> A view in Unbound is a named list of configuration options. The
> currently supported view configuration options are local-zone and
> local-data. Mapping a view to a client can be done using the
> access-control-view element.
>

thanks for clarifying this.


> You would like Unbound to also give the local-data record for the domain
> the local-data CNAME is pointing to? That is not yet possible, but an
> interesting idea!
>

Just to be clear, let me try with a simple example. We run a small lan with
just a few nodes I need dns for. I don't really wanna run bind/an auth dns
if I can avoid it and unbound works just fine for 90% of the use cases, ie
nagios.mylan , printer.mylan, etc. In some cases however I would like to
have also cnames such that monitor.mylan -> nagios.mylan. I could of course
implement this with an A record, pointing monitor.mylan to the same ip as
nagios does (and I'm doing that right now), but it's error prone and with
the rate that things are changing here I'd rather use CNAMEs.

makes sense?

thanks again for your help,

Spike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20161215/52ccae0b/attachment.htm>