From: Kirill A. Korinsky Subject: Re: Prevent Unbound from penalty upstream server To: OpenBSD tech Date: Fri, 10 May 2024 20:07:55 +0100 On Fri, 10 May 2024 19:30:36 +0100, Stuart Henderson wrote: > > On 2024/05/10 18:44, Kirill A. Korinsky wrote: > > On Fri, 10 May 2024 14:53:11 +0100, > > Stuart Henderson 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