Unbound blocklist (DNSBL): Add support for returning NXDOMAIN instead of 0.0.0.0

[cellsplicer]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [ x ] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [ x ] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

There was a previous feature request and subsequent work for adding NXDOMAIN support in Unbound-plus - see https://github.com/opnsense/plugins/issues/1842

This is important as 0.0.0.0 causes connection delays and poor performance on Apple devices running third party software. Apple has forced third party developers to use Network Extensions since 2020.

Describe the solution you like

I would like a check box on the ui/unbound/dnsbl/index page for returning NXDOMAIN instead of "Destination Address".

Describe alternatives you considered

Using piHole which has the functionality to configure returning NXDOMAIN or any other destination IP address for the blocklist.

Additional context

N/A

[haarp]

0.0.0.0 is an invalid IP address. I was always under the impression that most libraries would almost instantly fail when trying to connect to it. Does it work differently on Apple devices?

[cellsplicer]

It can be replicated on my M1 Macbook Pro running Big Sur with corporate internet filtering: time curl 0.0.0.0 -s > /dev/null curl 0.0.0.0 -s > /dev/null 0.00s user 0.01s system 1% cpu 1.024 total

time curl 127.0.0.1 -s > /dev/null curl 127.0.0.1 -s > /dev/null 0.00s user 0.01s system 69% cpu 0.012 total

As can be seen above the request to 0.0.0.0 blocks for a full second.

According to an old bug report for Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=1678446 it occurs when there are any user space applications hooking into MacOS Network Extension framework such as a VPN client or content filter. I happen to have both as enforced by corporate IT policy.

[refuseduser]

Hello, NXDOMAIN is better than redirecting to a wrong address, for example, but it is still confusing because the domain exists but you don't want to resolve it. Response code 5 (REFUSED, RFC1035) would be better, where it is clear that the response to the request is refused due to a policy. Since there may be people who prefer to use NXDOMAIN, you could make a list or a radio button in which you have the choice between NXDOMAIN and REFUSED.

Judging by the commit 1c136881e2cd7a69dae2c9d62d1940c0931eb292 (#6083), the following files would have to be adapted a little:

https://github.com/opnsense/core/blob/ff0e772b5ba2877c4ea925c86957900ad70a7774/src/opnsense/mvc/app/controllers/OPNsense/Unbound/forms/dnsbl.xml#L58-L73

https://github.com/opnsense/core/blob/ff0e772b5ba2877c4ea925c86957900ad70a7774/src/opnsense/mvc/app/models/OPNsense/Unbound/Unbound.xml#L229-L233

https://github.com/opnsense/core/blob/ff0e772b5ba2877c4ea925c86957900ad70a7774/src/opnsense/service/templates/OPNsense/Unbound/core/blocklists.conf#L43

https://github.com/opnsense/core/blob/ff0e772b5ba2877c4ea925c86957900ad70a7774/src/opnsense/service/templates/OPNsense/Unbound/core/dnsbl_module.py#L60

https://github.com/opnsense/core/blob/ff0e772b5ba2877c4ea925c86957900ad70a7774/src/opnsense/service/templates/OPNsense/Unbound/core/dnsbl_module.py#L372

https://github.com/opnsense/core/blob/ff0e772b5ba2877c4ea925c86957900ad70a7774/src/opnsense/service/templates/OPNsense/Unbound/core/dnsbl_module.py#L455-L457

Sorry to open this issue again.

[swhite2]

@refuseduser If the Unbound python context is capable of returning REFUSED, I have no objections. If you want to give it a go, just open a PR and I'll take a look at it.