unbound returns from DNSBLs

[kairuri]

Hi,
I have been gradually making changes to my opnsense configuration since upgrading from t1n1wall and I aim to keep opnsense as an appliance.
I recently changed from using dnsmasq forwarding to 202.68.86.122 and 210.48.65.1 to using unbound as a first as a forwarding and then recursive nameserver and I find that it does not return results suitable for a mailserver that uses DNSBLs - see <https://www.spamhaus.org/faq/section/DNSBL%20Usage#366> for explanation.

192.168.2.1 is my OPNsense/Unbound nameserver:

root@ikaroa:~# host  2.0.0.127.zen.spamhaus.org 192.168.2.1
Using domain server:
Name: 192.168.2.1
Address: 192.168.2.1#53
Aliases:

root@ikaroa:~# host  1.0.0.127.zen.spamhaus.org 192.168.2.1
Using domain server:
Name: 192.168.2.1
Address: 192.168.2.1#53
Aliases:

Host 1.0.0.127.zen.spamhaus.org not found: 3(NXDOMAIN)

Unbound does not send back the correct results for 2.0.0.127.zen.spamhaus.org

If I repeat the test against any of the forwarders I have used in the past, I get the correct response :

root@ikaroa:~# host  2.0.0.127.zen.spamhaus.org 202.68.86.122
Using domain server:
Name: 202.68.86.122
Address: 202.68.86.122#53
Aliases:

2.0.0.127.zen.spamhaus.org has address 127.0.0.4
2.0.0.127.zen.spamhaus.org has address 127.0.0.10
2.0.0.127.zen.spamhaus.org has address 127.0.0.2
root@ikaroa:~# host  1.0.0.127.zen.spamhaus.org 202.68.86.122
Using domain server:
Name: 202.68.86.122
Address: 202.68.86.122#53
Aliases:

Host 1.0.0.127.zen.spamhaus.org not found: 3(NXDOMAIN)

The correct results are really important for a properly working mailserver - currently I have my forwarding to the working nameservers.
These results are the same no matter if Unbound is recursive or forwarding.  I have DNSSEC enabled but it makes no difference.

I would really appreciate any help here!

Below I have added the verbose responses for 2.0.0.127.zen.spamhaus.org :

root@ikaroa:~# host -v  2.0.0.127.zen.spamhaus.org 192.168.2.1
Trying "2.0.0.127.zen.spamhaus.org"
Using domain server:
Name: 192.168.2.1
Address: 192.168.2.1#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3734
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;2.0.0.127.zen.spamhaus.org.    IN      A

Received 44 bytes from 192.168.2.1#53 in 568 ms
Trying "2.0.0.127.zen.spamhaus.org"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23743
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;2.0.0.127.zen.spamhaus.org.    IN      AAAA

;; AUTHORITY SECTION:
zen.spamhaus.org.       9       IN      SOA     need.to.know.only. hostmaster.spamhaus.org. 1809062246 3600 600 432000 10

Received 108 bytes from 192.168.2.1#53 in 410 ms
Trying "2.0.0.127.zen.spamhaus.org"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18129
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;2.0.0.127.zen.spamhaus.org.    IN      MX

;; AUTHORITY SECTION:
zen.spamhaus.org.       8       IN      SOA     need.to.know.only. hostmaster.spamhaus.org. 1809062246 3600 600 432000 10

Received 108 bytes from 192.168.2.1#53 in 1233 ms

root@ikaroa:~# host -v  2.0.0.127.zen.spamhaus.org 202.68.86.122
Trying "2.0.0.127.zen.spamhaus.org"
Using domain server:
Name: 202.68.86.122
Address: 202.68.86.122#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23399
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 0

;; QUESTION SECTION:
;2.0.0.127.zen.spamhaus.org.    IN      A

;; ANSWER SECTION:
2.0.0.127.zen.spamhaus.org. 60  IN      A       127.0.0.2
2.0.0.127.zen.spamhaus.org. 60  IN      A       127.0.0.4
2.0.0.127.zen.spamhaus.org. 60  IN      A       127.0.0.10

;; AUTHORITY SECTION:
zen.spamhaus.org.       391     IN      NS      a.gns.spamhaus.org.
zen.spamhaus.org.       391     IN      NS      c.gns.spamhaus.org.
zen.spamhaus.org.       391     IN      NS      b.gns.spamhaus.org.
zen.spamhaus.org.       391     IN      NS      e.gns.spamhaus.org.
zen.spamhaus.org.       391     IN      NS      d.gns.spamhaus.org.

Received 176 bytes from 202.68.86.122#53 in 158 ms
Trying "2.0.0.127.zen.spamhaus.org"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7804
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;2.0.0.127.zen.spamhaus.org.    IN      AAAA

;; AUTHORITY SECTION:
zen.spamhaus.org.       10      IN      SOA     need.to.know.only. hostmaster.spamhaus.org. 1809062302 3600 600 432000 10

Received 108 bytes from 202.68.86.122#53 in 155 ms
Trying "2.0.0.127.zen.spamhaus.org"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1178
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;2.0.0.127.zen.spamhaus.org.    IN      MX

;; AUTHORITY SECTION:
zen.spamhaus.org.       10      IN      SOA     need.to.know.only. hostmaster.spamhaus.org. 1809062302 3600 600 432000 10

Received 108 bytes from 202.68.86.122#53 in 148 ms

[kairuri]

Hi All,
I have found a solution to my problem with an incorrect answer from unbound to a query for 2.0.0.127.zen.spamhaus.org as required by a mailserver that uses DNSBL blocklists.

I just had to edit /var/unbound/unbound.conf and comment out the line
private-address: 127.0.0.0/8     # Loopback Localhost
and then send a HUP to the unbound PID.

Now unbound responds perfectly with (192.168.2.1 is my opnsense firewall/router/nameserver):
# host  2.0.0.127.zen.spamhaus.org 192.168.2.1
Using domain server:
Name: 192.168.2.1
Address: 192.168.2.1#53
Aliases:

2.0.0.127.zen.spamhaus.org has address 127.0.0.2
2.0.0.127.zen.spamhaus.org has address 127.0.0.10
2.0.0.127.zen.spamhaus.org has address 127.0.0.4

I can see that at first sight, suppressing results from "private-address: 127.0.0.0/8" may seem perfectly normal and even desirable, but in this case it does prevent a common and desirable use of a nameserver.
It would be important for anyone who operates even a small mailserver to be able to use DNS Block Lists (DNSBL).

This gives me a problem in that I want to use OPNsense as an appliance without having local hacks that are likely to break.  So there seems to be 3 choices:
1 - Use dnsmasq as a forwarding nameserver
2 - Try and maintain a local hack
3 - Try to convince the OPNsense maintainers to either remove 127.0.0.0/8 as a private-address or add yet another option in the GUI...

I am a newbie to opnsense so would appreciate advice
Cheers
Kairuri

[kairuri]

OK, I have now found the "complete answer". 
The problem results from decisions made as the result of https://forum.opnsense.org/index.php?topic=1416.0 which I believe were deficient (but probably seemed like a good idea at the time) and should be fixed by the maintainers (Franco?).

Please check the thread above against the man page for unbound.conf - refer to section private-address:

These are addresses on your private network, and are not allowed to be
returned for public internet names. [snip]
Turning on 127.0.0.0/8 would hinder many spamblocklists as they use that.

So I would like the maintainers of /usr/local/etc/inc/plugins.inc.d/unbound.inc to review the thread above, unbound.conf(5) and modify unbound.inc appropriately.

In the mean time after firmware upgrades, I run:

Code: [Select]

# sed -i.orig -e 's/^private-address: 127.0.0.0\/8/## private-address: 127.0.0.0\/8/' /usr/local/etc/inc/plugins.inc.d/unbound.incand then re-start unbound from the GUI 

Cheers
Pete

[MolallaComm]

I was just bitten by this exact same problem.  Thanks for the solution - and hopefully my posting will bring the thread back up to where it gets some visibility and a fix - because as you mention, it will be a drag remembering to login and run the fix after every upgrade.

[franco]

Ladies and gentlemen, please note removing this line is not the fix you're looking for. It's a workaround for your use case that opens up pandora's box.

https://github.com/opnsense/core/issues/3692

We've been running Unbound this way for almost 4 years now and all of a sudden that can't be such a pressing issue that requires a clean-cut revert.


Cheers,
Franco

[MolallaComm]

Thanks so much for the link to the proper and permanent way to fix.