Re: DoT forwarder: controlling timeout before fallback to recursion ?

> I'm curious if it's the same if the VM is up, but unbound is not running, so
> you'd get an instant port unreachable, rather than suffer through ARP/ND
> failures for the host.

interesting point / good catch.

if VM is up, but unbound is down, then fallback works ... with just a barely-noticeable delay.  NOT the ~3 secs in the VM-down case.

> I don't know the answer here, but if this VM is critical path, maybe it
> should be redundant/resilient?

this it the process of getting there ... making sure i understand DoT + Forwarding, and it does what I "want".

> Why do you want this cache in place?  Is it performance, anonynimity, ??

for this setup, "de-Comcasting" the LAN's resolver traffic.  so, anonymity, mostly.
with a soupçon of lack of trust ...

if i !forward from my LAN bind9 instance -- i.e., direct resolution, performance is good.  arguably not as quick as a cached at VM's unbound result ... but need to prove that to myself.
and that's true ... until the Comcast feed gets jinky.  which happens, tho not terribly often.

  
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.