DNS query to RBL blacklists return no answer
-
@serbus Thank you for the info, did not see that bug report before. But adding an extending/changing list of rbl servers to the allow list is not user friendly. We user multiple rbl lists to check against.
Removing 127.0.0.0/8 like in previous versions of pfSense is in my option a better approach. I already added only 127.0.0.1 as that could be the best between the recent changes. Also if we want to be "complete" ::1 should also be listed (and is not in the current default of pfSense).
@netblues I will have to dig deeper into Unbound's configuration options. Excluding on client ip could be another option and better approach. Another question of course is do you really need the full 127.0.0.0/8 blocked or only 127.0.0.1/32? -
May not be applicable here but probably worth noting that Spamhaus (and possibly others) block RBL queries from open public DNS servers run by the likes of Google, Cloudflare and IBM. https://www.spamhaus.org/returnc/pub/
-
@digdug3 Unfortunately 127.0.0.0/8 is needed.
see here for details
https://www.spamhaus.org/faq/section/Spamhaus%20DBL#291 -
@biggsy said in DNS query to RBL blacklists return no answer:
May not be applicable here but probably worth noting that Spamhaus (and possibly others) block RBL queries from open public DNS servers run by the likes of Google, Cloudflare and IBM. https://www.spamhaus.org/returnc/pub/
Well, its not that they block it, they just rate limit it. (which leads to the same effect)
In order to utilize any dnsbl practically means to use your own dns quering root servers.
Anything else tends to be problematic.
(thus the need to have pfsense do the job.) -
@netblues
I don't think "rate limit" really describes it. In the link provided:
"Spamhaus does not permit queries from such public DNS resolvers."If you have pfSense use those public resolvers, on behalf of your mail server, you risk getting a 127.255.255.254 response. Better to have your mail server run its own resolver.
-
@biggsy I was referring to others too, but anyways, the problem remains the same
No forwarders can be used for dnsbl lookups in practice.From a security point of view its better to have pf do the lookups instead of allowing outbound dns lookups to root servers for the mailserver.
Pushing this to the limit, forwarders for speedier responses and root server lookups for dnsbl is the best. (as a feature)
-
@jimp Accoring to the bugrequest #10685 at redmine (https://redmine.pfsense.org/issues/10685) pfSense should only block 127.0.0.1 when "DNS Rebinding" is enabled, but now it blocks the whole 127.0.0.0/8 subnet
" Status changed from New to Not a Bug
This is due to the change in #9708 on 2.4.5 -- 127.0.0.1 is considered a private result now so you will need to tell the DNS Resolver it's OK to receive private address results from that domain.
https://docs.netgate.com/pfsense/en/latest/dns/dns-rebinding-protections.html#dns-resolver-unbound
If you still have issues, post on the forum."
This blocks resolving of dns blacklists. Is this a bug? See: https://forum.netgate.com/topic/152671/dns-query-to-rbl-blacklists-return-no-answer/16
-
Hello!
You should be able to edit unbound.inc and either modify or remove the :
private-address: 127.0.0.0/8
line.
You would good until the next reinstall or upgrade.
John
-
Next upgrade that file will probably be overwritten and I think it should/could be:
private-address: 127.0.0.1/32 -
@digdug3 And all these
What do the 127...* Return Codes mean?
Spamhaus uses this general convention for return codes:Return Code Description
127.0.0.0/24 Spamhaus IP Blocklists
127.0.1.0/24 Spamhaus Domain Blocklists
127.0.2.0/24 Spamhaus Zero Reputation Domains list
127.255.255.0/24 ERRORS (not implying a "listed" response)Currently used return codes for Spamhaus public IP zones:
Return Code Zone Description
127.0.0.2 SBL Spamhaus SBL Data
127.0.0.3 SBL Spamhaus SBL CSS Data
127.0.0.4 XBL CBL Data
127.0.0.9 SBL Spamhaus DROP/EDROP Data (in addition to 127.0.0.2, since 01-Jun-2016)
127.0.0.10 PBL ISP Maintained
127.0.0.11 PBL Spamhaus Maintained127.0.0.5-7 are allocated to XBL for possible future use; 127.0.0.8 is allocated to SBL for possible future use.
-
Hello!
You could convert the redmine issue into a feature request and ask that the gui provide more granular control in the nodnsrebindcheck option, such as the ability to exclude or modify some ranges.
It is interesting to see how our "friends" are approaching this...
https://github.com/opnsense/core/issues/3692
John
-
@netblues Yes, exactly, and 127.0.0.1/32 (only localhost) isn't used. Even if they say "127.0.0.0/24".
If I check an IP-address at http://multirbl.valli.org/ (many blocklists). Also a return code of 127.0.0.1 isn't used by any blocklist.
DNS Rebinding attacks use local addresses, that's why Unbound blocks private IPv4 addresses (10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16). Anything other then 127.0.0.1 (localhost) isn't normally used.
@serbus I think you are right, it should be a "feature". Could you change the report to a feature request?
-
Any address in 127/8 is loopback. Yes, 127.0.0.1 is the most common to find on a workstation but there may be others as well, anywhere in that range.
Only doing rebind protection for 127.0.0.1/32 is a bit of a dangerous/insecure assumption.
-
@jimp said in DNS query to RBL blacklists return no answer:
Any address in 127/8 is loopback. Yes, 127.0.0.1 is the most common to find on a workstation but there may be others as well, anywhere in that range.
Only doing rebind protection for 127.0.0.1/32 is a bit of a dangerous/insecure assumption.
Thank you @jimp for the response. Is it possible to allow these 127.0.0.1/24 responses for one ip on the LAN and block it for all others?
