Hello,

> On 6 Jan 2021, at 16:19, Tapani Tarvainen <ipfire(a)tapanitarvainen.fi> wrote:
> 
> On Wed, Jan 06, 2021 at 03:14:52PM +0000, Michael Tremer (michael.tremer(a)ipfire.org) wrote:
> 
>>> On 6 Jan 2021, at 12:02, Paul Simmons <mbatranch(a)gmail.com> wrote:
>>> 
>>> On 1/6/21 4:17 AM, Jonatan Schlag wrote:
>>>> When unbound has no information about a DNS-server
>>>> a timeout of 376 msec is assumed. This works well in a lot of situations,
>>>> but they mention in their documentation that this could be way too low.
>>>> They recommend a timeout of 1126 msec for satellite connections
>>>> (https://nlnetlabs.nl/documentation/unbound/unbound.conf).
> 
> A small nit, they actually suggest 1128 ... and that's indeed what
> the patch has:
> 
>>>> +	unknown-server-time-limit: 1128
> 
> But that's trivial. The point:
> 
>> I am not entirely sure what this is supposed to fix.
> 
>> It is possible that a DNS response takes longer than 376ms, indeed.
>> Does it harm us if we send another packet? No.
> 
> If you are behind a slow satellite link, it can take more than that
> *every time*. So you would always have sent another query before
> getting a response to the previous one.

True, but aren’t these extra-ordinary circumstances?

On a regular network we want to keep eyeballs happy and when packets get lost or get sent to a slow server, we want to try again - sooner rather than later.

If we would set this to a worst case setting (let’s say 10 seconds), then even for average users DNS resolution will become slower.

> With TCP that would mean never getting a response, because you'd
> always terminate the connection too soon. With UDP, I'm not sure,
> depends on how unbound handles incoming responses to queries it's
> already deemed lost and sent again. Adjusting delay-close might help.
> But it may be it would not work at all when the limit is too small.
> 
> That would mean that someone installing IPFire in some remote location
> with a slow link would conclude that it just doesn't work.
> 
> The downside of increasing the limit is that sometimes replies will
> take longer when a packet is lost on the way because we'd wait longer
> before re-sending. So it should not be increased too much either.
> 
> I don't have data to judge what the limit should be, but I'd tend to
> trust nllabs recommendation here and go with the suggested 1128 ms.

Did anyone actually experience some problems here that this needs changing?

@Jonatan: What is your motivation for this patch?

> 
> -- 
> Tapani Tarvainen