On Fri, 10 May 2024 19:30:36 +0100,
Stuart Henderson <stu@spacehopper.org> wrote:
> 
> On 2024/05/10 18:44, Kirill A. Korinsky wrote:
> > On Fri, 10 May 2024 14:53:11 +0100,
> > Stuart Henderson <stu@spacehopper.org> wrote:
> > > 
> > > I'd like to wait until the discussion with upstream goes further before
> > > making any changes to the default config.
> > >
> > 
> > Well, this issue is opened since December 2020... and I bet that it won't go
> > any future, but I'll ba back to this in couple of months.
> 
> But for much of that time there was confusion between the difference
> between NXDOMAIN experienced while recursing (where this unbound
> behaviour was intentional, though now appears might be an issue with
> these [rather weakly coded, tbh...] rbldns daemons) and NXDOMAIN on
> the actual query (not intended to trigger).


The different errors depend on whether logging is enabled, and to find the
real cause, the debug level should be enabled, which produces more logs than
syslog can handle, and the logs should be redirected to a file.

This seems like a nightmare to debug, doesn't it?

Anyway, the main reason why I'm suggesting these changes in tech@ is because
I'm on an unstable internet connection and I'm using local unbound as my
local DNS on my laptop. And my unstable internet connection causes local
unbound to start banning some upstream servers.

So restarting unbound helps, but at first it seems like the internet is
down, but it wasn't the case because some part of the internet was working
and some had "domains not found".

I had tracked similar issues with unbound recently, and relealized that I
had it on laptop. After applying suggested changes, it starts working much
better.

And after taht I suggested it to tech@.

> I bet the real fix is a code change and ideally I'd not like to
> encourage users to add more to their unbound.conf (which is likely
> to stay around forever, even if the problem is fixed properly)
> which reduce effectiveness of an intentional feature to reduce
> risk of overloading poorly configured/coded DNS servers. (One
> could also take the view that it's working as expected...)
> 

I agree with you, but after reading comments from unbound team members, I
see that this is expected behavior and they don't plan to change it.

I can't disagree with point that overloaded servers need to be left alone to
cool down... but this behavior is quite unique and not something anyone
would expect from a DNS resolver.

Special up to 24h server ban. I have no idea why it's so huge, I don't
understand how such time is calculated, but if it's true, it should be
changed, because 24h ban of some servers is not what anyone expected nor
tolerate. So in real life a user will reboot the device with unbound over
unplug power instead of waiting for unban of the upstream NS server.

-- 
wbr, Kirill