[solved] best practice with unbound in pfSense and email-server behind it?
-
@darcey What I am missing on is the connection between e.g. Spamhaus and unbound or my upstream DNS.
I guess and I could be wrong, my email server is asking Spamhaus directly, my unbound is not involved, right? I really don't know how this part works though. -
@darcey said in best practice with unbound in pfSense for an email-server behind it?:
Having the business IP should at least mean you're not on the PBL and therefore deliver mail directly.
Again, not the point of this thread.
-
@Bob-Dig Say you're using one or more of the dnsbl services with e.g. postfix's postscreen. The dnsbl checks are made by postfix, via regular dns queries, to whatever the mailserver host's configued dns is.
The dns queries are of the form 12.34.56.78.zen.spamhaus.org
The replies (from spamhaus's NS ideally via recursive lookup) are of the form 127.0.0.X. Which is then interpretted by your mailserver. Usually you query several dnsblservers, optionally weighted according to which you prefer. -
@Bob-Dig said in best practice with unbound in pfSense for an email-server behind it?:
my email server is asking Spamhaus directly, my unbound is not involved
Incorrect, it's a DNS based lookup:
# dig +short 2.0.0.127.zen.spamhaus.org 127.0.0.2 127.0.0.10 127.0.0.4 # dig +short 2.0.0.127.zen.spamhaus.org txt "https://www.spamhaus.org/query/ip/127.0.0.2" "https://www.spamhaus.org/sbl/query/SBL2"
They have blocked Quad9/CloudFlare from connecting to their services by telling any queries that all IPs are bad. I thought Google also, actually but they don't seem to be blocked today?
#dig +short 2.0.0.127.zen.spamhaus.org @9.9.9.9 127.255.255.254 #dig +short 2.0.0.127.zen.spamhaus.org txt @9.9.9.9 "Error: open resolver; https://www.spamhaus.org/returnc/pub/2620:171:fe:f0::237" #dig +short 2.0.0.127.zen.spamhaus.org txt @1.1.1.1 "Error: open resolver; https://www.spamhaus.org/returnc/pub/172.70.177.38"
So in Unbound, uncheck "DNS Query Forwarding." Unless maybe if you're using Google DNS.
-
Ok, this is the hard part, I don't get. DNS is hard it seems.
-
@Bob-Dig said in best practice with unbound in pfSense for an email-server behind it?:
Ok, this is the hard part, I don't get. DNS is hard it seems.
Nah, ask a question, get an answer, simple.
-
I think I kinda getting it slowly. Will try tomorrow if I get the whole picture. And so my DNS configured in pfSense can make a big difference if this stuff will actually work or not. Thanks guys!
-
- Don't use upstream public DNS.
- If using unbound, either disable rebind protection or use the unbound config mentioned above for your specific dnsbl's.
- Be selective with the dnsbl's and,with postfix, you can also weight them:
postscreen_dnsbl_sites = zen.spamhaus.org*2,dnsbl.sorbs.net*1,bl.spamcop.net*1,b.barracudacentral.org*1 postscreen_dnsbl_threshold = 2
This has been working reasonably well for me other than some recent paypal 'communications' getting blocked by sorbs. None of the transaction related mail was affected.
-
@SteveITS @darcey Thank you both for helping me understand that topic and also showing me ways to validate my solution myself.
For now on one Site I am using a DNS Provider that is not blocked by any of those services I use and gave the mx that DNS server directly, not going through unbound anymore. One another Site I turned off DNS Query Forwarding in pfSense and turned on Python Group Policy in pfBlocker for the mx, just to make sure. In the end I can make it work now, thanks to you guys.A note to @biggsy , thanks you for your kindly offer, I am good now, topic is closed.
-
Just to recap, I couldn't use Unbound in resolver-mode for those mx because sites like zen.spamhaus.org wouldn't work with it, I don't know the reason.
Also I couldn't disable rebind protection because split-DNS wouldn't work anymore when I was using my domain with DNSSEC.
So I have to use a third party DNS-server for those mx which is not blocked by spamhaus.org and alike. And because I still have a need for some split-DNS like behavior for my mx, I made a port forward from one external to one internal address in pfSense to cope with that.
And it is running smoothly now. But it is more complicated than I had imagined.