<div dir="ltr">thanks for the insight Ralph.<div><br></div><div>comments inline below:<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 12, 2016 at 2:19 AM Ralph Dolmans via Unbound-users <<a href="mailto:unbound-users@unbound.net">unbound-users@unbound.net</a>> wrote:</div><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A module (C or Python) can now dictate that the Unbound cache should be<br class="gmail_msg">
bypassed when receiving queries containing the by the module registered<br class="gmail_msg">
EDNS options. This makes the module responsible to do the cache lookup.<br class="gmail_msg">
If you disable cache lookup and don't implement the cache lookup in your<br class="gmail_msg">
module, you wont use any cache at all!<br class="gmail_msg"></blockquote><div><br></div><div>mmmh, not quite sure I get it. Do you have an example somewhere? right now I'm using something very similar to <a href="https://www.unbound.net/documentation/pythonmod/examples/example2.html">https://www.unbound.net/documentation/pythonmod/examples/example2.html</a> .</div><div><br></div><div>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.</div><div><br></div><div>am I making any sense?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In your case you could better use the local-zones and data with tags, or<br class="gmail_msg">
views, to do the overrides based on client addresses.<br class="gmail_msg"></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A view in Unbound is a named list of configuration options. The<br class="gmail_msg">
currently supported view configuration options are local-zone and<br class="gmail_msg">
local-data. Mapping a view to a client can be done using the<br class="gmail_msg">
access-control-view element.<br class="gmail_msg"></blockquote><div><br></div><div>thanks for clarifying this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You would like Unbound to also give the local-data record for the domain<br class="gmail_msg">
the local-data CNAME is pointing to? That is not yet possible, but an<br class="gmail_msg">
interesting idea!<br class="gmail_msg"></blockquote><div><br></div><div>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.</div><div><br></div><div>makes sense?</div><div><br></div><div>thanks again for your help,</div><div><br></div><div>Spike</div></div></div></div>