public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Long delays restarting unbound if Red is down
Date: Thu, 13 Dec 2018 16:41:59 +0000	[thread overview]
Message-ID: <11684CBC-A4C2-4F5E-B8B8-27AA1D32EBFE@ipfire.org> (raw)
In-Reply-To: <94190F08-05FC-41C1-B68D-6D8CEE8195DC@rymes.com>

[-- Attachment #1: Type: text/plain, Size: 3146 bytes --]



> On 13 Dec 2018, at 16:36, Tom Rymes <trymes(a)rymes.com> wrote:
> 
> That’s precisely the problem, Michael. Everything works fine, until something (like an internet outage) prevents you from reaching the DNS servers. Then, when you reboot the router as part of a troubleshooting process, it takes forever while unbound flails about.

Yes. If you have seen my conversation with Erik on this list, we are aware of loads of issues with this script and want to remove those problems.

However, getting rid of that script might have other implications that we do not know yet. It is actually quite risky.

Unbound just does not handle those DNS servers well that do not conform to (recent) RFC standards. I am not sure if that has changed with recent releases and with more people who have deployed unbound in recent months and years. I hope it did.

> In this instance, we were replacing a failed router, and someone had misconfigured the red interface settings, so we were modifying those settings in setup. It took us a while to figure out what we were doing wrong, so we ended up having to wait over and over again as unbound tried to restart and failed. We were the problem, but unbound made it a real hassle while we worked to figure out what we were doing wrong.
> 
> Shouldn’t it have a reasonably short timeout for when the DNS servers are unavailable?

It does, but that timeout is still quite long. Some DNS servers do not respond when the EDNS0 buffer size is too large. We try to go down from a large size to a smaller one and hope that the server responds at some point (old Cisco equipment is to blame for this - they assumed that a DNS packet will never be larger than a couple of bytes). Each try has a small timeout, but we will test quite a couple of sizes until we finally decide that the server does not respond at all.

The algorithm could of course be tuned to figure that out earlier, but I never considered many people running into this problem. However, it has an effect too when the name servers are not reachable at all.

I want to get rid of this test though. That should be the solution instead of making a shitty script a little bit better. It will still be a bit shitty.

Best,
-Michael

> 
> Tom
> 
>> On Dec 13, 2018, at 11:19 AM, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
>> 
>> Hi Tom,
>> 
>> the script is usually quite fast when it can reach the DNS servers.
>> 
>> If it can’t it is waiting quite long and runs into a timeout.
>> 
>> Is there a reason why it cannot reach the DNS servers? It should be able to or you should not have functioning DNS.
>> 
>> -Michael
>> 
>>> On 12 Dec 2018, at 15:31, Tom Rymes <trymes(a)rymes.com> wrote:
>>> 
>>> Last night we were fighting with a router that had a non-functioning red interface. It ended up being a misconfiguration on our part, but while we were troubleshooting, we routinely had to wait for very long periods as unbound failed to contact the defined name servers. 
>>> 
>>> Is there a way to make the startup script time out more quickly when things are not functioning?
>>> 
>>> Tom
>> 


  reply	other threads:[~2018-12-13 16:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-12 15:31 Tom Rymes
2018-12-13 16:18 ` Michael Tremer
2018-12-13 16:36   ` Tom Rymes
2018-12-13 16:41     ` Michael Tremer [this message]
2018-12-13 17:00       ` Tom Rymes

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=11684CBC-A4C2-4F5E-B8B8-27AA1D32EBFE@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --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