From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [RFC] unbound: Increase timeout value for unknown dns-server
Date: Wed, 06 Jan 2021 18:01:45 +0000
Message-ID: <B58A78B2-5DC4-42CA-90FC-E9313DDFFFBA@ipfire.org>
In-Reply-To: <20210106161912.GD331292@vesikko.tarvainen.info>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9155193818937591899=="
List-Id: <development.lists.ipfire.org>

--===============9155193818937591899==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hello,

> On 6 Jan 2021, at 16:19, Tapani Tarvainen <ipfire(a)tapanitarvainen.fi> wro=
te:
>=20
> On Wed, Jan 06, 2021 at 03:14:52PM +0000, Michael Tremer (michael.tremer(a)=
ipfire.org) wrote:
>=20
>>> On 6 Jan 2021, at 12:02, Paul Simmons <mbatranch(a)gmail.com> wrote:
>>>=20
>>> 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).
>=20
> A small nit, they actually suggest 1128 ... and that's indeed what
> the patch has:
>=20
>>>> +	unknown-server-time-limit: 1128
>=20
> But that's trivial. The point:
>=20
>> I am not entirely sure what this is supposed to fix.
>=20
>> It is possible that a DNS response takes longer than 376ms, indeed.
>> Does it harm us if we send another packet? No.
>=20
> 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=E2=80=99t 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 late=
r.

If we would set this to a worst case setting (let=E2=80=99s 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.
>=20
> That would mean that someone installing IPFire in some remote location
> with a slow link would conclude that it just doesn't work.
>=20
> 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.
>=20
> 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?

>=20
> --=20
> Tapani Tarvainen


--===============9155193818937591899==--