notice: send failed: Permission denied

[Caroptions Caroptions]

Hi George, Wouter,

Thank you for reply! The problem with this solution is that (even silently) unbound continue to contact blocked NS and as result load firewall filter significantly, as I mentioned before CPU load jumps to up to 50% and stays on this level till I reload unbound with appropriate  do-not-query-address:.

Also strange thing that unbound (it seems) does not have any limit of how many times tries to ping specific name server (I observed once 5 hours in a row).

Is it (number of times to ping) configurable?

Thanks,
John

________________________________
From: Unbound-users <unbound-users-bounces at lists.nlnetlabs.nl> on behalf of George Thessalonikefs via Unbound-users <unbound-users at lists.nlnetlabs.nl>
Sent: Monday, April 12, 2021 8:01 AM
To: unbound-users at lists.nlnetlabs.nl <unbound-users at lists.nlnetlabs.nl>
Subject: Re: notice: send failed: Permission denied

Hi John,

The error messages are coming from the system call itself, which your
firewall seems to block. That way unbound will not record anything for
the nameserver in the infra cache (used to record time outs among other
options).
This will result in unbound trying a finite number of times every time
that nameserver needs to be contacted.

If you lower the verbosity level to 2 (and with the fix I just committed
https://github.com/NLnetLabs/unbound/commit/403d0551b7a65023e15be43ae5c1fd938edd6025)
you will no longer see log messages related to contacting upstreams.

Unbound would still try to connect silently though before giving up.

If you also want to skip that, then indeed using `do-not-query-address:`
is the way to go.

Best regards,
-- George

On 12/04/2021 11:20, Wouter Wijngaards via Unbound-users wrote:
> Hi John,
>
> Fix code is in
> https://github.com/NLnetLabs/unbound/commit/addd21f750b6042c40c2a92aef9b8919d8497532
>
> This stops the logs messages unless you set a high verbosity level.
> These error numbers did not get reported before, I guess because the
> block rule is reject.
>
> Best regards, Wouter
>
> On 06/04/2021 03:48, Caroptions Caroptions via Unbound-users wrote:
>> Important note, the firewall block rule is reject, not block ...
>>
>> Thanks,
>> John
>>
>> ------------------------------------------------------------------------
>> *From:* Unbound-users <unbound-users-bounces at lists.nlnetlabs.nl> on
>> behalf of Caroptions Caroptions via Unbound-users
>> <unbound-users at lists.nlnetlabs.nl>
>> *Sent:* Monday, April 5, 2021 2:20 PM
>> *To:* unbound-users at lists.nlnetlabs.nl <unbound-users at lists.nlnetlabs.nl>
>> *Subject:* notice: send failed: Permission denied
>>
>> Hi,
>>
>> Probably it is discussed already, then sorry for reiterating the same
>> problem, but I couldn't find solution.
>>
>> unbound 1.13.1
>>
>> I block certain ASNs/IPs on firewall. unbound starts normally, then
>> after some time flood log with messages:
>>
>> unbound[90575]: [90575:2] notice: remote address is xx.xx.xx.xx port 53
>> unbound[90575]: [90575:2] notice: send failed: Permission denied
>> unbound[90575]: [90575:2] notice: remote address is xx.xx.xx.xx port 53
>> unbound[90575]: [90575:2] notice: send failed: Permission denied
>> unbound[90575]: [90575:2] notice: remote address is xx.xx.xx.xx port 53
>> unbound[90575]: [90575:2] notice: send failed: Permission denied
>> unbound[90575]: [90575:2] notice: remote address is xx.xx.xx.xx port 53
>> unbound[90575]: [90575:2] notice: send failed: Permission denied
>> unbound[90575]: [90575:2] notice: remote address is xx.xx.xx.xx port 53
>>
>> the SAME ip for hours. My firewall process CPU load jumps and stays on
>> high level. unbound process CPU load high as well.
>>
>> My temporary workaround is adding:
>>
>> do-not-query-address: xx.xx.xx.xx
>>
>> When I add new ip to this list it stays normal for some time till
>> unbound find new NS server IP which is blocked on firewall and all loads
>> jumps and flood log with "notice" messages.
>>
>> In my understanding unbound should stop attempting to contact specific
>> NS if it is not reachable/down?
>>
>> Thanks,
>> John
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20210413/0377bb53/attachment-0001.htm>