From: Tapani Tarvainen <ipfire@tapanitarvainen.fi>
To: development@lists.ipfire.org
Subject: Re: [RFC] unbound: Increase timeout value for unknown dns-server
Date: Wed, 06 Jan 2021 18:19:12 +0200 [thread overview]
Message-ID: <20210106161912.GD331292@vesikko.tarvainen.info> (raw)
In-Reply-To: <89BEBEA5-D070-49A3-899E-12CED79D6A95@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]
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.
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.
--
Tapani Tarvainen
next prev parent reply other threads:[~2021-01-06 16:19 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-06 10:17 Jonatan Schlag
2021-01-06 12:02 ` Paul Simmons
2021-01-06 15:14 ` Michael Tremer
2021-01-06 16:19 ` Tapani Tarvainen [this message]
2021-01-06 18:01 ` Michael Tremer
2021-01-08 8:25 ` Paul Simmons
[not found] <5BE69EAB-BD90-4999-97AE-8A89479AD080@gmail.com>
2021-01-07 11:27 ` Michael Tremer
2021-01-07 14:35 ` Tapani Tarvainen
2021-01-07 14:54 ` Michael Tremer
[not found] <20E5B302-A896-4BD2-BAD1-9D6A50831514@ipfire.org>
2021-01-09 15:04 ` Michael Tremer
2021-01-09 18:57 ` Paul Simmons
2021-01-10 14:07 ` Tapani Tarvainen
2021-01-12 5:07 ` Paul Simmons
2021-01-16 3:02 ` Paul Simmons
2021-01-16 8:13 ` Tapani Tarvainen
2021-01-19 6:22 ` Paul Simmons
2021-01-25 19:23 ` Michael Tremer
2021-01-25 20:29 ` Paul Simmons
2021-01-25 20:50 ` Michael Tremer
2021-01-11 11:10 ` Michael Tremer
2021-01-12 4:37 ` Paul Simmons
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210106161912.GD331292@vesikko.tarvainen.info \
--to=ipfire@tapanitarvainen.fi \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox