sometimes people run unbound as local resolver for a larger network, yet want more immediate changes for their own (internal) zone(s) (ignoring TTL) being visible trying to use stub/forward for this. The easiest way to accomplish this is to prevent answers from going into the cache or using the cache to answer for those zones.
I’ve hacked up (with very limited testing) a patch to add a stub-no-cache: <yes/no> and a forward-no-cache: <yes/no>.
If this is something more people than the ones I know are interested in, let me know, and I can add the man page bits if needed (and submit it to bugzilla for proper tracking if you prefer).
thanks a lot.
You described my main unbound usage.
Most scenarios where I need to avoid obsolete RRs are perfecltly covered with auth-zones:.
For the stub'n'forward zones I limited max TTL as far as I remember.
But I remember I wanted a stub-no-cache: once. Can't remember the detailts, but I'm happy to know it's there now.
A short man page record would be nice, I wil have forgotten about it possibly already next time I'll touch any unbound.conf.
Are you aware of any stub-no-chache: advantage over auth-zone: in the mentioned usage scenario?
I mean if there is small zone data (<10k RRs), mid-latency links (<50ms) and isolated/secure transfer channels available?
sometimes people run unbound as local resolver for a larger network, yet
want more immediate changes for their own (internal) zone(s) (ignoring
TTL) being visible trying to use stub/forward for this. The easiest
way to accomplish this is to prevent answers from going into the cache
or using the cache to answer for those zones.
I’ve hacked up (with very limited testing) a patch to add a
stub-no-cache: <yes/no> and a forward-no-cache: <yes/no>.
Thank you for the patch! I have incorporated that into the code.