DNSBL failing

[xscapee1]

Okay I know this has been discussed many many times. Use your ISP DNS servers. I understand that. I was doing that. So I thought.

I have the URLS specified for the blacklists on the domain DNS servers tab and they are pointed to small(er) ISP DNS servers.

Prior to updating to 16.5.1 that worked. I have come to understand that 16.5.1 does not contain a change that would affect that.

I had sent this to support:

Prior to updating to 16.5.1 spam filters were not having an issue with resolving DNSBL queries. After the update I am seeing multiple errors for my DNS servers. I use internal severs (10.10.10.9 and 10.10.10.224) which forward to 1.1.1.1 and 1.0.0.1 and there was not an issue previously. I also have a public ISP DNS server specified on the domain DNS servers tab (see attached). This override no longer seems to work. I have also tested with the script provided in the forums and can see numerous failures for the blacklist look ups. Did 16.5.1 break this?

Does the Domain DNS server tab not work anymore?

Thanks,

Jeff

[sky-knight]

If you're using either of the Spamblockers, you have no choice but to deploy your own publicly resolving DNS server, and have Untangle use that for the DNSBLs.

Every single public DNS server I've ever used winds up in the black list. When I deployed my own DNS out in the cloud and used that, solution worked forever.

You should be using the domain feature you're doing, but you need to aim those special domains at a DNS server that does nothing else but those spam lookups for you.

[xscapee1]

When I use the script, why does it show the DNS servers I have specified on the interfaces, instead of the dns servers specified on the domain feature? How do I know it is actually using those servers?

I am working on a public dns server right now.

[sky-knight]

When I use the script, why does it show the DNS servers I have specified on the interfaces, instead of the dns servers specified on the domain feature? How do I know it is actually using those servers?

I am working on a public dns server right now.

Because that's the way the script is written, all you really care about is the top most result set because that's what's real and includes all the customization you're using.

The 2nd and 3rd test are against the indicated DNS servers, they're intended to tell you which DNS is having problems. Which simply doesn't apply for you.

So all you've really got broken is SURBL, the results form the two configured DNS servers mean nothing in your case.

[xscapee1]

Thanks Sky-Knight. I think I have it figured out and have a good solution in place now.

I built an Ubuntu 20.04 LTS VM and it is running Bind/Named and is handing the blacklist lookups now. I have the IP of this VM (10.100.100.100) specified on the Domain DNS server tab.

For my DNS that is specified on External and Internal interfaces of Untangle I use 2 DNS servers on my network. 10.10.10.9 and 10.10.10.224.

The 10.10.10.9 is a Windows AD controller with the DNS role. It uses forwarders and has no Root Hints specified. It's forwarder is to 10.10.10.224 (which is a Ubuntu Pi-Hole server). More on that in a second. On the Windows server I now have conditional forwarders specified for the DNSBL domains - -> ex: 2.0.0.127.zen.spamhaus.org., etc and they point to 10.100.100.100. That catches any DNSBL request that should go to that server.

For 10.10.10.224 as I said it is a Ubuntu 20.04 server running Pihole with DoH pointing to 1.1.1.1 and 1.0.0.1. All of the DNS in my network ultimately (except for 10.100.100.100) point to this server for external lookups. I am not doing any ad blocking etc., just using it for the DoH ability.

For 10.10.10.224 I created a file called bypass.conf in the /etc/dnsmasq.d folder and gave root permission to it. In the file I added this:

server=/spamhaus.org/10.100.100.100
server=/2.0.0.127.zen.spamhaus.org/10.100.100.100
server=/2.0.0.127.multi.uribl.com/10.100.100.100
server=/2.0.0.127.multi.surbl.org/10.100.100.100
server=/2.0.0.127.bl.spamcop.net/10.100.100.100
server=/2.0.0.127.list.dnswl.org/10.100.100.100

This catches any dnsbl lookups that should make it to this server. Again pointing back to make dnsbl server 10.100.100.100

Been running this since Friday evening and my dnsbl lookups with the script are good now. This seems to be the way around the dnsbl limitations of ISP dns servers getting flagged.