Thomas Eizinger
Thomas Eizinger
> This silent failure caused us to have issues for a while. We've been trying to figure out a way to enforce this at compile time (or allow the user...
> * Why is `Too many DNS queries` printed in each iteration of the eventloop it seems? Shouldn't this correspond to when the actual DNS query was attempted? It should...
Thanks for the repro @ReactorScram ! Does it ever stop doing that? Does it affect connectivity?
@ReactorScram Could you retest on the following branch https://github.com/firezone/firezone/pull/5263?
> * [c40fe36](https://github.com/firezone/firezone/commit/c40fe36889cb4aae647d55e7f5b2d7763e39d014) (built as [5b08c92](https://github.com/firezone/firezone/commit/5b08c92c16c5b525516bdaa3e615059236e744e7)) now says "Failed to send DNS query: Too many ongoing DNS queries" Which domain is it? Should be in the tracing span attached to...
Interesting, thanks for the test. Needs more work it seems.
I've looked a bit more into this: 1. Our DNS resolver, hickory, applies a 5s timeout with 2 retries. 2. 5s timeout matches the behaviour of `dig`. 3. I don't...
> Hm, can we replace old lookups with newer ones for the same query? I.e. Set not Queue And reply to the one that we replaced immediately with an error?...
Another way to deal with such a burst would be to clear the entire queue and drop all current in-flight DNS queries. That would at least make space for another...
Could somebody retest with https://github.com/firezone/firezone/pull/5306 so we see what the upstream response is?