I’m working on trying to improve spam filtering on my Virtualmin server and still having some blocklists block even after switching to my datacenter’s DNS in resolv.conf instead of using 8.8.8.8, etc. For example:
0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL
was blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[----- listed in list.dnswl.org]
0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[----- listed in sa-trusted.bondedsender.org]
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[----- listed in bl.score.senderscore.com]
I registered with Validity.com, but it sounds like both DNSWL and Validity want the e-mail server to have a caching DNS server for local resolution. Is there a good way to do local resolution DNS caching for spam filtering without messing up Virtualmin’s use of BIND for actual DNS service to hosted web sites?
I’m running Debian 12. It doesn’t seem to have systemd-resolved installed by default. I wonder if it would cause any unexpected behavior to enable it on Debian? I’d expect it would perform pretty similarly to a recent Ubuntu version like yours.
I’m running Debian 12. It doesn’t seem to have systemd-resolved installed by default. I wonder if it would cause any unexpected behavior to enable it on Debian? I’d expect it would perform pretty similarly to a recent Ubuntu version like yours.
I could not tell you as I am a Windows guy, but I cannot see it being that different, it is all of the required configuration that might be an issue.
Personally I would just use Ubuntu as I find most stuff is setup just right. Debian is a very minimal install where everything is a battle to get it to work.
The guys at Ubuntu have taken a naked Debian and add all of the stuff that should be there into it.
I used Ubunutu Server (Minimal install), see below for my setup pre-virtualmin
The Linux Pros might have a different opinion on what version of Linux to use
So, I played around and systemd-resolved works fine alongside BIND on Debian. However, I figured I’d still want the local name server to be authoritative for locally hosted sites. So I was going to have systemd-resolved reach out to BIND for local sites and then let BIND forward only for local requests. But, then why not just use bind directly?
I think I have it working where BIND correctly refuses recursive resolution for any external user, but caches and resolves for the local system. (This produces about a 1ms gain over systemd-resolved → BIND by reducing complexity; I noticed when I used the two in tandem, systemd-resolved quit attempting caching presumably because it realized BIND was local. Negligible from a performance standpoint, but I think one less step is one less step that could break!)
/etc/resolv.conf:
nameserver 127.0.0.1
search ---.com # Replace --- with local domain
/etc/bind/named.conf.options:
directory "/var/cache/bind";
dnssec-validation auto;
listen-on-v6 { any; };
allow-recursion { localnets; localhost; };
allow-query { any; }; # Allows any to query non-recursive
allow-query-cache { localnets; localhost; };
forwarders {
8.8.8.8; // Google DNS
8.8.4.4; // Google DNS
1.1.1.1; // Cloudflare DNS
1.0.0.1; // Cloudflare DNS
};
forward first;
For what it is worth, this seems to work well. Locally dig can look up any domain, but from another server attempting to query this server, it provides a “REFUSED” response.
Ha! Yes, the “Linux Pros” have revolted a bit against Ubuntu as of late for a few reasons. It is a nice distro, though. I’ve used RHEL-derivatives for years for hosting and as long as I was going to jump, I’d go purist and use Debian for good measure.
One more thing on my config above: once I got it working I removed the Cloudflare and Google DNS in favor of my datacenter’s DNS. Spamhaus refuses to talk to SpamAssassin (the original problem prompting all this!) if one uses an open resolver. Once I switched to my DC’s DNS, the warnings about that disappeared.
I was still having URIBL block my requests. I found a suggestion on ServerFault that seemed to fix it, completely disabling forwarding on known blacklists to keep them happy alongside my earlier configuration. On Debian 12, I put it in /etc/bind/named.conf.options below the options block:
// Disable forwarding for DNSBL queries
// https://wiki.apache.org/spamassassin/CachingNameserver#Non-forwarding
zone "multi.uribl.com" { type forward; forward first; forwarders {}; };
zone "dnsbl.sorbs.net" { type forward; forward first; forwarders {}; };
zone "combined.njabl.org" { type forward; forward first; forwarders {}; };
zone "activationcode.r.mail-abuse.com" { type forward; forward first; forwarders {}; };
zone "nonconfirm.mail-abuse.com" { type forward; forward first; forwarders {}; };
zone "iadb.isipp.com" { type forward; forward first; forwarders {}; };
zone "bl.spamcop.net" { type forward; forward first; forwarders {}; };
zone "fulldom.rfc-ignorant.org" { type forward; forward first; forwarders {}; };
zone "list.dnswl.org" { type forward; forward first; forwarders {}; };
zone "blackholes.mail-abuse.org" { type forward; forward first; forwarders {}; };
zone "bl.score.senderscore.com" { type forward; forward first; forwarders {}; };
zone "zen.spamhaus.org" { type forward; forward first; forwarders {}; };
I then reran a message through SpamAssassin that had previously warned with URIBL_BLOCK and the warning was no longer triggered.
